AWS Network Firewallにおけるステートフルルールでのドメイン登録と非対称ルーティング問題

はじめに

AWS Network Firewallを利用して、ステートフルルールにドメインを登録したにも関わらず、想定と異なり全ての通信が許可されてしまう事象に遭遇しました。本記事では、その際の調査内容と解決策について詳しく解説します。

AWS Network Firewallのリソース概要

AWS Network Firewallは、VPCの境界でネットワークトラフィックをフィルタリングするためのサービスです。主要なリソースとその役割は以下の通りです。

Network Firewall のリソース	説明
ファイアウォール	ファイアウォールは、ファイアウォールポリシーのネットワークトラフィックフィルタリング動作を、保護対象とする VPC に接続します。ファイアウォール設定には、ファイアウォールエンドポイントが配置されるアベイラビリティーゾーンおよびサブネットの仕様が含まれます。また、AWS ファイアウォールのリソースにおけるファイアウォールのログ設定やタグ付けなどの高レベルの設定も定義します。
ファイアウォールポリシー	ファイアウォールポリシーは、ファイアウォールのモニタリングおよび保護動作を定義します。動作の詳細は、ポリシーに追加するルールグループ、および一部のポリシーのデフォルト設定で定義されます。ファイアウォールポリシーを使用するには、1 つ以上のファイアウォールに関連付けます。
ルールグループ	ルールグループは、ネットワークトラフィックを検査および処理するための再利用可能な条件のセットです。ポリシー設定の一部として、ファイアウォールポリシーに 1 つ以上のルールグループを追加します。ステートレスルールグループを定義して、各ネットワークパケットを個別に検査できます。ステートレスルールグループは、Amazon VPC ネットワークアクセスコントロールリスト (ACL) と動作および使用態様が似ています。また、ステートフルルールグループを定義して、トラフィックフローのコンテキストでパケットを検査することもできます。ステートフルルールグループは、Amazon VPC セキュリティグループと動作と使用態様が似ています。

公式サイトより引用：
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/network-firewall.html

通信フロー

EC2インスタンスからNetwork Firewallエンドポイントを経由し、NAT Gatewayへ向かう通信フローです。
詳細については、以下の記事をご参照ください。
https://qiita.com/He_Xiaolu/items/050ce898eb39775b6ffd

設定内容

今回の問題発生時の設定内容は以下の通りです。

• 各リソースのルートテーブル設定は以下の図の通りです。

• ポリシー名：firewall-policy-test-2025
• ステートフルルールグループ：Stateful-test-2025
• ステートフルルール許可：.google.com

想定動作

• Googleへのアクセスのみが許可される。
• YahooなどGoogle以外のサイトへのアクセスはブロックされる。

実際の動作

• Google、Yahooいずれのサイトにもアクセスできてしまう（制御が効いていない）。
例：Googleへのcurl -v実行結果の一部

[root@ip-10-0-143-24 bin]# curl -v https://www.google.com/
* Host www.google.com:443 was resolved.
* IPv6: 2404:6800:4004:823::2004
* IPv4: 172.217.161.36
*   Trying [2404:6800:4004:823::2004]:443...
* Immediate connect fail for 2404:6800:4004:823::2004: Network is unreachable
*   Trying 172.217.161.36:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=www.google.com
*  start date: Oct  1 14:35:29 2025 GMT
*  expire date: Dec 24 14:35:28 2025 GMT
*  subjectAltName: host "www.google.com" matched cert's "www.google.com"
*  issuer: C=US; O=Google Trust Services; CN=WR2
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
* Connected to www.google.com (172.217.161.36) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.google.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.google.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.11.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: www.google.com
> User-Agent: curl/8.11.1
> Accept: */*

例：Yahooへのcurl -v実行結果の一部

[root@ip-10-0-143-24 bin]# curl -v https://www.yahoo.co.jp/
* Host www.yahoo.co.jp:443 was resolved.
* IPv6: (none)
* IPv4: 182.22.25.124
*   Trying 182.22.25.124:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: C=JP; ST=Tokyo; L=Chiyoda-ku; O=LY Corporation; CN=edge01.yahoo.co.jp
*  start date: Oct 15 01:51:03 2025 GMT
*  expire date: Nov 14 14:59:00 2026 GMT
*  subjectAltName: host "www.yahoo.co.jp" matched cert's "*.yahoo.co.jp"
*  issuer: C=JP; O=Cybertrust Japan Co., Ltd.; CN=Cybertrust Japan SureServer CA G4
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to www.yahoo.co.jp (182.22.25.124) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.yahoo.co.jp/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.yahoo.co.jp]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.11.1]
* [HTTP/2] [1] [accept: */*]

原因

AWS Network Firewallは非対称ルーティングをサポートしていません。非対称ルーティングが発生すると、Network Firewallはトラフィックを適切に処理できません。今回のケースでは、ステートフルルールが戻りの通信に適用されず、リクエストトラフィックとレスポンストラフィックがフローとして認識・処理されていない状態でした。

詳細はこちらのドキュメントをご参照ください。
https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/asymmetric-routing.html

つまり、今回の場合は、NAT Gatewayのサブネットルートテーブルに「戻りの経路」が適切に追加されていないと、Firewallをバイパスして通信が流れてしまうことがあります。これにより、ドメインルールを設定しても期待通りの動作にならず、全ての通信が許可されてしまうように見えていたのです。

解決策

NAT Gatewayのサブネットルートテーブルに「戻りの経路」を下記のように追加します。これにより、戻りトラフィックもNetwork Firewallを通過するようになります。

実際のAWSマネジメントコンソールでの設定画面は以下のようになります。

結果

設定修正後、以下の動作が確認できました。
・GoogleへのアクセスはOKでした。
・YahooへのアクセスはNGとなりました。

例：Googleへのcurl -v実行結果の一部

[root@ip-10-0-143-24 bin]# curl -v https://www.google.com/
* Host www.google.com:443 was resolved.
* IPv6: 2404:6800:4004:823::2004
* IPv4: 142.250.199.100
*   Trying [2404:6800:4004:823::2004]:443...
* Immediate connect fail for 2404:6800:4004:823::2004: Network is unreachable
*   Trying 142.250.199.100:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey

例：Yahooへのcurl -v実行結果の一部

[root@ip-10-0-143-24 bin]# curl -v https://www.yahoo.co.jp/
* Host www.yahoo.co.jp:443 was resolved.
* IPv6: (none)
* IPv4: 124.83.184.252
*   Trying 124.83.184.252:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt
*  CApath: none
* Connection timed out after 300364 milliseconds
* closing connection #0
curl: (28) Connection timed out after 300364 milliseconds

まとめ

AWS Network Firewallを利用する際は、ルートの向き先を正しく設定し、戻りの経路も必ずFirewallを通す構成にすることが非常に重要であると学びました。同様の事象で困っている方の参考になれば幸いです。

注意事項：
本ブログに掲載している内容は、私個人の見解であり、
所属する組織の立場や戦略、意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。