Introduction This document provides a sample configuration for setting up the ASA (running 8.3 or later) to hairpin/u-turn traffic off its interface. Requirements Ensure that you meet these requirements before you attempt this configuration: ASA is running 8.3 code or later. Network Diagram Configurations Consider the following scenario: 1. Client 192.168.1.10 is trying to access web-server 192.168.2.10. 2. The default-gateway for 192.168.1.10 is the ASA's inside interface ip i.e. 192.168.1.1 3. Thus, the SYN is sent from the host to the ASA's inside interface. 4. On the ASA, an access-list check is done first, followed by route-lookup which determines the egress interface to be the 'inside' interface itself. 5. Since, the SYN packet is going to ingress and egress the ASA from the same interface and hence, traverse through the same security-level, we need the ASA to permit this exclusively using: ASA(config)#same-security permit intra-interface 6. The SYN will then reach the webserver after the router does the appropriate routing. 7. When the SYN-ACK is returned from the webserver, it will get back to the router. Here, if the router is already aware of the 192.168.1.0 network (as shown in the topology above), then it will directly forward the packet back to the client (out its FastEthernet 0 interface). 8. The client upon receiving this SYN-ACK packet, will drop it. The reason for this is due to "TCP sequence number randomization" carried out by default on the ASA i.e. when the ASA receives a SYN packet on any interface, it randomizes the sequence number of the packet before sending the packet out. It carries this out as a security policy and keeps track of the the changes it has made using its state table. In our case, when the client initiated the connection, let's say the seq. number of the packet was 12345. When this SYN packets got hairpinned/u-turned off the inside interface, the seq. number would have gotten randomized to another number, say, 56789. Thus, when the webserver wants to acknowledge this packet, it generates a SYN-ACK with respect to 56789 (and not 12345). This SYN-ACK is dropped by the client (since it was expecting a SYN-ACK for the packet with seq. number 12345). 9. To avoid packet-drops due to the asymmetric nature of routing that's occuring internally, we need the ASA to bypass stateful inspection for this particular traffic. For this, we need to configure the following: ASA(config)#access-list tcp_bypass extended permit tcp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 !--- Configure the access list to specify the TCP traffic !--- that needs to by-pass inspection to improve the performance. !--- Configure the class map and specify the match parameter for the !--- class map to match the interesting traffic. ASA(config)#class-map tcp_bypass ASA(config-cmap)#description "TCP traffic that bypasses stateful firewall" ASA(config-cmap)#match access-list tcp_bypass !--- Configure the policy map and specify the class map !--- inside this policy map for the class map. ASA(config-cmap)#policy-map tcp_bypass_policy ASA(config-pmap)#class tcp_bypass !--- Use the set connection advanced-options tcp-state-bypass !--- command in order to enable TCP state bypass feature. ASA(config-pmap-c)#set connection advanced-options tcp-state-bypass !--- Use the service-policy policymap_name [ global | interface intf ] !--- command in global configuration mode in order to activate a policy map !--- globally on all interfaces or on a targeted interface. ASA(config-pmap-c)#service-policy tcp_bypass_policy inside Note: Once the above is enabled, the ASA does not keep track of the state of the connection anymore, so, features such as TCP sequence randomization, TCP intercept, etc. will be disabled. 10. Finally, as far as NAT is concerned, ASA's running 8.3 and higher have nat-control turned off and thus, no specific NATs are required to get the hairpinning/u-turning to work. There is one exception to this though: If NAT rules such as the one below are present, then we would require some specific NAT'ing to be done on the ASA to allow the u-turning to occur. object network obj-all-network subnet 0.0.0.0 0.0.0.0.0 nat (inside,any) dynamic <ip address> I n the NAT statement above, the 'any' keyword will cause an issue due to which the u-turned traffic will fail the reverse-path check (RPF-Drop). To avoid this, one can issue a NAT statement such as: nat (inside,inside) 1 source static obj-192.168.1.0 obj-192.168.1.0 destination static obj-192.168.2.0 obj-192.168.2.0 where obj-192.168.1.0 and obj-192.168.2.0 are the network objects that contain the subnets 192.168.1.0/24 and 192.168.2.0/24 respectively. This NAT rule is more specific and instructs the ASA as follows: When a packet sourced from 192.168.1.0/24 and destined to 192.168.2.0/24 reaches the inside interface of the ASA, then statically NAT the source ip of the packet from 192.168.1.X to 192.168.1.X and statically NAT the destination ip of the packet from 192.168.2.X to 192.168.2.X. This rule can be used for the return traffic from 192.168.2.X to 192.168.1.X as well i.e. it is a bi-directional NAT rule. 11. With the above configurations in place, the ASA will permit traffic to be hairpinned/u-turned off its interface. Additional Comments 1. Note that, as the name suggests, TCP State Bypass can be used to resolve such asymmetric routing issues only for TCP traffic and nothing else. 2. For example, pings from 192.168.1.x to 192.168.2.x may work; but pings initiated from 192.168.2.x to 192.168.1.x will not. This is because the ASA is usually configured to inspect protocols such as ICMP (refer: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008085283d.shtml ). 3. Thus, when initiating pings from 192.168.2.x to 192.168.1.x, the echo request reaches 1.x directly through the router whereas the echo reply from 1.x is sent to the ASA. Since the ASA is unaware of this ICMP session, it simply drops the echo reply packet. 4. The only workaround to allow pings to work from 192.168.2.x to 192.168.1.x is to disable ICMP inspection for that traffic on the ASA. 5. The same holds true for other protocols that are being inspected by the ASA. Related Information 1. TCP State Bypass Configuration Guide: http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080b2d922.shtml 2. Information on Default Global Inspection on the ASA: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008085283d.shtml 3. Information on 8.3 NAT and pre-8.3 to 8.3 NAT configuration examples: http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/nat_overview.html https://supportforums.cisco.com/docs/DOC-9129
... View more
