ファイアウォールで開けるVPNポート：プロトコル別に解説
PPTPはTCP 1723とGRE、L2TP/IPsecはUDP 500と4500およびESP、SSTP・OpenVPN・WireGuardはそれぞれ一つのポートが必要です。何を開けるべきかをまとめます。
VPNトンネルがファイアウォールを通過できるかは、クライアントが接続するポートと、ペイロードを運ぶプロトコルという二つの別々のルールで決まります。前者だけを開けるとトンネルは認証まで進み、その後にデータが流れません。最小構成は、PPTPならTCPポート一つとGRE、L2TP/IPsecとIKEv2ならUDPポート二つとESP、SSTP・OpenVPN・WireGuardならそれぞれ一つのポートです。残りは方向、状態追跡、NATで決まります。
クライアントが接続するポートから始める
どの方式にもクライアントが最初に接続する入口があり、許可ルールはその入口を指定しなければなりません。PPTPクライアントはTCP 1723に接続します。L2TP/IPsecはUDP 500でIKEを開始し、NATトラバーサルを使うとUDP 4500へ移り、L2TPフレーム自体はトンネル内のUDP 1701に載ります。SSTPはセッションをTCP 443のTLSで包み、IKEv2はUDP 500と4500で交渉し、OpenVPNは既定でUDP 1194を使いますがTCP 443へ移されることが多く、WireGuardはUDP 51820で待ち受けます。
| Family | Rule to add on the gateway | Typical mistake |
|---|---|---|
| WireGuard | UDP port from ListenPort, for the peer address | Assuming 51820 when the config says otherwise |
| OpenVPN | The configured UDP or TCP port, often 443 | Opening 1194 after the server moved |
| SSTP | TCP 443 limited to the gateway IP | Allowing 443 to any destination |
| IKEv2 | UDP 500 and UDP 4500, plus ESP | Allowing only 500 and losing NAT-T |
| L2TP/IPsec | UDP 500, 4500, ESP, and 1701 inside the tunnel | Exposing 1701 to the internet |
| PPTP | TCP 1723 and IP protocol 47 | Writing a rule for TCP 47 |
これらの番号は固定の性質ではなく既定値として扱い、WireGuardインターフェースは設定が宣言した待ち受けポートを使い、OpenVPNサーバーは管理者が選んだ任意のポートに置けることを覚えておいてください。ルールを書く前にサーバー設定を読みましょう。1194向けに開けたファイアウォールは、443へ移したサーバーには何の役にも立ちません。
三列目こそ、変更チケットの多くがつまずく場所です。ルールは存在しますが、宛先、方向、またはトランスポートが間違っています。
GREとESPはプロトコル番号であり、ポートではない
GREとESPにはポートがまったくないため、ポート番号しか受け付けないファイアウォールの入力欄では表現できません。GREはIPプロトコル47、ESPはIPプロトコル50で、どちらもIPヘッダーのプロトコルフィールドで照合します。TCPポート47として書いたルールは何にも一致せず、こうしてPPTPのポリシーは正しく見えながら、ハンドシェイク後のパケットをすべて落とします。
家庭用ルーターはこれをパススルーのチェックボックスで隠し、プロトコルのルールと、GREではフローを対応付けるためのNATヘルパーを入れます。本物のファイアウォールでは、PPTPサーバーへIPプロトコル47を、IPsecゲートウェイへIPプロトコル50を自分で許可します。プラットフォームにプロトコル欄がない場合の逃げ道がカプセル化であり、IKEv2がUDP 4500へ戻れるのも、OpenVPNとWireGuardがこの問題に当たらないのもそのためです。
クライアントを責める前に、ルールが実際に何に一致しているかを確認します。ゲートウェイでゼロのままのパケットカウンターは、ルールが一度も発動していないことを示し、クライアント側で何度入れ直しても変わりません。
方向、状態、NATが答えを変える
外向きに接続するクライアントと内向きに待ち受けるゲートウェイは別の要件であり、同じポート一覧が一方では正しく、他方では間違っていることがあります。状態を持つファイアウォールは500と4500のUDPフローを追跡し、二つ目のルールなしで応答を戻します。ESPとGREはポートを持たないため、NAT装置には手がかりがなく、セッションを追うにはヘルパーかカプセル化が必要です。
NATトラバーサルが見落とされる部分です。IKEv2はUDP 500で始まり、NAT装置を検出してUDP 4500で続けるため、500だけを許可するポリシーでは確立後に沈黙するトンネルになります。L2TP/IPsecも同じ動きをします。キャプチャに最初のやり取りだけが写り、継続的な通信がない場合は、500で止まるルールを探してください。
各ルールに方向を記録します。「UDP 4500を許可」はどこからどこへかを言うまで意味を持たず、移動するクライアントに正しいルールは通常サイト間ピアには間違っています。
各経路をキャプチャで確認する
キャプチャはクライアントではなくゲートウェイで取ります。クライアントは届いたものしか記録しないので、次のフィルターは上記の方式を網羅し、欠けている段階を示します：
sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50出力は順序として読みます。交渉は現れるのにペイロードのプロトコルが現れないなら、ドロップはクライアントとゲートウェイの間のどこかで起きています。両方が現れてなおページが失敗するなら、ファイアウォールはもう容疑者ではありませんから、ルーティング、DNS、クライアントに渡されたアドレスプールを見てください。
tcpdumpのない環境では、同じ証拠がインターフェースとルールのカウンターから得られます。トンネルインターフェースで受信はあるのに送信がない場合は、最初の許可ルールではなく戻り経路を指しています。
説明できるルールセットを残す
TCP 443のSSTPは、ポートベースのフィルターには通常のHTTPSと区別できず、ネットワークがWeb通信だけを許可する場合の狙いがまさにそこにあります。443のルールで宛先をインターネット全体ではなくゲートウェイにするべき理由もそこにあります。トンネルが動いたら一時的な全許可ルールはすぐ削除します。どのルールが一致したか、プロトコル番号がある場合はその番号、そして方向を書き残し、次の人が証拠から始められるようにします。
クラウドのポイント対サイトゲートウェイは選択を可視化し、ダウンロードしたプロファイルは443のSSTPか500と4500のIKEv2のどちらかを使うので、実際に選ばれた方だけを開けるべきです。現代のネットワークでPPTPのためにGREの例外を作る価値はなく、携帯事業者はファイアウォールに関係なくプロトコル47を落とすことが多いからです。チケットを閉じる前に、ルールがサーバー設定のポートと一致しているか、プロトコル欄が必要な場所で設定されているか、宛先が任意のアドレスではなくゲートウェイかを確認してください。