現職で、AWS環境にPaloaltoVMを構築し、オンプレミスのPaloaltoからのリプレイスを図ったのですがその時ハマったことを自分用のメモとして記載します。
本エントリに書いてあることが意外とドキュメントとして探しづらいので情報をまとめました。この情報が誰かの役にたてばこれ幸いです。

前提

このエントリは下記の方向けに記載しています。

Paloaltoの構築・運用経験がある。 ※オンプレミスでも可。
AWS環境でEC2インスタンスを作成したことがある。

そもそもなぜ移行を検討したか

主にBCP目的です。
データセンターではなく、社内環境にPaloaltoを用意してあり、各支社からは本社のPaloaltoを経由して各種通信をするスター型のネットワークトポロジになっていました。
要は 本社のPaloaltoが停止すると全社のネットワークが止まる という。。
例えば、本社が大規模災害になったとすると 支社含めて会社業務がほぼ止まる という全く笑えない事態となってました。 (実際に本社の法令停電で支社がネットワーク接続できなくなる、という事態もおきてました)

どういう形で移行したの？

AWS側にPaloaltoVMを構築し、社内環境からはAWS側に構築したPaloaltoとIPSec接続しました。
そして、社内からのInternet接続は全てAWS環境のPaloaltoを通過するような構成にしました。
図にすると↓みたいな感じ。

[オンプレ]社内PC→[オンプレ]IPSecルータ→[AWS]Paloalto→[AWS]Internet Gateway

AWS環境じゃなくて、データセンターに置けば良くない？

データセンターに置くことも考えましたが、データセンターに置くことによるメリットがコストメリットくらいしか無く、 「Paloalto物理マシンのメンテ」 など余計な運用コストが発生することを懸念し、クラウドに移行しました。
※予算がシビアな会社はデータセンターにPaloaltoを置いて、そことIPSEC接続するのも悪い選択肢ではないとは思います。現社の場合は「運用コスト＞費用」だったので。

そもそもPalo Alto VM必要？AWS側の機能だけで良くない？

と、最初考えたのですが、AWS側ですべて完結しようとすると、「セキュリティグループの管理が大変」だったり、「トラフィックログを見るのが大変」だなと考えたのでPalo Alto VMを導入することを決めました。

セキュリティグループの管理
- AWSだけで頑張ると1インスタンス事にセキュリティグループを"適切"にアタッチすることが必要になるので、インスタンスが増えていくと管理が大変...。その点、EC2インスタンスの通信をPalo Alto VMを経由するように(0.0.0.0/0の通信をすべて、Palo Alto VMのENIにルーティング)してしまえば、Palo Alto側で一元的にセキュリティポリシーを制限できる。
トラフィックログの管理
- AWS側でも「VPCフローログ」等を設定すればトラフィックログを追えるのですが、もっとライトに「〇〇のインスタンスが△△に通信できない」といったちょっとしたログを追うのに適していないと感じてます。その点、Palo Alto VMならば簡単にトラフィックログが見れるので楽。

ハマったこと

ここからが本題。ハマったこと一覧です。

InterfaceのIPアドレスはDHCPではなく、スタティックで構築すべし

当初はclassmethodさんの下記記事を参考にPaloaltoVMへのIPアドレスアサインを「DHCPクライアント」として登録して、AWS側のDHCPサーバ側からIPを取得させていました。

dev.classmethod.jp

ところが、しばらくすると通信が不通になりPaloaltoVM自体を再起動しないと、再度通信ができなくなる自体に。 (恐らく、DHCPリース期限が切れたタイミングでこういった事象になるのですが真の原因は不明です。 )

そこでIPアドレスをDHCPではなくスタティックで設定しました。そうすることで通信が切れることはなくなりました。
ちなみに、どういったIPアドレスを設定すればいいか(≒AWS側からアサインされたIPアドレスをどうやって確認すればいいか)はPaloalto管理コンソールから対象のインタフェースを選択し、「DHCPクライアントランタイム情報の表示」を選択すれば確認できます。 f:id:undersooon:20190601011001p:plain

Gatewayアドレス・NextHopアドレスはグローバルIPではなく、ローカルIPアドレスで指定すべし

GatewayアドレスやNextHopアドレスをElastic IP(AWSで用意したグローバルIPのこと)で設定しがちなのですが、これはNGです。
設定するIPアドレスは AWS側の「プライベートIPアドレス」 を設定します。
(グローバルIPのアタッチはAWS側で勝手に実施します。Paloalto側ではできません。)

オンプレミスで構築をしてきた人だとグローバルIPを設定しがちなんですよね。。(私もそうでした)

インスタンスタイプによるInterface数の制限に注意

PaloaltoVMを構築する際にEC2インスタンスのインスタンスタイプが一番最低限のものにする場合、現時点(2019年5月時点)では「m4.xlarge」を選択することになります。 mx4.largeではENI(インタフェース)を4つまでしか作成できず、かつ、PaloaltoVM側でマネージメントインタフェースとして1つENIを使用するので、 実質、インタフェースは３つまでしか作成できません というわけで、3つ以上のインタフェースを作成したい人はインスタンスタイプをm4.xlarge以上のものにする必要があります。

詳細は下記URLの「各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数」-「ネットワークインターフェイスの最大数」でご確認ください。

docs.aws.amazon.com

※単純に「グローバルIPを複数使いたい」という場合は上記ENIの最大数の制限を回避する方法があります。詳細は後述の「１つのインタフェースにグローバルIPを複数割り当てする方法」を参考にしてください。

１つのインタフェースにグローバルIPを複数割り当てする方法

ちょっとややこしいですが、、下記手順で構築すれば可能です。

EC2管理コンソールから「IPアドレスの管理」を選択。「新しいIPの割り当て」で新たなプライベートIPを割り当て。
EC2管理コンソールから新たに割り当てたプライベートIPにEIPを割り当て。
PaloaltoVMの管理コンソールにて「Policies」タブ-「NAT」にて新たに割り当てたEIPを適用したいNATルールを作成。

※ENIの割り当てもインスタンスタイプによって上限はあります。m4.xlargeでも上限15個なので、まあ使い切ることは無いかもですが。こちらも詳細は(https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html の「インターフェイスあたりの IPv4 アドレス」を参考にしてください。)

swapインタフェース

PaloaltoVMを冗長化する場合の選択肢の一つとして、「AWS側のNLBにぶら下げる」という方法があります。
が、しかし。 PaloaltoVMのデフォルトでは「プライマリのインタフェースがマネジメントインタフェース」となります。
マネジメントインタフェースのままでは、ALBにぶら下げることができないので、下記方法でeth0とeth1を交換(swap)するようにPaloaltoVMを起動するようにすればNLBにぶら下げることができるようになります。
なので、私はインスタンス作成時に下記のように構築し、インスタンス作成後にswapして構築しました。

eth0
- Internet Gatewayと通信できるENI(PaloaltoでいうUntrust側インタフェース)
eth1
- マネジメントインタフェースのENI

ご参考までに： https://docs.paloaltonetworks.com/vm-series/7-1/vm-series-deployment/set-up-the-vm-series-firewall-in-aws/use-the-vm-series-firewall-cli-to-swap-the-management-interface

冗長化の組み方

Palo Alto VMの冗長化構成として私が調べた限りでは一般的には下記の２つのいずれかの方法を取るようです。

同一AZ内に配置し、HA構成を組む。 ※オンプレミスでHA構成を構成するときと同じやり方。
NLBにPalo Alto VMをぶら下げる

ただし、現職では上記いずれの方式も採用しませんでした。
理由は下記。

「同一AZでHA」
- そもそもPalo Alto VMが使用不可になるのは「AWS側の定期メンテナンスによる個別のインスタンス停止」と「AZ全体の障害」だという風に考えています。前者の"メンテナンス"はAWS側から事前に「そろそろインスタンスを停止/起動してね」と告知されるのでそれに従えば良い、"AZ全体の障害"の場合、同一AZで構成したら両方死ぬので意味が無い。ということで、全く旨味ゼロ。
「NLB」
- 悪くない選択肢なのですが、諸事情により「ロードバランシングではなく常にプライマリ側で通信させたい」という要件があり、これも旨味がない。
- 諸事情とは：VMを常時２台起動していると当然ですが、２台分のインスタンス費用が発生するのでこれを避けたかった。(節約したかった)