FortiGate NAT 設定の手順｜VIP と IP Pool の使い分けと確認コマンド

2026年5月23日2026年8月17日

URLをコピーしました！

はじめに

FortiGate で NAT を設定する方法は 1 つではありません。ファイアウォールポリシー内で NAT を有効化する方式（ポリシー NAT）と、変換ルールを独立したテーブルで一元管理する方式（セントラル NAT）の 2 方式があり、どちらを採用するかで設定箇所・運用手順・トラブルシューティングの勘所が大きく変わります。また、送信元を変換する SNAT には IP Pool、宛先を変換する DNAT には VIP（Virtual IP）という専用オブジェクトが用意されており、それぞれに複数のタイプ・オプションが存在します。

本記事では、FortiOS 7.6 系 を前提に、FortiGate の NAT 設定を SNAT（IP Pool）・DNAT（VIP）・セントラル NAT の順で整理し、CLI 設定例と確認コマンドまでを解説します。

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

この記事でわかること

FortiGate における SNAT と DNAT の役割と、対応するオブジェクト（IP Pool / VIP）の関係
ポリシー NAT とセントラル NAT の違いと、どちらを選ぶべきかの判断基準
IP Pool の 4 タイプ（Overload / One-to-One / Fixed Port Range / PBA）の使い分け
静的 VIP・ポートフォワーディングの CLI 設定手順
セッションテーブルと diagnose debug flow を使った NAT 動作の確認・切り分け手順

先に結論を示すと、一般的な拠点ファイアウォール用途であれば、デフォルトのポリシー NAT 方式で十分に構成できます。一方、変換ルールが多数あり送信元・ポート単位で細かく制御したい場合や、NGFW ポリシーベースモードを使用する場合は、セントラル NAT の採用を検討することが推奨されます。両方式は排他であり、切り替えには既存設定の整理が必要となるため、設計初期にどちらで運用するかを決めておくことが重要です。

FortiGate の NAT の全体像

FortiGate の NAT を理解するには、「通信のどの方向を変換するか（SNAT / DNAT）」と「変換ルールをどこで定義するか（ポリシー NAT / セントラル NAT）」の 2 つの軸で整理すると見通しが良くなります。このセクションでは、個別の設定手順に入る前に全体像を押さえます。

SNAT と DNAT の役割整理

SNAT（Source NAT）は送信元 IP アドレスの変換 です。典型例は、社内 LAN のプライベート IP アドレスをインターネット向けのグローバル IP アドレスに変換する、いわゆる出口方向の NAT です。FortiGate では、ファイアウォールポリシーの NAT オプション、または後述の IP Pool を用いて設定します。

最も基本的な構成は、出力インターフェイスの IP アドレスに変換する方式です。この方式では、すべての内部 IP アドレスが単一のグローバル IP アドレスに集約され、ポート番号で個々のセッションを識別します。

参考: FortiOS 7.6 – Static SNAT
“all internal IP addresses are always mapped to the same public IP address”
（すべての内部 IP アドレスは、常に同一のパブリック IP アドレスにマッピングされます）
https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/898655/static-snat

DNAT（Destination NAT）は宛先 IP アドレスの変換 です。典型例は、インターネットから届いたグローバル IP アドレス宛の通信を、DMZ や社内のサーバーが持つプライベート IP アドレスに転送する、いわゆる公開サーバー向けの NAT です。FortiGate では VIP（Virtual IP）オブジェクトとして定義します。

役割と対応オブジェクトの関係は以下の通りです。

変換の種類	変換対象	主な用途	使用するオブジェクト・設定
SNAT	送信元 IP アドレス	LAN からインターネットへの通信	ポリシーの NAT オプション / IP Pool
DNAT	宛先 IP アドレス	インターネットから公開サーバーへの通信	VIP（Virtual IP）

なお、1 つの通信に SNAT と DNAT の両方を適用する構成（Double NAT）も可能です。拠点間で IP アドレスが重複する環境での実例は、関連記事『FortiGate IPsec VPN の構築手順｜IKEv2 と NAT 越えの設定例』で解説しています。

ポリシー NAT とセントラル NAT の 2 方式と選び方

FortiGate には、NAT ルールを定義する場所が異なる 2 つの動作モードがあります。

ポリシー NAT（デフォルト） は、ファイアウォールポリシーの中で NAT を有効化する方式です。「この通信を許可し、あわせて送信元を変換する」という形で、通信制御と NAT が 1 つのポリシーに同居します。設定箇所が 1 か所に集約されるため直感的で、小〜中規模構成ではこちらが標準的な選択です。

セントラル NAT は、config system settings で central-nat を有効化すると切り替わる方式です。SNAT ルールはファイアウォールポリシーから分離され、central-snat-map という専用テーブルで一元管理されます。

参考: FortiOS 7.6 – Central SNAT
“If central NAT is enabled, the NAT option under IPv4 policies is skipped”
（セントラル NAT を有効化すると、IPv4 ポリシー配下の NAT オプションはスキップされます）
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/421028/central-snat

セントラル NAT では、変換ルールが上から順に評価され、送信元アドレス・宛先アドレス・ポート範囲の組み合わせごとに「どの IP Pool を使うか」を細かく指定できます。また、NGFW ポリシーベースモードを使用する場合は、セントラル NAT（SNAT）が暗黙的に有効となります。

DNAT 側にも違いがあります。ポリシー NAT では VIP をファイアウォールポリシーの宛先として指定しますが、セントラル NAT モードでは VIP はポリシーに紐付けず、独立したオブジェクトとして有効化した時点で変換が機能します。この挙動差は、モード切り替え時の移行作業やトラブルシューティングに直結するため、後のセクションで改めて取り上げます。

2 方式の比較と選定基準は以下の通りです。

比較軸	ポリシー NAT（デフォルト）	セントラル NAT
SNAT の定義場所	ファイアウォールポリシー内	central-snat-map（専用テーブル）
VIP（DNAT）の扱い	ポリシーの宛先に指定	独立オブジェクトとして機能
ポート単位の変換制御	限定的	送信元・宛先・ポート範囲で細かく制御可能
NGFW ポリシーベースモード	使用不可	暗黙的に有効化される
向いている環境	小〜中規模の一般的な構成	変換ルールが多数ある環境、通信制御と NAT を分離して運用したい環境

両方式は併用できず、どちらか一方を選択する排他の関係 です。運用途中の切り替えは可能ですが、ポリシーに割り当て済みの VIP の解除など移行作業が発生するため（詳細はセントラル NAT のセクションで解説）、設計初期の方式決定が重要になります。

SNAT の設定手順（IP Pool）

FortiGate の SNAT は、「出力インターフェイスの IP アドレスに変換する基本方式」と「IP Pool で変換後アドレスを明示的に指定する方式」の 2 段階で理解すると整理しやすくなります。まず基本方式を押さえ、次に IP Pool の 4 タイプを確認します。

出力インターフェイス IP による変換（基本）

最も基本的な SNAT は、ファイアウォールポリシーで NAT を有効化するだけの構成です。この場合、送信元 IP アドレスは出力インターフェイス（WAN 側）の IP アドレスに変換されます。GUI では「Policy & Objects → Firewall Policy」でポリシーを作成し、NAT を有効化して「Use Outgoing Interface Address」を選択します。

CLI では以下のように設定します。

config firewall policy
    edit 1
        set name "LAN-to-Internet"
        set srcintf "internal"                  # LAN 側インターフェイス
        set dstintf "wan1"                      # WAN 側インターフェイス
        set srcaddr "LAN-Subnet"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable                          # 出力インターフェイス IP への SNAT
    next
end

参考: FortiOS 7.6 – Static SNAT
https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/898655/static-snat

この方式では、すべての内部ホストが 1 つのグローバル IP アドレスを共有し、ポート番号でセッションを識別します。公式ドキュメントでは、1 つのパブリック IP アドレスあたり約 60,416 個のポート番号が利用可能とされており、一般的な拠点規模であれば十分な収容力です。ただし、多数のクライアントが同一宛先へ大量のセッションを張る環境ではポート枯渇のリスクがある ため、後述の IP Pool による分散を検討します。

なお、送信元ポートを変換せずに維持したい場合（特定の送信元ポートを前提とするサービス向け）は、ポリシーで set port-preserve enable を指定します。

IP Pool の 4 タイプ（Overload / One-to-One / Fixed Port Range / PBA）

変換後の IP アドレスを出力インターフェイスとは別のアドレスにしたい場合や、変換方式を制御したい場合は、IP Pool オブジェクトを作成してポリシーに適用します。IP Pool には 4 つのタイプがあります。

タイプ	変換方式	ポート変換	主な用途
Overload（デフォルト）	プール内のアドレスを複数クライアントで共有	あり（NAPT）	変換元アドレスを WAN インターフェイスと別にしたい一般用途
One-to-One	内部アドレスと 1 対 1 で対応	なし	相手側に見せる送信元 IP を固定したい対外接続
Fixed Port Range	クライアントごとに固定のポート範囲を割り当て	あり（範囲固定）	変換ログから発信元を特定しやすくしたい環境
Port Block Allocation（PBA）	クライアントごとにポートブロックを動的割り当て	あり（ブロック単位）	多数クライアント収容とログ量削減を両立したい環境

各タイプの CLI 設定例は以下の通りです。

Overload（デフォルト）

config firewall ippool
    edit "Pool-Overload"
        set type overload                       # 省略時のデフォルト
        set startip 203.0.113.10
        set endip 203.0.113.11
    next
end

One-to-One

config firewall ippool
    edit "Pool-OneToOne"
        set type one-to-one
        set startip 203.0.113.20
        set endip 203.0.113.29                  # 変換対象の内部ホスト数分を確保
    next
end

One-to-One では内部アドレスの若い順にプールの若いアドレスから対応付けられるため、ポリシーの送信元アドレスオブジェクトはプールのアドレス数と揃えて定義する ことが推奨されます。プール数を超えた内部ホストの通信は変換できません。

Fixed Port Range

config firewall ippool
    edit "Pool-FPR"
        set type fixed-port-range
        set startip 203.0.113.30
        set endip 203.0.113.31
        set source-startip 192.168.1.1          # 変換対象の内部アドレス範囲
        set source-endip 192.168.1.100
    next
end

Fixed Port Range は、内部アドレス範囲と変換後アドレス範囲の対応から、クライアントごとの割り当てポート範囲が一意に決まる方式です。変換後の IP アドレスとポート番号から発信元クライアントを逆引きしやすく、監査・トレーサビリティ要件のある環境に向いています。

Port Block Allocation（PBA）

config firewall ippool
    edit "Pool-PBA"
        set type port-block-allocation
        set startip 203.0.113.40
        set endip 203.0.113.41
        set block-size 128                      # 1 ブロックあたりのポート数
        set num-blocks-per-user 1               # クライアントあたりの初期ブロック数
    next
end

PBA はクライアントの初回通信時にポートブロックを割り当て、ブロックを使い切ると次のブロックを追加割り当てする方式です。セッション単位ではなくブロック単位でログを記録できるため、多数のクライアントを収容する環境で NAT ログの量を抑制できます。

また、FortiOS 7.6 では Fixed Port Range と PBA の両タイプで、割り当てに使用するポート範囲そのものを指定できるようになりました。

参考: FortiOS 7.6 New Features – Custom port ranges for PBA and FPR IP pools
“Administrators can now configure custom port ranges from 1024 to 65535”
（管理者は 1024〜65535 の範囲でカスタムポート範囲を設定できるようになりました）
https://docs.fortinet.com/document/fortigate/7.6.0/new-features/769882/custom-port-ranges-for-pba-and-fpr-ip-pools

config firewall ippool
    edit "Pool-PBA"
        set startport 1024                      # FortiOS 7.6 以降で指定可能
        set endport 65535
    next
end

ファイアウォールポリシーへの適用

作成した IP Pool は、ファイアウォールポリシーの NAT 設定で参照します。set nat enable に加えて set ippool enable と set poolname の指定が必要 です。ippool enable を忘れると、プールではなく出力インターフェイスの IP アドレスで変換されるため注意が必要です。

config firewall policy
    edit 2
        set name "LAN-to-Internet-Pool"
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "LAN-Subnet"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set nat enable
        set ippool enable                       # IP Pool を使用する宣言
        set poolname "Pool-Overload"            # 作成済みプール名を指定
    next
end

適用時の設計上の注意点として、IP Pool のアドレスに対する ARP 応答の挙動があります。IP Pool（および VIP）には arp-reply オプション（デフォルト有効）があり、有効時は FortiGate がプール内アドレスへの ARP 要求に応答します。出力インターフェイスと同一セグメントのアドレスをプールに割り当てる場合は原則そのままで動作しますが、別セグメントのアドレスを割り当てる場合は、対向ルーター側でプールアドレス宛の経路を FortiGate に向ける設計が必要です。

参考: Fortinet Community – Technical Tip: ARP reply setting in Virtual IP/IP Pool
https://community.fortinet.com/t5/FortiGate/Technical-Tip-ARP-reply-setting-in-Virtual-IP-IP-Pool/ta-p/192527

DNAT の設定手順（VIP）

インターネット側から届いた通信を内部サーバーへ転送する DNAT は、VIP（Virtual IP）オブジェクトで定義します。VIP には、全ポートを転送する「静的 VIP（1 対 1 変換）」と、特定ポートのみを転送する「ポートフォワーディング」の 2 つの使い方があります。

静的 VIP（1 対 1 変換）の設定

外部 IP アドレス宛の通信を、ポートを限定せずすべて内部サーバーへ転送する構成です。GUI では「Policy & Objects → Virtual IPs」で作成します（セントラル NAT 有効時は「DNAT & Virtual IPs」に画面が変わります）

CLI では以下のように設定します。

config firewall vip
    edit "VIP-WebServer"
        set extip 203.0.113.100                 # 外部（公開）IP アドレス
        set extintf "any"                       # 待ち受けインターフェイス
        set mappedip "192.168.1.80"             # 転送先の内部サーバー IP
    next
end

作成した VIP は、ファイアウォールポリシーの 宛先アドレス（dstaddr）に指定 します。これが「VIP はポリシーの宛先として使う」というポリシー NAT 方式の基本形です。

config firewall policy
    edit 10
        set name "Internet-to-WebServer"
        set srcintf "wan1"
        set dstintf "internal"
        set srcaddr "all"
        set dstaddr "VIP-WebServer"             # VIP オブジェクトを宛先に指定
        set action accept
        set schedule "always"
        set service "HTTPS"                     # 許可するサービスは必要最小限に絞る
    next
end

参考: FortiOS 7.6 – Static virtual IPs
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/510402/static-virtual-ips

このポリシーで set nat enable を追加すると、宛先変換とあわせて送信元も内部インターフェイス側のアドレスに変換されます。サーバーのアクセスログに実際のクライアント IP アドレスを記録したい場合は NAT を無効のままにし、サーバーのデフォルトゲートウェイが FortiGate 以外を向いている場合のみ有効化を検討する、という使い分けが実務的です。

なお、社内 LAN から公開用のグローバル IP アドレス（VIP の外部アドレス）宛にアクセスすると通信できない、という事象は VIP 構成で頻出のトラブルです。この解決にはヘアピン NAT の構成が必要となります。詳細は関連記事『ヘアピン NAT とは｜内部からグローバル IP でアクセスできない原因と対処』で解説予定です。

ポートフォワーディングの設定

1 つのグローバル IP アドレスで複数のサーバーを公開したい場合や、外部公開ポートと内部サーバーのポートを変えたい場合は、ポートフォワーディングを使用します。

config firewall vip
    edit "VIP-Web-8443"
        set extip 203.0.113.100
        set extintf "any"
        set portforward enable                  # ポートフォワーディングを有効化
        set protocol tcp
        set extport 8443                        # 外部公開ポート
        set mappedip "192.168.1.81"
        set mappedport 443                      # 内部サーバーの実ポート
    next
end

この例では、203.0.113.100:8443 宛の通信が 192.168.1.81:443 へ転送されます。ポリシーへの適用方法は静的 VIP と同じで、宛先アドレスに VIP オブジェクトを指定します。同一の外部 IP アドレスに対して外部ポート違いの VIP を複数作成すれば、1 つのグローバル IP アドレスで複数サーバーの公開が可能です。

VIP 設計上の重要な注意点 として、VIP や IP Pool は arp-reply が有効（デフォルト）の場合、ポリシーで未使用であっても FortiGate 自身のローカルアドレスとして扱われます。

参考: FortiOS 7.6 – Static virtual IPs
“the FortiGate considers it as a local address and will not forward traffic”
（FortiGate はそのアドレスをローカルアドレスとみなし、ルーティングテーブルに基づく転送を行いません）
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/510402/static-virtual-ips

つまり、検証などで作成したまま放置された VIP が、本来ルーティングされるべき通信を意図せず吸い込む 可能性があります。使用しない VIP・IP Pool は削除しておくことが推奨されます。

セントラル NAT の設定手順

第 1 回で整理した通り、セントラル NAT は SNAT ルールをファイアウォールポリシーから分離し、専用テーブルで一元管理する方式です。ここでは有効化から SNAT・DNAT の定義方法、モード切り替え時の注意点までを解説します。

central-snat-map による SNAT

セントラル NAT は CLI で有効化します（GUI では System → Settings の System Operations Settings から有効化できます）。

config system settings
    set central-nat enable
end

有効化すると、ファイアウォールポリシー側の NAT オプションは機能しなくなり、SNAT ルールは central-snat-map で定義します。

config firewall central-snat-map
    edit 1
        set srcintf "internal"                  # 入力インターフェイス
        set dstintf "wan1"                      # 出力インターフェイス
        set orig-addr "LAN-Subnet"              # 変換対象の送信元アドレス
        set dst-addr "all"
        set nat-ippool "Pool-Overload"          # 使用する IP Pool（省略時は出力 I/F の IP）
    next
    edit 2
        set srcintf "internal"
        set dstintf "wan1"
        set orig-addr "all"
        set dst-addr "all"
    next
end

参考: FortiOS 7.6 – Central SNAT
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/421028/central-snat

central-snat-map のルールは 上から順に評価され、最初に一致したルールが適用 されます。送信元アドレス・宛先アドレスに加えて、プロトコル（set protocol）や送信元ポート範囲（set orig-port）でも条件を絞れるため、「特定サーバー群の通信だけ専用の IP Pool で変換し、それ以外は出力インターフェイスの IP で変換する」といった段階的なルール設計が可能です。この粒度の変換制御が、ポリシー NAT に対するセントラル NAT の最大の利点です。

なお、通信を許可するファイアウォールポリシー自体は引き続き必要です。セントラル NAT モードでは、ポリシーは「通信制御」、central-snat-map は「アドレス変換」と役割が分離される、と整理できます。

セントラル NAT モードでの VIP の扱い

DNAT 側の挙動はポリシー NAT 方式と大きく異なります。セントラル NAT モードでは、VIP をポリシーの宛先に指定する必要はなく、VIP オブジェクトのステータスを有効化した時点で宛先変換が機能 します。

参考: FortiOS 7.6 – Central DNAT
“The VIPs are configured as separate objects where their status must be enabled”
（VIP は独立したオブジェクトとして設定され、そのステータスが有効化されている必要があります）
https://docs.fortinet.com/document/fortigate/7.6.0/administration-guide/448790/central-dnat

config firewall vip
    edit "VIP-WebServer"
        set extip 203.0.113.100
        set extintf "any"
        set mappedip "192.168.1.80"
        set status enable                       # 有効化した時点で DNAT が機能する
    next
end

通信を許可するファイアウォールポリシーでは、VIP オブジェクトではなく 変換後の内部アドレス（192.168.1.80 に対応するアドレスオブジェクト）を宛先に指定 します。

config firewall policy
    edit 11
        set name "Internet-to-WebServer-Central"
        set srcintf "wan1"
        set dstintf "internal"
        set srcaddr "all"
        set dstaddr "Addr_192.168.1.80"         # VIP ではなく変換後の実アドレスを指定
        set action accept
        set schedule "always"
        set service "HTTPS"
    next
end

「ポリシーの宛先に VIP を指定する」ポリシー NAT 方式の感覚のまま設定すると意図通りに動作しないため、どちらのモードで動いているかを最初に確認する ことが、DNAT まわりの切り分けの出発点になります。

モード切り替え時の注意点

ポリシー NAT とセントラル NAT は運用途中でも切り替え可能ですが、以下の点に注意が必要です。

ポリシーに割り当て済みの VIP がある場合、割り当てを解除しないとセントラル NAT モードへ切り替えられません。切り替え前に、VIP を宛先に指定しているポリシーの棚卸しが必要です。
切り替え後は、ポリシー側で有効化していた NAT オプションが機能しなくなるため、既存の SNAT 要件をすべて central-snat-map に移植 する必要があります。移植漏れがあると、該当通信は変換されないまま送出されます。
NGFW ポリシーベースモードを使用する場合、セントラル NAT（SNAT）は暗黙的に有効となり、無効化の選択肢はありません。

切り替え作業はアドレス変換の全面的な組み替えとなるため、通信断を許容できるメンテナンス時間帯に実施し、切り替え前後で主要通信の変換結果を確認する 手順を推奨します。確認に使うコマンドは次のセクションで解説します。

動作確認とトラブルシューティング

NAT 設定後は「意図したアドレスに変換されているか」をセッションテーブルで確認し、期待通りに動作しない場合はフローの追跡で原因を絞り込みます。ここでは確認の基本手順と、FortiGate の NAT で頻出する 3 つのトラブルパターンを整理します。

セッションテーブルでの NAT 動作確認

NAT の動作確認は、セッションテーブルの参照が基本です。確認対象の通信をフィルタで絞り込んでから表示します。

# フィルタの設定（例: 宛先 IP とポートで絞り込み）
diagnose sys session filter dst 203.0.113.100
diagnose sys session filter dport 443

# セッションの表示
diagnose sys session list

# フィルタのクリア
diagnose sys session filter clear

出力の hook= 行に、変換の種類と変換前後のアドレスが表示されます。

hook=post dir=org act=snat 192.168.1.10:49531->198.51.100.20:443(203.0.113.10:61776)
hook=pre dir=reply act=dnat 198.51.100.20:443->203.0.113.10:61776(192.168.1.10:49531)

act=snat の行では「変換前の送信元 → 宛先（変換後の送信元）」の形式で表示され、括弧内が IP Pool または出力インターフェイスによる変換後のアドレスです。意図した Pool のアドレスが括弧内に表示されているか が最初の確認ポイントになります。SNAT・DNAT のセッション数を集計したい場合は、diagnose sys session list の出力を act=snat などで grep する方法が案内されています。

参考: Fortinet Community – Technical Tip: How to count IP pool, DNAT and SNAT sessions
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-count-IP-pool-DNAT-and-SNAT-sessions/ta-p/192783

IP Pool 単位の利用状況は、以下のコマンドで確認できます。ポート枯渇の予兆監視にも有効です。

# VDOM 内の IP Pool 一覧
diagnose firewall ippool-all list

# 特定プールのセッション統計（TCP / UDP / その他の内訳）
diagnose firewall ippool-all stats <pool-name>

diagnose debug flow による追跡

「セッションが生成されない」「変換結果がおかしい」という場合は、Flow Trace でパケット処理をリアルタイムに追跡します。

diagnose debug enable
diagnose debug flow filter addr <確認したい IP アドレス>
diagnose debug flow trace start 20              # パケット 20 個分だけ表示

# 確認後は必ず停止
diagnose debug flow trace stop
diagnose debug disable

出力中の DNAT / SNAT メッセージで変換の発生箇所を、Denied by forward policy check などのメッセージでポリシーによる拒否を確認できます。どのポリシー ID にマッチしたかは policy_id= で判別します。なお、ASIC オフロードが有効なセッションは Flow Trace に表示されないことがあるため、検証時のみ一時的にオフロードを無効化する方法があります（本番環境では検証後に必ず戻すことが推奨されます）。

よくあるトラブルと切り分け（match-vip・ポート枯渇・port-preserve）

トラブル 1: Deny ポリシーで VIP 宛の通信を拒否できない

「特定の送信元から公開サーバーへのアクセスを Deny ポリシーで拒否したはずなのに通信が通ってしまう」という事象は、FortiGate の VIP 処理順序に起因する代表的なトラブルです。

参考: Fortinet Community – Technical Tip: DENY Policy for Virtual IP Firewall Policy
“Destination NAT (DNAT) is applied before the firewall policy check”
（宛先 NAT（DNAT）は、ファイアウォールポリシーの評価より前に適用されます）
https://community.fortinet.com/t5/FortiGate/Technical-Tip-DENY-Policy-for-Virtual-IP-Firewall-Policy/ta-p/192456

VIP 宛のパケットはポリシー評価の時点ですでに宛先が内部アドレスへ変換済みのため、宛先を「all」や公開側アドレスで指定した Deny ポリシーにはマッチしません。対処は次の 2 通りです。

Deny ポリシーの宛先アドレスに VIP オブジェクトそのものを指定する。
Deny ポリシーで set match-vip enable を指定し、変換後のパケットもマッチ対象に含める。

なお、match-vip は Deny ポリシーでのみ指定可能なオプションで、FortiOS 7.2.3 以降はデフォルトが enable に変更 されています。7.6 系の新規構築では既定で緩和されていますが、旧バージョンからのアップグレード環境や過去の設定を流用する場合は、この挙動差を把握しておくことが推奨されます。

トラブル 2: NAT ポートの枯渇

Overload タイプ（および出力インターフェイス IP による変換）では、変換後 IP アドレス 1 つあたりのポート数に上限があります。多数のクライアントが同一宛先へ集中する環境では、ポートを使い切ると新規セッションが確立できなくなります。ポート枯渇時にはイベントログに NAT port is exhausted. というメッセージが記録されるため、このログの監視をポート枯渇検知のトリガーにする ことが実務的です。恒常的に発生する場合は、IP Pool のアドレス数追加、または PBA タイプへの変更によるポート管理の効率化を検討します。

トラブル 3: 送信元ポートが変換されて認証・連携が失敗する

対向システムが「特定の送信元ポートからの通信」を前提としている場合（レガシーな企業間連携や一部の UDP ベースのプロトコルなど）、NAPT による送信元ポートのランダム変換が原因で通信が失敗することがあります。この場合は、ポリシーまたは central-snat-map で set port-preserve enable を指定し、送信元ポートを維持する構成を検討します。ただし、ポートを維持する分だけ変換の柔軟性は下がるため、対象通信を絞ったポリシー・ルールにのみ適用することが推奨されます。

制約事項・設計上の注意

最後に、FortiGate の NAT を設計に組み込む際に把握しておきたい制約と注意点を整理します。

ペイロードに IP アドレスを含むプロトコルにはセッションヘルパーが関与する: FTP や SIP のように、アプリケーションデータの中に IP アドレス・ポート番号を埋め込むプロトコルは、ヘッダの変換だけでは通信が成立しません。FortiGate ではセッションヘルパー（ALG）がペイロード内の情報を補正しており、セッションテーブルの helper= フィールドで関与の有無を確認できます。NAT 環境でこれらのプロトコルだけが失敗する場合は、セッションヘルパーの動作を切り分け対象に含める ことが推奨されます。
未使用の VIP・IP Pool は削除する: 第 3 回で触れた通り、arp-reply が有効な VIP・IP Pool はポリシーで未使用でもローカルアドレスとして扱われ、該当アドレス宛のルーティング転送が行われなくなります。検証用に作成したオブジェクトの放置は、原因特定が難しい通信断につながります。
HA 構成ではセッション同期の設定を確認する: FGCP による HA 構成では、セッション同期（session-pickup）の設定状態により、フェイルオーバー時に NAT セッションが引き継がれるかどうかが決まります。同期が無効の場合、フェイルオーバー時に既存の NAT セッションは再確立が必要となるため、要件に応じて設定を確認することが推奨されます。
セントラル NAT への切り替えは計画的に行う: ポリシー NAT とセントラル NAT は排他であり、切り替え時には VIP の割り当て解除と SNAT ルールの全面移植が必要です。運用途中の切り替えは移行作業のボリュームが大きいため、設計初期の方式決定が最も低コストです。

まとめ

本記事では、FortiGate（FortiOS 7.6）の NAT 設定を、SNAT（IP Pool）・DNAT（VIP）・セントラル NAT の 3 つの軸で解説しました。VIP と IP Pool の基本操作に加えて、2 方式の使い分けと確認コマンドまで押さえておくことで、構築から障害対応までを一貫して進められます。

SNAT は IP Pool、DNAT は VIP で定義し、方式はポリシー NAT が既定
変換ルールの一元管理や細かなポート制御が必要ならセントラル NAT を選択
IP Pool は Overload・One-to-One・FPR・PBA の 4 タイプを要件で使い分ける
セントラル NAT モードでは VIP をポリシーに紐付けず単体で機能させる
動作確認は diagnose sys session list と diagnose debug flow が基本
Deny ポリシーと VIP の組み合わせでは match-vip の挙動理解が必要
未使用の VIP・IP Pool はローカルアドレス扱いとなるため削除を推奨

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

よかったらシェアしてね！

URLをコピーしました！

この記事を書いた人

とも

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ（ネットワーク・サーバ・クラウド・セキュリティ）の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus（取得から20年以上）／ VCAP-DCA ／ Azure Solutions Architect Expert

▶ 運営者プロフィール（詳細）

2026年11月
月	火	水	木	金	土	日
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30