2023-03-27 08:42 AM - 最終編集日: 2023-12-19 09:17 PM 、編集者: JapanTAC_CSC
SASE TopologyはFMC7.3以降で実装されている、FTDとUmbrella SIGとのIPSecトンネルを簡単に設定するための機能です。それ以前でFTDとUmbrella SIGを連携するためには、IKEv2やIPSecに関する様々なパラメータを双方で設定する必要があり特にFMCはGUIで入力が必要であるため非常に手間がかかりました。
SASE Topologyを使用すると、FMC側でUmbrella設定のためのAPIキーを連携することにより、Umbrella Dashboard側での作業は、APIキーを正しく発行することのみとなり、FMC側は接続先のUmbrellaのデータセンターと、APIキー、共有パスワードなどを入力するだけで、SIG Tunnelが確立できるようになります。
SASE Topologyの基本的な構成は以下の通りとなります。
設定はFMC側で実施することにより、FTDデバイスのIKEv2 / IPSecトンネルの設定及び、Umbrella SIGのTunnel設定が行われます。Umbrella SIG側の設定は、Umbrellaで発行するAPI経由での設定になりますので、Umbrella Dashboardでの設定は不要となります(APIのSecretを紛失している場合はUmbrella Dashboardで再発行が必要)。IPSecのTunnelを確立した後は、Policy Based Routing(PBR)を用いてユーザのSource IP等ベース等のACLを使って、Next HopをSVTIのTunnel Interfaceの宛先に設定することで、ユーザトラフィックをUmbrella SIGに送付し、各種セキュリティ機能を通じてInternetへアクセスします。
対応しているIPSecトンネル | 対応していないIPSecトンネル |
事前共有キー(PSK)認証 | 証明書認証 |
Failover(HA)構成 | Cluster構成 |
IKEv2 | IKEv1 |
SASE Topologyを使ったSIGトンネルの確立は以下の流れで実施します。
以下、それぞれの手順を紹介します。
Umbrella Dashboardにアクセスし、Organization IDと各種APIキーを取得します。
以下、それぞれの確認方法です。
1. Organization ID
Organization IDはUmbrellaのテナントを識別するIDであり、Dashboardへログインした際のURLから取得が可能です。
一例となりますが、Dashboardにログイン後のトップページのURLが以下の場合、2から始まる数字の部分がOrganization IDとなります。
2. APIキー
SASE Topologyで使用するAPIキーは以下3種類となりますが、以下APIはそれぞれOrganizationに一つのみ生成可能であるためご注意ください。パスフレーズであるSecretを紛失した場合にはAPI Keyの再発行が必要ですが、他の方が当該APIを使用している場合は、再発行すると古いAPI keyは使用不可になるため、ご注意ください。
上記は全てAdmin -> API Keysより、Legacy Keysをクリックすると表示されます。
以下の通り、Umbrella Network Devicesおよび、Umbrella ManagementのAPI keyはAPI keyとパスフレーズであるsecretがセットになっています。API KeyはDashboardでいつでもコピー可能ですが、Secretを紛失した場合はRefreshでAPI Key自体の再発行が必要です。再発行した場合、Secretは発行直後しか表示されないため別途コピーしておきます。
Legacy Network DevicesはTokenのみとなっており、Secretはありませんので発行されているTokenをコピーします。
以上で必要なパラメータの取得は終了となります。以降はFMCの設定となります。
ここからは先ほど取得したAPI keyなどの情報をFMCに入力します。
FMCにログインし、Integration -> Other IntegrationよりCisco Cloud Connectionの内容を入力します。Generalタブに、Organization ID、Umbrella Network DevicesのKeyとSecret、及び、Legacy Network DeviceのTokenを入力します。
AdvancedのタブよりUmbrella ManagementのAPI KeyとSecretを入力しSaveをクリックします。
入力後、Test ConnectionをクリックすることでUmbrella APIとの疎通確認が出来ます。
引き続き、FMCよりSASE Topologyを作成します。Devices -> VPN -> Site To Siteへアクセスします。
SASE Topologyをクリックします。
Create SASE Topologyの各パラメータを入力し、Threat Defense Nodesを追加するためにAddをクリックします。パラメータの説明は以下の通りです。
設定を適用するFTDデバイスを選択し、適用するVTIインターフェイスを指定します。
SASE TopologyでUmbrella SIGとIPSecトンネルを張る場合は、VTIインターフェイスを使用します。VTIインターフェイスを設定しますと、仮想のインターフェイスが設定され、FTDのRoutingでIPSec対象となるトラフィックのみをVTIインターフェイスに通すなど制御が容易です。最初は設定されていないと思われますため、その場合+をクリックして以下のように作成します。
ほとんどデフォルトのままで問題ありませんが、Tunnel Sourceに関しては、IPSecトンネルを張るのに使うInterfaceを指定する必要があります。また、IPアドレスに関しては後ほど対向先のTunnelのIPアドレスとして同じセグメントのアドレスを指定するため、記録しておきます。
先ほどの画面に戻り、対象のFTDデバイスと作成したVTIインターフェイスを指定しまます。Local Tunnel IDは使用しているUmbrellaのOrgの中で一意になれば問題ないため、適当なものを設定します。
入力後、Saveをクリックします。
(最終的にはUmbrellaのOrganization IDなどを使って一意なTunnel IDを生成します)
Create SASE Topologyの画面に戻ってくるため、Nextをクリックします。
Summaryを確認しSaveをクリックします。
先ほど設定したUmbrella ConnectionのAPI Keyを使って、Umbrella側の設定が開始されます。StatusがSUCCESSになることを確認します。また、同時にFTDデバイス側への設定のDeployも実行されます。
Transcriptをクリックしますと、実際に、UmbrellaのManagement APIでどのような設定が行われたのかを確認することが出来ます。
この時点でUmbrellaのDashboard設定だけでなく、FTDデバイスへの設定もDeployされるため、設定は完了しますが、場合によっては、IPSecトンネルが張れず、ステータスが以下のようにUnknownのままになる場合があります。
一時的な問題の可能性があるため、その場合は、IPSec Tunnelを貼るInterfaceを一度、Devices -> Device Managementの該当デバイスからDisableしDeployし、改めてEnableにしDeployするなどで復旧するか確認します。
問題なくトンネルが張れた場合は、SASE Topologyは以下のようにActiveとして表示されます。
これでIPSec Tunnelは確立されますが、あくまでVTIによって定期的な接続を試みているためであり、この時点では実際のトラフィックは送信されません。以降は、ユーザトラフィックをSIGにRoutingするための設定を説明します。
FTDで処理するトラフィックをUmbrella SIGに飛ばす方法としては、Source IPアドレスを用いたPolicy Based Routing(PBR)を使用します。PBRを用いることで発信元アドレス等に基づいて、SIGを経由させるトラフィックを設定します。これによって、SIGを経由させるトラフィック、経由させないトラフィックを分けることが可能です。
Policy Based Routingは、Devices -> Device Managementより、対象のデバイスのRouting -> Policy Based Routingより設定します。Addをクリックして、PBRを追加します。
Ingress InterfaceにPBRの対象とするパケットを受信するインターフェイスを指定し、Match Criteria and Egress InterfaceでActionを指定するためにAddをクリックします。
Match ACLで、対象となるトラフィックを指定します。ここでは、事前に作成しておいた、特定のSource IPアドレスからのみのACLを追加します。ACLの追加方法については、こちらをご確認ください。
また、Send ToをIP Addressとし、先ほどSASE Topologyで作成したVTI Interfaceと同じセグメントのIPアドレスを入力します。ここでは、VTIのInterfaceのIPが169.254.2.1/30であるため、169.254.2.2を設定します。
全ての項目を入力したらSaveをクリックします。
Saveをクリックします。
さらに、FTDデバイスの設定をSaveし、設定をDeployします。
必ずしも全ての環境で必要ではないと思われますが、環境によっては、ネットワークのパケットサイズの調整のため、MTU / MSSをFTDに設定する必要がある場合がございます。
特に、IPSecトンネルを確立出来ているにも関わらず、SIG経由で外部サイトにアクセス出来ないなどの問題が発生する場合にはMTU / MSSの調整をお試しください。
Umbrellaのドキュメントに記載されている通り、MTUは最大1400Byte、MSSは最大1360Byteに設定する必要があります。UmbrellaはPath MTU Discoveryに対応していないため、大きなサイズのパケットをドロップする動作となりますのでご注意ください。FMC管理のFTDに対するMTU / MSSの設定は以下の記事に記載してありますので、合わせてご確認ください。
SASE Topologyを用いたUmbrella SIGとの接続におけるトラブルシューティングの方法を紹介します。
まずは、FMC及びUmbrellaそれぞれのGUI上で、IPSecトンネルの状態を確認します。
FMCはDevices -> VPN -> Site to Siteより作成したSASE Topologyの状態を確認し、状態がActive(緑)になっていることを確認します。
UmbrellaはDashboardのDeployments -> Core Identities -> Network Tunnelより、対象のTunnelのStatusがActiveになっていることを確認します。
FTD側のIPSecトンネルのもう少し詳細の情報を確認する場合はFTDのCLIより以下の二つのコマンドを実行します。
1. show crypto ikev2 sa
ftd73# show crypto ikev2 sa
IKEv2 SAs:
Session-id:3, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote fvrf/ivrf Status Role
170859211 64.104.47.154/4500 146.112.112.8/4500 Global/Global READY RESPONDER <<<<READYと表示されておりIKEv2によるトンネルの確立を確認
Encr: AES-GCM, keysize: 256, Hash: N/A, DH Grp:20, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/5476 sec
Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0xc04a2b62/0xc23fa601
2. show crypto ipsec sa
ftd73# show crypto ipsec sa
interface: outside_static_vti_1
Crypto map tag: __vti-crypto-map-Tunnel1-0-1, seq num: 65280, local addr: 64.104.47.154
Protected vrf (ivrf): Global
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer: 146.112.112.8
--snip--
inbound esp sas: <<<< Inbound方向のSAが出来ていることを確認
spi: 0xC04A2B62 (3226086242)
SA State: active
transform: esp-aes-gcm-256 esp-null-hmac no compression
in use settings ={L2L, Tunnel, NAT-T-Encaps, IKEv2, VTI, }
slot: 0, conn_id: 27, crypto-map: __vti-crypto-map-Tunnel1-0-1
sa timing: remaining key lifetime (kB/sec): (4054934/28249)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas: <<<< Outbound方向のSAが出来ていることを確認
spi: 0xC23FA601 (3258951169)
SA State: active
transform: esp-aes-gcm-256 esp-null-hmac no compression
in use settings ={L2L, Tunnel, NAT-T-Encaps, IKEv2, VTI, }
slot: 0, conn_id: 27, crypto-map: __vti-crypto-map-Tunnel1-0-1
sa timing: remaining key lifetime (kB/sec): (4101114/28249)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Umbrella Dashboard / FTDそれぞれの設定が完了しているにも関わらず、IPSecトンネルの状態がActiveにならない場合は、一度FTDのIPSecで使用しているインターフェイスをDisable / Enableにし直すことで復旧が可能か確認します。当方で試験した限りでは、特にSASE Toplogyを作成した直後はIPSecトンネルが確立出来ない事象が確認出来ており、その場合はインターフェイスをDisable / EnableすることでIPSecトンネルを張ることに成功しました。
また、通信要件などを満たす必要があるため、Umbrella SIGデータセンターのGlobal IPアドレスとFTDのインターフェイスの双方向に対して、ESP、UDP:500、UDP4500の疎通が取れることを確認お願いします。
その他、Umbrella SIGとIPSecトンネルを確立するためには、条件があるため、詳しくは以下のドキュメントをご確認ください。
事象が継続する場合は後述するログを取得して、TACケースオープン等で調査を進めます。
IPSecトンネルが正しく動作している場合、次に確認するべき箇所は、ユーザトラフィックが正しく流れているかどうかとなります。いくつか確認する方法がありますが、FTDではCLIから以下のコマンドを確認します。
ftd73# show crypto ipsec sa
interface: outside_static_vti_1
Crypto map tag: __vti-crypto-map-Tunnel1-0-1, seq num: 65280, local addr: 64.104.47.154
Protected vrf (ivrf): Global
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer: 146.112.112.8
#pkts encaps: 226, #pkts encrypt: 226, #pkts digest: 226 <<< 行きのパケットが暗号化されていることをカウントで確認
#pkts decaps: 436, #pkts decrypt: 436, #pkts verify: 436 <<< 帰りのパケットが復号化されていることをカウントで確認
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 226, #pkts comp failed: 0, #pkts decomp failed: 0 <<<その他エラーカウントが上がっていないことを確認
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0
これにより、pkts encaps / decapsのカウンターが上がっていることを確認します。
カウンターの値が過去の値である場合には、clear crypto ipsec sa countersでカウンターを初期化してから、通信を発生させたのちに確認します。もし、そもそもIPSec SAの情報が表示されない場合は、IPSecトンネル自体の確立に失敗しているため、前項のIPSecトンネルの確認を改めて実施します。
また、packet-tracerを用いて、正しくPBRが適用され各フェーズでパケットがDropされずに、設定したトンネルを通過することを確認します。
ftd73# packet-tracer input inside tcp 192.168.201.65 12345 8.8.8.8 443
Phase: 1
Type: PBR-LOOKUP
Subtype: policy-route
Result: ALLOW
Elapsed time: 122976 ns
Config:
route-map FMC_GENERATED_PBR_1678778168201 permit 5 <<< 意図したPBRが適用されていることを確認
match ip address Umbrella-ACL
set ip next-hop 169.254.2.2
Additional Information:
Matched route-map FMC_GENERATED_PBR_1678778168201, sequence 5, permit
Found next-hop 169.254.2.2 using egress ifc outside_static_vti_1
---snip---
Result:
input-interface: inside(vrfid:0)
input-status: up
input-line-status: up
output-interface: outside_static_vti_1(vrfid:0) <<<設定したStatic VTI Interfaceからパケットが出ることを確認
output-status: up
output-line-status: up
Action: allow
Time Taken: 449154 ns
こちらが動作しない場合、Policy Based Routingの設定が適切であるか等を確認します。
Umbrella側においてもFirewall PolicyをTunnel Identityに対して設定している場合、Policies -> Management -> Firewall Policyから対象のFirewall Policyを確認すると、以下のようにHit Countが上がっていればIPSec経由でUmbrella SIGにデータが流れているという点を確認が可能です。画面のRESET RULE COUNTより、Hit Countをリセットすることも可能です。
最後に、Umbrella側のFirewall Policy、DNS Policy、Web Policyなどでパケットが通過していることや、適切にDrop出来ていることを確認します。Umbrella SIGとIPSecトンネルを確立する場合、Umbrella側では、まずFirewall Policyがチェックされ、主にLayer3/4のIP/Portレベルの制御が実行され、その後TCP:80/443のトラフィックがSWGによってWeb Policyのチェックが行われます。HTTPSのトラフィックに関しては、中間証明書を用いてSWGの中でDecryptされるため、端末側では、事前にUmbrellaのRoot CA証明書、もしくは組織で発行したCA証明書を準備し、端末に事前に配布する必要があります。
詳しくは以下ドキュメントをご確認ください。
Umbrella: 組織が発行した CA 証明書の使用について
Umbrellaの各Policyによって、パケットがDropされていないかについては、Umbrella DashboardのReporting -> Core Reports -> Activity Searchより確認します。
Umbrella SIGの場合、Firewall Policy / Web PolicyのIdentityはNetwork Tunnelとなるため、Identity TypeにNetwork Tunnelsを指定するなどによって、Firewall Policy / Web Policyの適用状況と、Allow, Blockを確認します。
スクロールすることでActionとしてAllowedとなったかBlockになったか等を確認することが可能です。
ここで想定しない通信がBlockになっていることによって問題が出る場合は、各Policyの変更を行います。
また、SWGによるHTTPS通信の復号によって、動作しなくなるアプリケーション等もあり、その場合は選択的復号リストを用いて、除外したいコンテンツ・カテゴリ、アプリケーションをリストに追加することにより、SWGの復号の対象から外すことが可能です。詳しくは、以下ドキュメントをご参照ください。
Umbrella:Web ポリシーの選択的複合リスト利用方法について
SWG固有と思われる問題が発生している場合においては、以下ドキュメントを参照し、必要なログを取得ください。
Troubleshooting Umbrella Secure Web Gateway: Policy Debug and Diagnostic Tests
SASE Topology設定に関するトラブルで必要と考えられるログ等は以下となります。
あくまで一般的に必要と考えられる情報であり、これらに限らず、追加の情報取得が必要となる場合がございます。また、逆に常に全てのログが必要ではないため、必要なログを可能な限り、取得をいただけますと幸いです。
全ての事象に共通して必要な情報
> system support diagnostic-cli
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.
ftd73> ena
Password:
ftd73#
カウンターのクリア
clear crypto ipsec sa counters
clear access-list <PBRで使用するACL名> counters
clear asp drop
事象発生時に複数回実行
show crypto ipsec sa
show crypto ikev2 sa
show asp drop
show access-list <PBRで使用するACL名>
一度のみ取得
show run crypto
show run interface
show run access-list
show policy-route
show route-map
show version
show tech(上記showコマンドの多くを含む)
ping <Umbrella SIG データセンター IP> 例:東京は146.112.112.8
packet-tracer input <送信元IF> <tcp or udp> <送信元IP> <送信元port> <宛先IP> <宛先port> ※IPSec Tunnelを通る通信をテスト
Debug Log
FMC管理のFTDはASAとは異なり、CLIのみでDebug Logを取得することが出来ないため、Internal Bufferや外部syslogサーバに対してLogging level Debuggingのログを転送する設定が事前に必要となります。もしIPSecトンネルを接続出来ない事象が継続する場合においては、以下Debug Logの取得をご検討ください。
debug crypto ikev2 platform
debug crypto ikev2 protocol
debug crypto ipsec
debug policy-route
FTDのDebug Logの取得方法については以下ドキュメントをご確認ください。
Debug Logの取得後はundebug allでDebugを停止することを忘れないでください。本番環境の場合、ログサイズが肥大化したり、負荷が上がる可能性がございます。
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
下記より関連するコンテンツにアクセスできます