VPN(PPTP)接続ができない

3つのオフィス間でつながる（2）

ソリューションページはこちら

インデックス

 症状    切り分け手順    状態確認方法    トラブル原因と対処方法

症状：VPN(PPTP)接続ができない

ここでは、RTX1200の基本的な設定が終了し、RT58iとVPN(PPTP)接続ができないケースでのトラブルシューティングを提供します。

※解説は[3つのオフィス間でつながる(2)]のRTX1200を対象としています。

切り分け手順：通信状況を以下の手順で確認し、問題の切り分け作業を行います。

1-1

RTX1200からインターネット上のnetvolante.jpへのpingは応答がありますか？

YES/NO
インターネット接続に失敗していますので、こちらを参考に設定を確認してください。

1-2

RTX1200から対向側RT58iのネットボランチDNSに登録された名前に対するpingは応答がありますか？

YES/NO
RT58i側でネットボランチDNSへの登録ができているかを確認してください。
Open in new window ネットボランチDNSのFAQ

1-3

RTX1200から対向側RT58iのLAN1アドレスへのpingは応答がありますか？

YES/NO
RTX1200の状態を確認するため状態確認方法へ進んでください。

正常に動作しています。

状態確認方法

この項目ではコマンドによる状態確認方法を紹介します。
表示例は正常接続時のものです。
トラブル発生時の状態と比較することで、問題解決の助けとなります。

2-1 プロバイダとの接続状態を確認する。

2-2 NATディスクリプタの状態を確認する。

2-3 経路情報を確認する。

2-4 デバッグログを確認する。

2-1 プロバイダとの接続状態を確認する。

RTX1200の"show status pp 1"コマンドを実行し、内容を確認します。

[正常時]

# show status pp 1
PP[01]:
説明:
PPPoEセッションは接続されています
接続相手:
通信時間: 13分4秒
受信: 191 パケット [15207 オクテット] 負荷: 0.0%
送信: 191 パケット [14255 オクテット] 負荷: 0.0%
PPPオプション
　LCP Local: Magic-Number MRU, Remote: CHAP Magic-Number MRU
　IPCP Local: IP-Address, Remote: IP-Address
　PP IP Address Local: 172.16.0.10, Remote: 172.16.0.1
　CCP: None

[解説]
接続に成功し"PPPoEセッションは接続されています"と表示されています。

2-2 NATディスクリプタの状態を確認する。

RTX1200の"show nat descriptor address"コマンドを実行し、内容を確認します。

[正常時]

# show nat descriptor address
参照NATディスクリプタ : 1, 適用インタフェース : PP[01](1)
Masqueradeテーブル
　外側アドレス: ipcp/172.16.0.10
　ポート範囲: 60000-64095, 49152-59999, 44096-49151 14個使用中
プロトコル 内側アドレス 宛先 マスカレード 種別

PPTP

192.168.101.1.*

*.*.*.*.*

*

static---(1)

TCP

192.168.101.1.1723

*.*.*.*.*

1723

static---(2)
No. 内側アドレス 使用中のポート数 制限数 種別

1

192.168.101.1

14

20000

dynamic
有効なNATディスクリプタテーブルが1個ありました
[解説]
(1)GREを通すための静的IPマスカレードです。
(2)TCP 1723番ポートを通すための静的IPマスカレードです。

2-3　経路情報を確認する。

RTX1200の"show ip route"コマンドを実行し、経路情報を確認します。

[正常時]

# show ip route
宛先ネットワーク ゲートウェイ インタフェース 種別 付加情報

default

-

PP[01]

static

 

172.16.0.1/32

-

PP[01]

temporary

 

172.16.0.10/32

-

PP[01]

implicit

 

192.168.102.0/24

-

PP[02]

static

 

192.168.103.0/24

-

PP[03]

static

 

192.168.200.0/24

-

PP[ANONYMOUS01]

implicit

 
[解説]
"default"は"ip route default gateway pp 1"コマンドで設定された静的経路です。
インターネットに接続するためには、"default"経路が必要です。

2-4 デバッグログを確認する。

あらかじめRTX1200に"syslog debug on"を設定しておきます。
その後、RTX1200で"show log"コマンドを実行すると以下のようなログが表示されます。

[VPN接続成功時ログの例]

# show log
2010/04/05 14:12:48: TUNNEL[01] PPTP connection is established: 172.16.0.11
2010/04/05 14:12:48: PP[02] PPTP Connect
2010/04/05 14:12:48: PP[02] SEND LCP ConfReq in STARTING
2010/04/05 14:12:48:　 ff 03 c0 21 01 01 00 13　01 04 07 00 03 05 c2 23
2010/04/05 14:12:48:　 80 05 06 c2 e0 5f 63
2010/04/05 14:12:48: PP[02] RECV LCP ConfReq in REQSENT
2010/04/05 14:12:48:　 ff 03 c0 21 01 01 00 0e　01 04 07 00 05 06 4d 52
2010/04/05 14:12:48:　 5e 81
2010/04/05 14:12:48: PP[02] SEND LCP ConfAck in REQSENT
2010/04/05 14:12:48:　 ff 03 c0 21 02 01 00 0e　01 04 07 00 05 06 4d 52
2010/04/05 14:12:48:　 5e 81
2010/04/05 14:12:51: PP[02] SEND LCP ConfReq in ACKSENT
2010/04/05 14:12:51:　 ff 03 c0 21 01 01 00 13　01 04 07 00 03 05 c2 23
2010/04/05 14:12:51:　 80 05 06 c2 e0 5f 63
2010/04/05 14:12:51: PP[02] RECV LCP ConfAck in ACKSENT
2010/04/05 14:12:51:　 ff 03 c0 21 02 01 00 13　01 04 07 00 03 05 c2 23
2010/04/05 14:12:51:　 80 05 06 c2 e0 5f 63
2010/04/05 14:12:51: PP[02] SEND CHAP Challenge in CS_CLOSED/SS_CLOSED
2010/04/05 14:12:51:　 ff 03 c2 23 01 01 00 1a　08 49 cb e4 9b a5 89 6c
2010/04/05 14:12:51:　 21 31 39 32 2e 31 36 38　2e 31 30 31 2e 31
2010/04/05 14:12:51: PP[02] RECV CHAP Response in CS_CLOSED/SS_INIT-CHAL
2010/04/05 14:12:51:　 ff 03 c2 23 02 01 00 3d　31 00 00 00 00 00 00 00
2010/04/05 14:12:51:　 00 00 00 00 00 00 00 00　00 00 00 00 00 00 00 00
2010/04/05 14:12:51:　 00 39 46 ea 52 4a cf cf　f7 83 f2 30 d2 54 6d c0
2010/04/05 14:12:51:　 87 cc 00 9a 39 66 00 8c　72 01 6b 79 6f 74 65 6e
2010/04/05 14:12:51:　 32
2010/04/05 14:12:51: PP[02] SEND CHAP Success in CS_CLOSED/SS_INIT-CHAL
2010/04/05 14:12:51:　 ff 03 c2 23 03 01 00 1d　41 75 74 68 65 6e 74 69
2010/04/05 14:12:51:　 63 61 74 69 6f 6e 20 73　75 63 63 65 65 64 65 64
2010/04/05 14:12:51:　 2e
2010/04/05 14:12:51: PP[02] SEND CCP ConfReq in STARTING
2010/04/05 14:12:51:　 ff 03 80 fd 01 01 00 0a　12 06 01 00 00 60
2010/04/05 14:12:51: PP[02] SEND IPCP ConfReq in STARTING
2010/04/05 14:12:51:　 ff 03 80 21 01 01 00 0a　03 06 00 00 00 00
2010/04/05 14:12:51: PP[02] SEND IPV6CP ConfReq in STARTING
2010/04/05 14:12:51:　 ff 03 80 57 01 01 00 0e　01 0a 02 a0 de ff fe 37
2010/04/05 14:12:51:　 b5 0a
2010/04/05 14:12:52: PP[02] RECV CCP ConfReq in REQSENT
2010/04/05 14:12:52:　 ff 03 80 fd 01 01 00 0a　12 06 01 00 00 60
2010/04/05 14:12:52: PP[02] SEND CCP ConfNak in REQSENT
2010/04/05 14:12:52:　 ff 03 80 fd 03 01 00 0a　12 06 01 00 00 40
2010/04/05 14:12:52: PP[02] RECV IPCP ConfReq in REQSENT
2010/04/05 14:12:52:　 ff 03 80 21 01 01 00 0a　03 06 00 00 00 00
2010/04/05 14:12:52: PP[02] SEND IPCP ConfRej in REQSENT
2010/04/05 14:12:52:　 ff 03 80 21 04 01 00 0a　03 06 00 00 00 00
2010/04/05 14:12:52: PP[02] RECV CCP ConfNak in REQSENT
2010/04/05 14:12:52:　 ff 03 80 fd 03 01 00 0a　12 06 01 00 00 40
2010/04/05 14:12:52: PP[02] SEND CCP ConfReq in REQSENT
2010/04/05 14:12:52:　 ff 03 80 fd 01 02 00 0a　12 06 01 00 00 40
2010/04/05 14:12:52: PP[02] RECV IPCP ConfRej in REQSENT
2010/04/05 14:12:52:　 ff 03 80 21 04 01 00 0a　03 06 00 00 00 00
2010/04/05 14:12:52: PP[02] SEND IPCP ConfReq in REQSENT
2010/04/05 14:12:52:　 ff 03 80 21 01 02 00 0a　03 06 c0 a8 65 01
2010/04/05 14:12:52: PP[02] RECV LCP ProtRej in OPENED
2010/04/05 14:12:52:　 ff 03 c0 21 08 02 00 14　80 57 01 01 00 0e 01 0a
2010/04/05 14:12:52:　 02 a0 de ff fe 37 b5 0a
2010/04/05 14:12:52: PP[02] RECV CCP ConfReq in REQSENT
2010/04/05 14:12:52:　 ff 03 80 fd 01 02 00 0a　12 06 01 00 00 40
2010/04/05 14:12:52: PP[02] SEND CCP ConfAck in REQSENT
2010/04/05 14:12:52:　 ff 03 80 fd 02 02 00 0a　12 06 01 00 00 40
2010/04/05 14:12:52: PP[02] RECV IPCP ConfReq in REQSENT
2010/04/05 14:12:52:　 ff 03 80 21 01 02 00 0a　03 06 c0 a8 66 01
2010/04/05 14:12:52: PP[02] SEND IPCP ConfAck in REQSENT
2010/04/05 14:12:52:　 ff 03 80 21 02 02 00 0a　03 06 c0 a8 66 01
2010/04/05 14:12:52: PP[02] RECV CCP ConfAck in ACKSENT
2010/04/05 14:12:52:　 ff 03 80 fd 02 02 00 0a　12 06 01 00 00 40
2010/04/05 14:12:52: PP[02] RECV IPCP ConfAck in ACKSENT
2010/04/05 14:12:52:　 ff 03 80 21 02 02 00 0a　03 06 c0 a8 65 01
2010/04/05 14:12:52: PP[02] PPP/IPCP up　(Local: 192.168.101.1, Remote: 192.168.102.1)
2010/04/05 14:12:52: PP[02] Local　PP IP address 192.168.101.1
2010/04/05 14:12:52: PP[02] Remote PP IP address 192.168.102.1

[解説]
"PP[02] PPP/IPCP up"が表示され、VPN接続が成功していることが分かります。

トラブル原因と対処方法

この項目では各トラブル発生時の状態と、原因及びその解決方法を紹介します。
正常時の状態と比較することで、問題解決の助けとなります。

3-1 PP1フィルタの設定間違いによるVPN接続失敗。

3-2 NATディスクリプタの設定間違いによるVPN接続失敗。

3-3 VPN接続は成功しているが、通信ができない。

3-1　PP1フィルタの設定間違いによるVPN接続失敗

このケースは、フィルタの設定間違いによるVPN接続失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。

ログの確認
※ログ採取の前にRTX1200に"syslog notice on"を設定しておきます。

ケース1 VPN接続に失敗した時に以下ログが表示されました。

2010/04/07 15:41:07: PP[01] Rejected at IN(2000) filter: TCP 172.16.0.11:6003
5 > 192.168.101.1:1723
2010/04/07 15:41:12: same message repeated 1 times

[解説]
ログからTCP 1723番ポート宛のパケットがPP1のIN方向のフィルタの2000番で破棄されていることが分かります。

例えば、このような原因としては以下が考えられます。
　
・PP1のIN方向に静的フィルタの1040番が設定されていない。
　
pp select 1
ip pp secure filter in 1020 1030 1041 2000
※ 設定例では、PP1のIN方向にPPTP接続に必要なTCPの1723番ポートとGREを通していますので、これが設定されていないとVPN接続ができません。

対処方法
フィルタを正しく設定してください。

pp select 1
ip pp secure filter in 1020 1030 1040 1041 2000

ケース2 "show status pp 2"コマンドで確認すると「PPTPセッションは接続されています」と表示されるが、通信ができない。

pp1# show status pp 2
PP[02]:
PPTPセッションは接続されています
接続相手: RT58i
通信時間: 8秒
受信: 0 パケット [0 オクテット]
送信: 3 パケット [69 オクテット]
　
　
・ログは以下の通り
2010/04/05 14:26:58: TUNNEL[01] PPTP connection is established: 172.16.0.11
2010/04/05 14:26:58: PP[02] PPTP Connect
2010/04/05 14:26:58: PP[02] SEND LCP ConfReq in STARTING
2010/04/05 14:26:58: ff 03 c0 21 01 01 00 13 01 04 07 00 03 05 c2 23
2010/04/05 14:26:58: 80 05 06 d2 17 07 1b
2010/04/05 14:26:58: PP[01] Rejected at IN(2000) filter: proto=47 172.16.0.11
> 192.168.101.1
2010/04/05 14:27:01: PP[02] SEND LCP ConfReq in REQSENT
2010/04/05 14:27:01: ff 03 c0 21 01 01 00 13 01 04 07 00 03 05 c2 23
2010/04/05 14:27:01: 80 05 06 d2 17 07 1b
2010/04/05 14:27:01: PP[01] Rejected at IN(2000) filter: proto=47 172.16.0.11
> 192.168.101.1
2010/04/05 14:27:03: same message repeated 2 times
2010/04/05 14:27:04: PP[02] SEND LCP ConfReq in REQSENT
2010/04/05 14:27:04: ff 03 c0 21 01 01 00 13 01 04 07 00 03 05 c2 23
2010/04/05 14:27:04: 80 05 06 d2 17 07 1b
2010/04/05 14:27:04: PP[01] Rejected at IN(2000) filter: proto=47 172.16.0.11
> 192.168.101.1
2010/04/05 14:27:07: same message repeated 2 times
2010/04/05 14:27:07: PP[02] SEND LCP ConfReq in REQSENT
2010/04/05 14:27:07: ff 03 c0 21 01 01 00 13 01 04 07 00 03 05 c2 23
2010/04/05 14:27:07: 80 05 06 d2 17 07 1b
2010/04/05 14:27:07: PP[01] Rejected at IN(2000) filter: proto=47 172.16.0.11
> 192.168.101.1
2010/04/05 14:27:10: same message repeated 2 times
2010/04/05 14:27:10: PP[02] SEND LCP ConfReq in REQSENT
2010/04/05 14:27:10: ff 03 c0 21 01 01 00 13 01 04 07 00 03 05 c2 23
2010/04/05 14:27:10: 80 05 06 d2 17 07 1b
2010/04/05 14:27:10: PP[01] Rejected at IN(2000) filter: proto=47 172.16.0.11
> 192.168.101.1
2010/04/05 14:27:13: PP[02] SEND LCP ConfReq in REQSENT
2010/04/05 14:27:13: ff 03 c0 21 01 01 00 13 01 04 07 00 03 05 c2 23
2010/04/05 14:27:13: 80 05 06 d2 17 07 1b
2010/04/05 14:27:13: PP[01] Rejected at IN(2000) filter: proto=47 172.16.0.11
> 192.168.101.1
2010/04/05 14:27:16: PP[02] SEND LCP ConfReq in REQSENT
2010/04/05 14:27:16: ff 03 c0 21 01 01 00 13 01 04 07 00 03 05 c2 23
2010/04/05 14:27:16: 80 05 06 d2 17 07 1b
2010/04/05 14:27:16: PP[01] Rejected at IN(2000) filter: proto=47 172.16.0.11
> 192.168.101.1
2010/04/05 14:27:19: PP[02] SEND LCP ConfReq in REQSENT
2010/04/05 14:27:19: ff 03 c0 21 01 01 00 13 01 04 07 00 03 05 c2 23
2010/04/05 14:27:19: 80 05 06 d2 17 07 1b
2010/04/05 14:27:19: PP[01] Rejected at IN(2000) filter: proto=47 172.16.0.11
> 192.168.101.1
2010/04/05 14:27:22: PP[02] SEND LCP ConfReq in REQSENT
2010/04/05 14:27:22: ff 03 c0 21 01 01 00 13 01 04 07 00 03 05 c2 23
2010/04/05 14:27:22: 80 05 06 d2 17 07 1b
2010/04/05 14:27:22: PP[01] Rejected at IN(2000) filter: proto=47 172.16.0.11
> 192.168.101.1

[解説]
ログからプロトコルの47番(GRE)がPP1のIN方向のフィルタの2000番で破棄されていることが分かります。
例えば、このような原因としては以下が考えられます。
　
・PP1のIN方向に静的フィルタの1041番が設定されていない。
　
pp select 1
ip pp secure filter in 1020 1030 1040 2000

※ 設定例では、PP1のIN方向にPPTP接続に必要なTCPの1723番ポートとGREを通していますので、これが設定されていないとVPN接続ができません。
参考：正常時状態

対処方法
フィルタを正しく設定してください。

pp select 1
ip pp secure filter in 1020 1030 1040 1041 2000

3-2 NATディスクリプタの設定間違いによるVPN接続失敗

このケースは、NATディスクリプタの設定間違いによるVPN接続失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。

pp1# show nat descriptor address
参照NATディスクリプタ : 1, 適用インタフェース : PP[01](1)
Masqueradeテーブル
　外側アドレス: ipcp/172.16.0.10
　ポート範囲: 60000-64095, 49152-59999, 44096-49151
---------------------
有効なNATディスクリプタテーブルが1個ありました

[解説]
VPN接続するための静的IPマスカレードが設定されていません。
参考：正常時状態

対処方法
以下のように静的IPマスカレードが設定されているか確認してください。

nat descriptor masquerade static 1 1 192.168.0.1 tcp 1723
nat descriptor masquerade static 1 2 192.168.0.1 gre

3-3 VPN接続は成功しているが、通信ができない。

このケースは、経路情報の設定間違いによるVPN接続失敗事例です。
以下ではRTX1200の状態を確認し原因の究明を行います。

# show ip route
宛先ネットワーク ゲートウェイ インタフェース 種別 付加情報

default

-

PP[01]

static

 

172.16.0.1/32

-

PP[01]

temporary

 

172.16.0.10/32

-

PP[01]

implicit

 

192.168.102.1/32

-

PP[02]

temporary

 

192.168.103.0/24

-

PP[03]

static

 

192.168.200.0/24

-

PP[ANONYMOUS01]

implicit

 
[解説]
ログには"PP[02] PPP/IPCP up"が表示され、VPN接続が成功していることを確認することができるが、VPN経由の通信ができない。
"show ip route"コマンドで経路情報を確認すると、以上のようにPP[02]宛の192.168.102.0/24への経路が設定されていません。
参考：正常時状態

対処方法
フィルタを正しく設定してください。

ip route 192.168.102.0/24 gateway pp 2

それでも問題が解決しない場合は、サポート窓口までご相談ください。

ページトップへ戻るReturn to Top