ASA:Uターントラフィックについて

xingj · ‎2017-07-11

はじめに
ASAで必要な設定
トラブルシューティングについて　
関連情報

はじめに

内部サーバーや社内ゾーンを保護するため、外部からのトラフィックをASAがフィルターリングをかけて運用する場合があります。但し、ASAの同じInterfaceを利用してパケットの受信と送信を対応する (Uターントラフィック) ように設定した場合、通信がうまくできない場合があります。　
本ドキュメントはUターントラフィックについて紹介します。　
　
　

ASAで必要な設定

本ドキュメントでは以下の構成例にて説明します。　

以下構成図では、PC 2の Default Gatewayが Router (172.16.10.10) ではなく ASA (172.16.10.254) となっている事にご注意ください。

ASA側にて以下の3つの設定を行えば、Uターントラフィックの制御が可能となりますが、上記構成での通信の場合では当3つの設定のみでは通信確立はできません。本ドキュメントでその理由と対応方法について説明いたします。

interface GigabitEthernet0/1-------------------------------->Interfaceを設定
nameif inside
security-level 100
ip address 172.16.10.254 255.255.255.0
!
same-security-traffic permit intra-interface---------------->Uターントラフィック機能を有効
route inside 60.60.60.0 255.255.255.0 172.16.10.10 ----->ルーティング設定を追加

トラブルシューティングについて　

背景

上記構成でルーターにPC2の情報があれば、ASAを経由せずPCへ直接パケットを送る場合、該当通信がドロップされます。これはASAのTCPステートバイパス機能とInspection機能と関連します。　

TCPステートバイパスについて：　　

機能の詳細については、以下の記事をご参照ください。　
https://supportforums.cisco.com/ja/document/13122501　

アプリケーションインスペクションについて：　　

機能の詳細については、以下の記事をご参照ください。　
http://www.cisco.com/cisco/web/support/JP/docs/SEC/Firewall/ASA5500NextGenerationFire/CG/003/inspect_overview.html?bid=0900e4b183273703

通信の一連の流れについて (workaround未適用時)

PC1 (60.60.60.1) からPC2 (172.16.10.1) へTCP通信を行う場合：

1. PC1からSYNパケットをルーターに送って、ルーターにはPC2のルーティングテーブル情報を持ってあり、ASAを経由せず、直接PC2へ送ります。

2. PC2はSYNパケットを受信して、GatewayがASAのinsideインターフェースのため、ASA宛にSYN/ACKパケットを返します。

3. SYN/ACKパケットをASAが受信しますが、初期のSYNパケットが確認できないため、以下のログを出力して、パケットをドロップします。

%ASA-6-106015: Deny TCP (no connection) from 172.16.10.1/21 to 60.60.60.1/21218 flags SYN ACK on interface inside
%ASA-6-106015: Deny TCP (no connection) from 172.16.10.1/21 to 60.60.60.1/21218 flags SYN ACK on interface inside
%ASA-6-106015: Deny TCP (no connection) from 172.16.10.1/21 to 60.60.60.1/21218 flags SYN ACK on interface inside

PC2 (172.16.10.1) からPC1 (60.60.60.1) へTCP通信を行う場合：　

1. PC2のGatewayがASAのため、ASA宛にSYNパケットを送ります。

2. ASAは以下の設定があるため、Uターン機能とルーティング情報によりパケットをルーターに送ります。
　 -same-security-traffic permit intra-interface
　 -route inside 60.60.60.0 255.255.255.0 172.16.10.10 1

但し、この段階でASAのデフォルト機能のTCPシーケンス番号ランダマイゼーション機能により、シーケンス番号を書き換えて転送します。

3. ルーターはSYNパケットをPC1に転送します。

4. PC1はASAが送信したランダム化されたシーケンスのパケットを受信して、それに基づくSYN/ACKパケットをルーターに送ります。

5. ルーターはPC2のルーティングテーブル情報があり、ASAを経由せずPC2へ送ってしまいます。

6. PC2はランダム化されたシーケンス番号を受信したため、最初に自分が送ったSYNに対する応答ではないため、リセットをパケットを送信してセッションを閉じます。このタイミングでASAには以下のSyslogを出力させます。

%ASA-6-302013: Built inbound TCP connection 21 for inside:172.16.10.1/31905 (172.16.10.1/31905) to inside:60.60.60.1/21 (60.60.60.1/21)
%ASA-6-302014: Teardown TCP connection 21 for inside:172.16.10.1/31905 to inside:60.60.60.1/21 duration 0:00:00 bytes 0 TCP Reset-O
%ASA-6-106015: Deny TCP (no connection) from 172.16.10.1/31905 to 60.60.60.1/21 flags RST on interface inside

PC1 (60.60.60.1) からPC2 (172.16.10.1) へICMP通信を行う場合：　　

ASAにて "inspect icmp" 機能が有効になった場合、同じくパケットがドロップされます。

1. PC1からPC2へPingする場合、ルーターがまずASAを経由せず直接PC2へICMPのEcho Requestを出します。

2. PC2はEcho requestを受信して、それに対するEcho ReplyパケットをASAに送信します。

3. 但し、ASAはこのパケットを受信して既存のEcho Requestが確認できなく、以下のログにてパケットを直接ドロップします。

%ASA-6-302020: Built inbound ICMP connection for faddr 172.16.10.1/0 gaddr 60.60.60.1/1 laddr 60.60.60.1/1
%ASA-4-313004: Denied ICMP type=0, from laddr 172.16.10.1 on interface inside to 60.60.60.1: no matching session
%ASA-6-302021: Teardown ICMP connection for faddr 172.16.10.1/0 gaddr 60.60.60.1/1 laddr 60.60.60.1/1
%ASA-6-302020: Built inbound ICMP connection for faddr 172.16.10.1/0 gaddr 60.60.60.1/1 laddr 60.60.60.1/1
%ASA-4-313004: Denied ICMP type=0, from laddr 172.16.10.1 on interface inside to 60.60.60.1: no matching session
%ASA-6-302021: Teardown ICMP connection for faddr 172.16.10.1/0 gaddr 60.60.60.1/1 laddr 60.60.60.1/1

PC2 (172.16.10.1) からPC1 (60.60.60.1) へICMP通信を行う場合：　

この場合、PC2からICMPのEcho RequestはASAを経由しますが、戻りのEcho ReplyパケットはASAを経由しないままPC1に届くため、通信は影響を受けません。

　
Workaroundについて　

TCP通信の場合：　　

以下のようにTCPのステートバイパス設定を無効にすることで回避可能です。

access-list tcp_bypass extended permit tcp host 172.16.10.1 host 60.60.60.1
PC1とPC2間の通信をACLで定義します。
!
class-map bypass_c------------------------------------>定義したACLをclass-mapに適用します。
description "TCP traffic that bypasses stateful firewall"
match access-list tcp_bypass
!
policy-map bypass_p----------------------------------->policy-mapを作成して上記のclass-mapを適用して、TCPステートバイパス設定を適用します。
class bypass_c
set connection advanced-options tcp-state-bypass
!
service-policy bypass_p interface inside-------------->policy-mapをservice-policyに適用します。

　
但し、TCPステートバイパス設定を有効にした場合、先に案内したURL情報に記載しております通り、セキュリティの低下などの影響がありますこと、予めご了承ください。そのため、上記のように特定の通信のみに対して適用していただくことを推奨いたします。

ICMP通信の場合：　　

以下のようにICMPのインスペクションを無効にすることとなります。

policy-map global_policy
class inspection_defaul
no inspect icmp

但し、上記の設定の場合、すべてのICMPインスペクションが無効となり、セキュリティチェックが低下されます。通信特定などできる場合、特定通信のみをICMPインスペクションから除外することができます。

access-list icmp_bypass extended deny icmp host 172.16.10.1 host 60.60.60.1
access-list icmp_bypass extended permit icmp any any
!
class-map icmp_c
description "icmp bypass"
match access-list icmp_bypass
!
policy-map global_policy
class inspection_default
no inspect icmp
policy-map icmp_p
class icmp_c
inspect icmp
!
service-policy icmp_p interface inside