ヘアピン NAT とは｜内部からグローバル IP でアクセスできない原因と対処

はじめに

「外部からはグローバル IP アドレス（またはドメイン名）で公開サーバーにアクセスできるのに、社内 LAN からだけアクセスできない」公開サーバーの構築後に高い確率で遭遇する、原因の分かりにくいトラブルです。ping は通る、外部の回線（スマートフォンのテザリングなど）からは見える、なのに社内からだけ繋がらない、という切り分け結果になった場合、原因はサーバーでもクライアントでもなく、NAT を行うルーター / ファイアウォールがヘアピン NAT（NAT ループバック）を構成していないこと にあります。

本記事では、この事象が発生する仕組みを変換テーブルの動きから解説し、対処を「機器側でヘアピン NAT を構成する方法」と「内部 DNS などの代替策」の 2 系統で整理します。あわせて、FortiGate・Cisco IOS/IOS XE・YAMAHA RTX の対応状況と構成方法を横断的に比較します。

なお、NAT・NAPT そのものの動作原理については、関連記事『NAT とは｜変換テーブルの仕組みと NAPT・IP マスカレードの違い』を参照してください。

先に結論を示すと、対処は 「機器でヘアピン NAT を構成する」か「内部 DNS で内部クライアントだけプライベート IP に名前解決させる」かの 2 択 です。ヘアピン NAT は構成がシンプルな一方、サーバーのアクセスログ上で内部クライアントの送信元が識別できなくなる副作用があります。アクセスログを運用・監査に使う環境では、内部 DNS 方式の採用が推奨されるケースも多く、本記事ではこの判断基準まで含めて解説します。

ヘアピン NAT とは（NAT ループバックの仕組み）

ヘアピン NAT は、NAT の内側にある端末から、同じ NAT の内側にある公開サーバーへ、NAT の外側アドレス（グローバル IP アドレス）を指定して接続できるようにする機能です。通信がルーターで髪留めのヘアピンのように鋭角に折り返されることからこの名前で呼ばれ、NAT ループバックとも呼ばれます。

参考: YAMAHA RTpro – ヘアピン NAT 機能
「NAT の内側にある端末から同じ NAT の内側にある端末に NAT の外側アドレスを指定して接続できるようにする機能」
https://www.rtpro.yamaha.co.jp/RT/docs/nat-descriptor/hairpin_nat.html

まず「なぜ普通の NAT 設定ではこの通信が成立しないのか」から確認します。ここを理解しておくと、メーカーごとの構成方法の違い（なぜ FortiGate では SNAT の併用が必要なのか、など）が腹落ちします。

内部からグローバル IP 宛にアクセスできない理由

前提として、静的 NAT（ポートフォワーディング）で公開サーバーを構成済みの、次の環境を考えます。

• ルーターの WAN 側アドレス: 203.0.113.1（グローバル IP）
• 公開サーバー: 192.168.1.80（静的 NAT で 203.0.113.1:443 → 192.168.1.80:443 を定義済み）
• 内部クライアント: 192.168.1.10

内部クライアントが 203.0.113.1:443 へアクセスすると、失敗のメカニズムは機器の実装により大きく 2 パターンに分かれます。

パターン 1: ルーターが折り返しを処理せず、パケットが破棄される

多くの機器では、静的 NAT・ポートフォワーディングの変換ルールを「WAN 側インターフェイスから入ってきたパケット」にのみ適用します。LAN 側から入ってきた 203.0.113.1 宛のパケットは変換対象にならず、ルーターは「自分自身（WAN 側インターフェイス）宛の通信」として処理します。該当ポートでルーター自身がサービスを提供していなければ、接続は拒否または破棄されます。家庭向けルーターやヘアピン NAT 非対応の機器で起きるのはこのパターンです。

パターン 2: 宛先変換はされるが、戻りパケットが非対称になり切断される

より本質的な問題がこちらです。仮に LAN 側から入ったパケットにも宛先変換（DNAT）が適用され、パケットがサーバーへ届いたとします。このときサーバーから見た送信元は、内部クライアントのアドレス 192.168.1.10 のままです。

サーバーは応答を 192.168.1.10 宛に返しますが、宛先が同一セグメントの内部アドレスであるため、応答はルーターを経由せずサーバーからクライアントへ直接届きます。クライアントの視点では、203.0.113.1 宛に送った SYN に対して、見知らぬ 192.168.1.80 から SYN/ACK が返ってくることになり、送信元の不一致として TCP セッションは成立しません（OS が RST を返す、またはパケットを無視します）

つまり、内部からの折り返し通信を成立させるには、宛先の変換（DNAT）だけでは足りません。戻りパケットを必ずルーター経由に引き戻す仕掛けが必要 であり、それがヘアピン NAT の本質です。

ヘアピン NAT の動作（折り返し変換の流れ）

ヘアピン NAT では、折り返し通信に対して宛先変換（DNAT）と送信元変換（SNAT）を 同時に 適用します。先ほどの環境での変換の流れは以下の通りです。

1. クライアント 192.168.1.10 が 203.0.113.1:443 へ SYN を送信する。
2. ルーターが宛先を 192.168.1.80:443 へ変換（DNAT）し、あわせて送信元を自身の LAN 側アドレス 192.168.1.1 へ変換（SNAT） する。
3. サーバーには「192.168.1.1 からの接続」として届く。
4. サーバーは応答を 192.168.1.1（ルーター）宛に返す。宛先がルーターであるため、応答は必ずルーターを経由する。
5. ルーターが変換テーブルに基づき、送信元を 203.0.113.1:443 に、宛先を 192.168.1.10 に戻してクライアントへ届ける。
6. クライアントから見ると「203.0.113.1:443 と正常に通信できている」状態になる。

ポイントは手順 2 の SNAT です。送信元をルーター自身のアドレスに書き換えることで、戻りパケットを強制的にルーター経由へ引き戻し、非対称ルーティングを解消 しています。この仕組みは、FortiGate でヘアピン構成を組む際にポリシーで NAT（SNAT）を有効化する理由、そして後述する「サーバーのアクセスログから内部クライアントを識別できなくなる」副作用の理由に直結します。

なお、機器によってはこの折り返し変換を専用機能として自動処理するもの（YAMAHA RTX のヘアピン NAT 機能など）と、DNAT・SNAT の設定を明示的に組み合わせて実現するもの（FortiGate など）があり、構成の考え方がメーカーで異なります。この違いが後半のメーカー別セクションの主題です。

ヘアピン NAT を使わない代替策

ヘアピン NAT は「グローバル IP 宛の折り返し通信」を機器側で成立させる解決策ですが、そもそも 内部クライアントにプライベート IP へ直接アクセスさせれば、折り返し自体が不要 になります。構成によってはこちらの方が筋の良い解決策となるため、機器別の設定に入る前に代替策を整理します。

内部 DNS（スプリット DNS）による解決

同じドメイン名（FQDN）に対して、内部と外部で異なる名前解決の結果を返す構成です。スプリット DNS またはスプリットブレイン DNS と呼ばれます。

• 外部のクライアント: パブリック DNS が www.example.jp → 203.0.113.1（グローバル IP）を返す
• 内部のクライアント: 社内 DNS サーバーが www.example.jp → 192.168.1.80（プライベート IP）を返す

内部クライアントは最初からプライベート IP 宛に通信するため、ルーターでの折り返しは発生しません。この方式には、ヘアピン NAT にはない明確な利点が 2 つあります。

• サーバーのアクセスログに内部クライアントの実 IP アドレスが記録される（ヘアピン NAT では後述の通り送信元がルーターのアドレスに置き換わります）
• NAT 機器の機能・性能に依存しない（折り返しトラフィックがルーターを通らないため、機器の対応可否や負荷を考慮する必要がありません）

一方で、社内 DNS サーバーの構築・運用が前提となること、ドメイン名ではなく グローバル IP アドレスを直接指定するアクセスには効果がない ことが制約です。また、近年はブラウザーの DNS over HTTPS（DoH）などにより端末が社内 DNS を経由せず名前解決するケースがあり、内部 DNS 方式を採用する場合は端末側の名前解決経路の統制もセットで検討する ことが推奨されます。

Active Directory 環境であれば AD DNS への A レコード追加、小規模環境であればルーター内蔵の DNS 機能や dnsmasq などで実現できます。

hosts ファイルによる回避と使いどころ

クライアント端末の hosts ファイルに 192.168.1.80 www.example.jp を記述する方法です。DNS サーバーの構築が不要で即座に効果が出るため、検証時の一時的な回避策や、対象端末が数台に限られる場合 には合理的な選択です。

ただし恒久策としては推奨されません。端末を社外に持ち出すと hosts の記述が邪魔をして外部からのアクセスに失敗する、スマートフォン（特に iOS）では hosts の編集が事実上できない、端末が増えるたびに設定が必要になる、といった運用上の限界があるためです。

3 つの解決策の使い分けは以下の通りです。

メーカー別の対応状況と設定例

ここからは、ヘアピン NAT を機器側で構成する方法をメーカー別に解説します。第 1 章で整理した通り、ヘアピン NAT の本質は「折り返し通信への DNAT と SNAT の同時適用」ですが、これを明示的なポリシー設計で実現する機器（FortiGate）と、専用機能として自動処理する機器（YAMAHA RTX・NEC IX）があり、構成の考え方が異なります。

FortiGate（VIP とポリシーによる構成）

FortiGate にはヘアピン NAT の専用機能はなく、VIP と通常のファイアウォールポリシーの組み合わせ で実現します。FortiOS の Administration Guide にも Hairpin NAT の構成例が公式に掲載されています。

参考: FortiOS – Hairpin NAT（Administration Guide）
“Hairpin NAT ensures consistency, avoiding confusion and complications in network configurations”
（ヘアピン NAT は、内外どちらからも同じ宛先でアクセスできる一貫性を保ち、ネットワーク構成の混乱を避けます）
https://docs.fortinet.com/document/fortigate/8.0.0/administration-guide/736522/hairpin-nat

構成のポイントは 2 つです。

ポイント 1: VIP の extintf は any にする

VIP の待ち受けインターフェイスを WAN に限定していると、GUI 上で LAN 起点のポリシーに VIP を割り当てられず、ヘアピン構成が組めません。ヘアピン NAT を想定する VIP は extintf any で作成します。

config firewall vip
    edit "VIP-WebServer"
        set extip 203.0.113.1                   # 公開用グローバル IP
        set extintf "any"                       # ヘアピン構成では any にする
        set mappedip "192.168.1.80"
    next
end

ポイント 2: LAN 起点の折り返しポリシーを追加し、必要に応じて NAT（SNAT）を有効化する

外部公開用のポリシー（wan → internal）とは別に、内部クライアント起点のポリシーを追加します。宛先には VIP オブジェクトを指定します。

config firewall policy
    edit 20
        set name "LAN-Hairpin-to-WebServer"
        set srcintf "internal"                  # クライアント側インターフェイス
        set dstintf "internal"                  # サーバー側インターフェイス
        set srcaddr "LAN-Subnet"
        set dstaddr "VIP-WebServer"             # VIP オブジェクトを宛先に指定
        set action accept
        set schedule "always"
        set service "HTTPS"
        set nat enable                          # 同一セグメント折り返しでは有効化が必要
    next
end

ここで重要なのが set nat enable（SNAT）の要否です。判断基準は 「サーバーからの戻りパケットが FortiGate を経由するかどうか」 です。

クライアントとサーバーが同一セグメント（同一インターフェイス配下の同一サブネット）の場合

SNAT の有効化が必要です。無効のままだと、先ほど解説した戻りパケットの非対称が発生し、セッションが成立しません。

サーバーが別インターフェイス・別セグメント（DMZ など）にいる場合

SNAT なしでも動作します。戻りパケットは経路上必ず FortiGate を通るためです。この構成では SNAT を無効にしておくと、サーバーのアクセスログに内部クライアントの実 IP アドレスが残る 利点があります。

参考: Fortinet Community – Technical Tip: How to access VIP from LAN machine with a hairpin NAT through the GUI
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-access-VIP-from-LAN-machine-with-a-hairpin/ta-p/265457

つまり FortiGate では、ネットワーク設計（サーバーを DMZ に分離しているか）によってヘアピン NAT の副作用の大きさが変わります。動作しない場合の切り分けは diagnose debug flow で「DNAT の発生」と「マッチしたポリシー ID」を確認するのが近道です。VIP・ポリシー・確認コマンドの基本は、関連記事『FortiGate NAT 設定の手順｜VIP と IP Pool の使い分けと確認コマンド』で解説しています。

なお、LAN からの全通信をインターネットへ向けるポリシールートを構成している環境では、DNAT 後のパケットがポリシールートに引かれて WAN 側へ流れ、ヘアピンが成立しないケースがあります。ポリシールート利用環境では、VIP 宛の通信を除外する設計が必要です。

Cisco IOS/IOS XE（対応の制約と考え方）

Cisco ルーターのヘアピン NAT は、OS の世代によって対応状況が明確に分かれます。結論から言うと、従来 IOS には対応手段（NVI）がありましたが、現行の IOS XE には標準的な構成手段がありません。

従来 IOS: NVI（NAT Virtual Interface）で対応可能

従来 IOS では、IOS 12.3(14)T で導入された NVI がヘアピン通信に対応していました。NVI は inside/outside のドメイン指定を廃した NAT 方式で、インターフェイスに ip nat enable を設定し、変換ルールを ip nat source（inside/outside キーワードなし）で定義します。

参考: CiscoZine – NAT Virtual Interface aka NVI, what is that?!
“removes the requirements to configure an interface as either NAT inside or outside”
（NVI は、インターフェイスを NAT の inside または outside として設定する要件を取り除きます）
https://www.ciscozine.com/nat-virtual-interface-aka-nvi-what-is-that/

NVI では変換がルーティング決定後に一律で適用されるため、「inside から inside へ折り返す」通信も特別な設定なしで変換されます。従来 IOS 機（ISR G2 世代など）でヘアピンが必要な場合の解でした。

IOS XE: NVI 非対応のため、標準的なヘアピン構成手段がない

現行の IOS XE（ISR 4000 / Catalyst 8000 シリーズなど）では、NVI の中核である ip nat source list コマンドがサポートされていません。インターフェイスで ip nat enable が受け付けられる場合がありますが、NVI としては機能しません。Cisco Community でも、IOS XE 機でのヘアピン要件に対しては、ループバックインターフェイスとポリシーベースルーティング（PBR）を組み合わせた回避構成が議論されているのが実情です。

参考: Cisco Community – C8300 IOS-XE NAT Hairpinning
https://community.cisco.com/t5/routing/c8300-ios-xe-nat-hairpinning/td-p/4837880

ただし、この回避構成は PBR による強制的な経路曲げを伴い、構成の複雑さとトラブルシューティングの難易度が上がります。IOS XE 環境でヘアピン要件が出た場合は、機器側で無理に折り返すのではなく、内部 DNS（スプリット DNS）方式を第一候補として検討する ことを推奨します。前章で整理した通り、内部 DNS 方式にはサーバーログの観点でも利点があります。

なお、静的 NAT・PAT の基本設定と変換テーブルの確認方法は、関連記事『Cisco NAT 設定の手順｜静的 NAT と PAT（overload）の使い分け』で解説しています。

YAMAHA RTX（ヘアピン NAT 機能と対応条件）

YAMAHA ルーターは、ヘアピン NAT を 専用機能として公式サポート しています。RTpro に専用の技術ドキュメントがあり、対応機種・設定例・制約が明記されています。3 社の中で最もドキュメントが充実しているメーカーです。

参考: YAMAHA RTpro – ヘアピン NAT 機能
https://www.rtpro.yamaha.co.jp/RT/docs/nat-descriptor/hairpin_nat.html

対応機種とファームウェア

機種	ファームウェア
vRX さくらのクラウド版 / RTX840 / RTX3510	すべてのリビジョン
RTX1300	Rev.23.00.03 以降
RTX1220	Rev.15.04.04 以降
RTX830	Rev.15.02.24 以降
NVR510	Rev.15.01.23 以降
NVR700W	Rev.15.00.23 以降

RTX1210 以前の旧機種はこの機能を持たないため、旧機種でヘアピン要件がある場合は、ファームウェアではなく機器更改または内部 DNS での対応 になります。

設定方法

NAT ディスクリプターのタイプ定義に hairpin=on オプションを付与するだけです。固定グローバル IP・LAN2 接続で Web サーバーを公開する場合の設定例は以下の通りです（公式ドキュメントの設定例に基づきます）。

ip lan1 address 192.168.100.1/24
ip lan2 address 203.0.113.1/24
ip lan2 nat descriptor 1
nat descriptor type 1 masquerade hairpin=on
nat descriptor address outer 1 primary
nat descriptor masquerade static 1 1 192.168.100.200 tcp 80

hairpin=on を設定した NAT ディスクリプターがインターフェイスに適用されリンクアップすると、折り返し用の暗黙経路が自動生成されます。show ip route で hairpin:1 の付加情報を持つホスト経路が確認できれば、機能が有効になっています。

show ip route
宛先ネットワーク  ゲートウェイ   インタフェース  種別      付加情報
192.168.100.0/24  192.168.100.1  LAN1            implicit
203.0.113.1/32    203.0.113.1    LAN2            implicit  hairpin:1

動作の仕組みも先ほど解説した原理通りで、折り返し時に送信元が IP マスカレードにより NAT 外側アドレスへ変換されるため、戻りパケットの非対称は発生しません（同時に、サーバーから見た送信元はルーターのアドレスになります）。

主な制約（公式ドキュメント記載）

• 順方向に適用した NAT ディスクリプターでのみ動作します（逆方向適用では動作しません）。
• SIP パケットには対応していません。
• ルーター自身が発するパケットには適用されません。
• 外側アドレスの個数に上限があります（1 インターフェイスあたり 256 個まで、全インターフェイス合計 512 個まで）

このほか、MAP-E / DS-Lite 環境での利用可否という重要な制約がありますが、これは後の制約事項セクションでまとめて解説します。

NEC IX（ip napt hairpinning による構成）

NEC IX シリーズもヘアピン NAT を公式サポートしています。IX-R / IX-V シリーズの機能説明書に仕様が明記されており、設定は WAN 側インターフェイスへの ip napt hairpinning の 1 行です。

参考: NEC – IX-R/IX-V 機能説明書 2.12. NAT/NAPT の設定
「ヘアピンNAT機能を有効にすることで、同一プライベートネットワークの端末同士がグローバアドレスを用いて通信することが可能です」
https://support.necplatforms.co.jp/ix-nrv/manual/fd/02_router/13-2_nat.html

静的 NAPT で Web サーバーを公開している構成にヘアピン NAT を追加する設定例は以下の通りです。

interface GigaEthernet0.0
  ip address dhcp receive-default
  ip napt enable
  ip napt hairpinning                # ヘアピン NAT の有効化（WAN 側に設定）
  ip napt static 192.168.1.80 tcp 443
  no shutdown

主な制約（公式ドキュメント記載）

• ヘアピン NAT が適用されるのは TCP・UDP・ping のパケットのみです。
• 1 装置につき 1 インターフェイスのみ設定できます。1 インターフェイスに複数の NAPT を設定した環境ではサポートされません。
• 変換対象は ip napt address コマンドで指定したアドレス宛のパケットのみです（未設定の場合はインターフェイスのプライマリアドレス）。
• UNIVERGE IX-V シリーズをクラウドで利用する場合は、ヘアピン NAT を利用できません。

従来の IX2000 / 3000 シリーズ（IX2215 など）でも ip napt hairpinning コマンドはコマンドリファレンス（Ver.10 系）に記載がありますが、対応はファームウェアバージョンに依存するため、使用機種・バージョンのコマンドリファレンスでの確認が推奨されます。

メーカー別対応状況の比較

3 社（4 系統）の対応状況をまとめると以下の通りです。

制約事項・設計上の注意

ヘアピン NAT は「繋がらない」を解決する便利な機能ですが、採用にあたって把握しておくべき副作用と環境制約があります。特に 1 点目は、構成が動いた後に気づくと手戻りが大きいポイントです。

サーバーのアクセスログから内部クライアントを識別できなくなる

ヘアピン NAT の折り返し通信では送信元がルーター / ファイアウォールのアドレスに変換されます。その結果、公開サーバーのアクセスログ上、内部クライアントからのアクセスはすべて同一の送信元（ルーターのアドレス）として記録されます。

この状態では、アクセス解析で内部利用の実態が見えなくなるだけでなく、セキュリティインシデント調査の際に「どの端末からのアクセスか」をサーバーログから遡れない という監査上の問題が生じます。対応の方向性は以下の通りです。

• ログ・監査要件がある環境では、内部 DNS（スプリット DNS）方式を第一候補とする。
• FortiGate でサーバーが DMZ など別セグメントにある構成では、折り返しポリシーの SNAT を無効にする（クライアントの実 IP がサーバーに届きます）。
• ヘアピン NAT を採用する場合は、NAT 機器側の変換ログ（セッションログ）を保全し、サーバーログと突合できる体制を整える。

MAP-E / DS-Lite（IPoE）環境では利用できない場合がある

IPoE 接続で MAP-E や DS-Lite を利用する環境では、そもそもヘアピン NAT が利用できない、または前提から成立しないケースがあります。YAMAHA の公式ドキュメントでは以下が明記されています。

• MAP-E で IP アドレスを共有する契約（一般的な「v6 プラス」等）では、ヘアピン NAT 機能を利用できません。固定 IP を使用する契約では利用できます。
• DS-Lite を利用する構成では、ヘアピン NAT 機能を利用できません。

MAP-E（IP 共有）や DS-Lite では、利用できるポートが制限される・IPv4 の NAT がキャリア側で行われるといった方式上の制約があり、公開サーバーの構成自体に工夫が必要です。IPoE 方式ごとの違いは、関連記事『IPoE（MAP-E・DS-Lite）の仕組みと PPPoE との違い｜方式の選び方と機種対応』を参照してください。

折り返しトラフィックはすべて NAT 機器を往復する

ヘアピン NAT では、本来同一セグメント内で完結するはずの通信が、ルーター / ファイアウォールを往復し、往路・復路で NAT 変換を受けます。クライアントとサーバーが同じスイッチ配下にあっても、トラフィックは必ず NAT 機器まで上がってから折り返します。内部クライアントから公開サーバーへの大容量転送（バックアップ、ファイル共有など）が定常的にある環境では、NAT 機器の帯域・セッション処理への負荷を考慮する必要があります。この観点でも、内部トラフィックを機器に上げない内部 DNS 方式に分があります。

プロトコルによっては折り返しが機能しない

前章で触れた通り、YAMAHA は SIP パケット非対応、NEC IX は TCP・UDP・ping のみ対応という制約があります。また、ペイロードに IP アドレスを埋め込むプロトコル（FTP・SIP など）は ALG の対応状況に依存します。Web（HTTP/HTTPS）以外のプロトコルで折り返しを構成する場合は、対象プロトコルの対応可否を事前に確認する ことが推奨されます。

まとめ

本記事では、「外部からはアクセスできるのに内部からだけアクセスできない」という NAT 環境の定番トラブルを、ヘアピン NAT の仕組みからメーカー別の対応まで整理しました。原因が戻りパケットの非対称にあることを理解しておけば、各メーカーの構成方法の違いも、SNAT 併用によるログの副作用も、同じ原理から導けます。

• 原因は戻りパケットの非対称、解決には DNAT と SNAT の同時適用が必要
• 対処はヘアピン NAT の構成か内部 DNS（スプリット DNS）の 2 択
• SNAT の併用によりサーバーログの送信元はルーターのアドレスに置き換わる
• ログ・監査要件のある環境では内部 DNS 方式が有力
• FortiGate は VIP と折り返しポリシー、YAMAHA は hairpin=on で構成
• Cisco IOS XE に標準手段はなく内部 DNS の検討を推奨
• MAP-E（IP 共有）や DS-Lite の環境ではヘアピン NAT を利用不可

以上、最後までお読みいただきありがとうございました。