AWS TransitGatewayでVPC間通信をFireWall経由にしたい(が、できなかった件)=>できそうな件=>新機能NetworkFireWallローンチ!!=>早速試してみた!!!

(2020.10.21)

監査専用のVPCを作成してそこにFireWallを設置し、VPC間の通信制御をするという構成を検討したが、現状うまくいっていない。

事象は以下の通り。
・PC1からFireWall(ENI1およびENI2)へのPINGは応答がある。
・PC1からPC2へのPINGは応答がない。FireWall上でパケットキャプチャをすると、ICMPのリクエストパケット(10.0.1.100->192.168.1.100)がループしている(ENI2->ENI1)。
これはTGWをアタッチしたinline-pri-cサブネットのルーティングテーブルで192.168.0.0/16->ENI1に指定されているからだと思われる。

仮にこの構成がうまくルーティングできるとしても、以下の疑問がある。
(疑問1)
・Attatchmentは各AZに対して1つなのだから、inputは常に同じサブネット。
=>通常のFWならip spoofingでDROPする構成だが、問題ないのか。

(疑問2)
・FireWallのルーティングはどちらのインターフェースも0.0.0.0/0がある。
=>必ず反対側のインターフェースから出力するようにできるのか。
(Windowsではできているし、FireWallの仕様次第と思われる)

だとすると、別のAZにサブネットを作成して、そこにもTGWのアタッチメントを作成して、192.168.1.100へのルーティングを向ければよいと思われるが、FireWallから別のAZのサブネットからTGWに抜けていくルートを記載できないので実装できなかった。

AWSはトランジットゲートウェイに監査用のVPCを作成して、VPC間通信を監査用のVPCのファイアウォールを経由させる事ができると言い切っているので(NATもせずに)、何かしら方法があるのかもしれないが、見当がつかない。どういうルーティングにすれば良いのかご存知の方がいたら教えてほしい。

(20202.11.18)
その後色々とテストして、結局ルーティング可能な構成は以下の3つでした。
前回のテストでPINGが通らなかったのは設定間違いでした。ちゃんと確認しないとだめですね。

①往路はENI1からENI2に抜ける。復路はENI2からENI1に抜ける構成
この場合、ENI2側のホストのルーティングテーブルは、TGWを指定する必要がある。
いくつか課題があって、1つ目はA社とVPC、B社とVPCのルーティング経路をサブネットとホストに書く。そうするとA社とB社間のルーティングが書けなくなります。もう1つは、ENI1のルーティングはゲートウェイをTGWのIPアドレスにする必要があるということです。TGWのIPが変わってしまったら通信できなくなってしまいます。
②往路も復路もENI1からENI2に抜ける構成(上図のテストの構成)
これは①の構成の課題をクリアしている。ただ、FireWallがこのような通信を正常にフィルタできるのか不明。
③FireWallをワンアーム構成にする
上図でいうと、ENI2のみを使う構成です。これは可能ですが、②と同様にFireWallがこのような通信を正常にフィルタできるか不明です。ENI1はTGWと同じサブネットなので、そっちのENIを使う場合には①の構成ど同様にホストのルーティングにゲートウェイにTGWのIPを指定する必要があります。

という事で、現実的なのは②か③です。AWSに聞いたらワンアームで設計するのが一般的だそうです。あとはFireWallの仕様次第ですが、できると言っている人がいます。自分はやった事ないので知らないです。が、ワンアームの構成はICMPリダイレクトを無効にできなかったらFireWallを経由しないのでは?と疑ってますが、無効ならできるのかもしれないです。

(2020.11.20)
そうこうしているうちに、なんと新機能Network Firewallがリリースされました。
https://aws.amazon.com/jp/blogs/aws/aws-network-firewall-new-managed-firewall-service-in-vpc/

ただ、東京リージョンはまだ対応してません。IGWやTransitGatewayにアタッチできて、WebFilterも使えるみたいです。
近いうちにテストしてみようと思います。

詳細はこちら
https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html

 

(2020.11.21)
タイミングよくNetwork Firewallがリリースされたので(東京リージョンはまだ対応してません)、上のワンアーム構成におけるLinux(FireWallみなし)をNetwork FireWallに置き換えてみました。
結果、構成はLinuixの時と全く変わらず、TGWをアタッチしたほうのセグメントのルーティングテーブルで、10.10.0.0/16宛と192.168.0.0/16宛をNetworkFirewallのエンドポイントにルーティングするという変更だけで動作しました。
先の構成は作り直したので一応構成図は以下です。この構成でPC1とPC2はNetwork FireWall経由で通信します。

(図中のRoute tgw vpc3 192.168.0.0/16 ->VPC1は間違えです。正しくはVPC2です)

Network Firewallのデプロイ自体はとても簡単なのでここでは特に書きませんが、デプロイするとENIができます。

ですが、ルートの設定ではこのENIを指定するのではなく、エンドポイントを指定します。リストから選ぶときはGateway Load Balancer Endpointにあります。
FireWallのポリシーはステートレスのポリシーとステートフルのポリシーに分かれていて、FireWall製品を扱ってた人には少しだけ違和感がありますが、慣れだと思います。いずれにしてもとても楽に構築できました。機能の詳細はまだこれから確認ですが、このNetwork Firewallは検討の価値はあると思います。
AZ毎にデプロイしなければならないし、可用性についてはAWSライクな考え方で設計していくのだと思います。まだあまり考えてないですが。

ベースのモデルは以下にあります。
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/
For the return traffic from firewall endpoint, a single VPC route table is configured. The route table contains a default route towards AWS Transit Gateway. Traffic is returned to AWS Transit Gateway in the same AZ after it has been inspected by AWS Network Firewall. Figure 6 shows traffic flow of inspection VPC.

ログは大事ですね。こういうログが出ます。

{
“firewall_name”: “vpc3-firewall”,
“availability_zone”: “eu-west-1a”,
“event_timestamp”: “1605924774”,
“event”: {
“timestamp”: “2020-11-21T02:12:54.085913+0000”,
“flow_id”: 205116760543129,
“event_type”: “alert”,
“src_ip”: “10.0.1.100”,
“src_port”: 34034,
“dest_ip”: “192.168.1.100”,
“dest_port”: 22,
“proto”: “TCP”,
“alert”: {
“action”: “blocked”,
“signature_id”: 1,
“rev”: 0,
“signature”: “”,
“category”: “”,
“severity”: 3
}
}
}
ログはもっとちゃんと見たいのですが別の話になってきたので、ここで別の記事に切り替えます。