AWS Network Firewall を経由するとセキュリティグループが送信元となる通信が許可されない
VPC のセキュリティグループには、ミドルボックスアプライアンスを経由すると、セキュリティグループを送信元とした通信が許可されないという仕様があります。詳細は下記ドキュメントをご参照ください。
ミドルボックスアプライアンスを介して異なるサブネット内の 2 つのインスタンス間のトラフィックを転送するようにルートを設定するには、両方のインスタンスのセキュリティグループでインスタンス間のトラフィックがフローできるようにする必要があります。各インスタンスのセキュリティグループは、他のインスタンスのプライベート IP アドレス、または他のインスタンスを含むサブネットの CIDR 範囲を送信元として参照される必要があります。他のインスタンスのセキュリティグループを送信元として参照する場合、インスタンス間のトラフィックは許可されません。
一方で、上記仕様は、ミドルボックスアプライアンスが AWS Network Firewall の場合も含まれるのか試してみました。以下の構成で検証します。
結論
上記のミドルボックスアプライアンスの仕様は AWS Network Firewall も含まれます。
- 通信経路
パブリックEC2 -> AWS Network Firewall -> プライベートEC2
上記通信経路において、プライベート EC2 のセキュリティグループ（インバウンドルール）のソースがパブリックEC2のセキュリティグループになっている場合、通信ができません。
一方で、ソースにパブリック EC2 のプライベート IP を設定している場合、通信が可能です。
- 参考例：プライベート EC2 の セキュリティグループ
ソースがセキュリティグループ ID -> 通信 NG
ソースがプライベート IP -> 通信 OK
やってみた
VPC の作成
パブリックサブネット 1 つ、プライベートサブネットを 2 つ持つ VPC を作ります。
それぞれ パブリック EC2,プライベート EC2, ファイアウォールを配置するためのサブネットです。
EC2 の作成
以下構成で パブリック EC2 インスタンスを作成します。
- name: pub-ec2
- Amazon Linux 2023
- t3.micro
- パブリックサブネットに配置
- パブリックIPの自動割り当てを有効化
- ローカルから SSH できるようセキュリティグループを設定
続いて、プライベート EC2 インスタンスを作成します。
- name: pvt-ec2
- Amazon Linux 2023
- t3.micro
- プライベートサブネットに配置
- セキュリティグループを新規作成
プライベート EC2 のセキュリティグループにてパブリック EC2 から PING できるようルールを追加します。
動作確認のため、ローカルからパブリック EC2 に入り、そこからプライベート EC2 に PING してみます。
以下の通り通信できているので OK です。（10.0.137.19 は pvt-ec2 のプライベート IP です）
[ローカル]$ ssh -i <キー> ec2-user@<pub-ec2 のパブリック IP>
...
[pub-ec2]$ ping 10.0.137.19
PING 10.0.137.19 (10.0.137.19) 56(84) bytes of data.
64 bytes from 10.0.137.19: icmp_seq=1 ttl=127 time=0.479 ms
...
--- 10.0.137.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2112ms
rtt min/avg/max/mdev = 0.183/0.284/0.479/0.137 ms
Network Firewall の作成
続いて、AWS Network Firewall を作っていきます。
VPC コンソールから、作成画面へ移動し、任意の名前を指定します。
サブネットは前述にて作成済みの Firewall 用サブネットを指定します。
詳細設定の部分はデフォルトのままにします。
空のファイアウォールポリシーを作成にチェックを入れ、任意のポリシー名を指定します。それ以外はデフォルト設定にしておきます。
最後に設定内容を確認し、問題が無ければファイアウォールを作成します。
作成できました。
Firewall ルールグループの作成
次に、Firewall のルールグループを設定します。
前項にて作成したファイアウォールのポリシー設定のタブを選択し、ステートフルルールグループを作成します。
形式は標準ステートフルルールを選びます。
任意の名前でルールグループ名を指定します。
続いてルールの設定を行います。
ルール変数および IP セット参照はオプションのため、特にデフォルトのまま変更しません。
標準ステートフルルールにて、パブリック EC2 からプライベート EC2 への通信をチェックするよう設定を行います。
プロトコルは ICMP を指定し、送信元および送信先にそれぞれの EC2 のプライベート IP を設定します。
（※上記 IP 設定例の参考として EC2 のプライベート IP が分かる画像を載せておきます）
ルールを追加したら「次へ」いきます。
カスタマーマネージドキーのチェックは外しておきます。
確認画面で問題なければそのままルールグループを作成します。
ルールグループ作成後、ファイアウォールの詳細タブより、設定が「同期中」となっていれば設定は OK です。
ルートテーブルの修正と動作確認
ここまでで設定は全て終えたので、最後にパブリック EC2 からの通信がファイアウォールを経由するようルートテーブルを修正し、動作確認をしていきます。
まず 現時点で プライベート EC2 に PING が通るか試します -> 通りました。
[ec2-user@ip-10-0-15-234 ~]$ ping 10.0.137.19
PING 10.0.137.19 (10.0.137.19) 56(84) bytes of data.
64 bytes from 10.0.137.19: icmp_seq=1 ttl=127 time=0.153 ms
64 bytes from 10.0.137.19: icmp_seq=2 ttl=127 time=0.163 ms
64 bytes from 10.0.137.19: icmp_seq=3 ttl=127 time=0.167 ms
^C
--- 10.0.137.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2060ms
rtt min/avg/max/mdev = 0.153/0.161/0.167/0.005 ms
パブリック EC2 サブネットのルートテーブルを編集し、プライベートEC2に向けた通信は、ファイアウォールエンドポイントを通るよう設定します。
（※参考：上記の送信先はプライベートサブネット EC2 の CIDR の値です）
上記の通りルートテーブルを編集後、再度 PING を行います。
すると、以下の通り PING が通らなくなりました。
[ec2-user@ip-10-0-15-234 ~]$ ping 10.0.137.19
PING 10.0.137.19 (10.0.137.19) 56(84) bytes of data.
^C
--- 10.0.137.19 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2105ms
現在の状態では、プライベート EC2 のセキュリティグループにてパブリック EC2 の SG をソースとして設定しています。
これをパブリック EC2 のプライベート IP に変えてみます。
すると、PING が通るようになりました。
[ec2-user@ip-10-0-15-234 ~]$ ping 10.0.137.19
PING 10.0.137.19 (10.0.137.19) 56(84) bytes of data.
64 bytes from 10.0.137.19: icmp_seq=1 ttl=127 time=2.92 ms
64 bytes from 10.0.137.19: icmp_seq=2 ttl=127 time=1.98 ms
64 bytes from 10.0.137.19: icmp_seq=3 ttl=127 time=2.04 ms
^C
--- 10.0.137.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.976/2.311/2.917/0.428 ms
上記の動作は公式ドキュメントの通りですね。
Public-EC2 -> Network Firewall -> Private-EC2 の通信において、プライベート EC2 のセキュリティグループのソースにパブリック EC2 の SG を指定すると通信ができないことがわかりました。
終わりに
今回は、セキュリティグループのミドルボックスアプライアンスを介した通信について、Network Firewall がそのアプライアンスに含まれるのか検証してみました。結論、含まれました。
ドキュメントをそのまま読んでいると見逃しそうな内容のため、本ブログがどなたかのお役に立てば幸いです。
以下、ドキュメントの情報の再掲です。
ミドルボックスアプライアンスを介して異なるサブネット内の 2 つのインスタンス間のトラフィックを転送するようにルートを設定するには、両方のインスタンスのセキュリティグループでインスタンス間のトラフィックがフローできるようにする必要があります。各インスタンスのセキュリティグループは、他のインスタンスのプライベート IP アドレス、または他のインスタンスを含むサブネットの CIDR 範囲を送信元として参照される必要があります。他のインスタンスのセキュリティグループを送信元として参照する場合、インスタンス間のトラフィックは許可されません。
参考情報
