Hairpinning off ASA interface 5520 8.4(3)

[diesel]

Hi Guys,

This is my scenario

1. IPSEC s2s tunnel configured between Head office and branch office works fine

2. Head office terminates RA VPN  users and this works fine in terms of connectivity to networks at Head Office

3. RA VPN clients are unable to connect to branch office networks through IPSEC s2s tunnel between head office and branch office

4. Split tunneling is in use

The vpn profile created for this test is a replica of a working one (sharing the same pool but different policy) with the inclusion of the branch office subnets on the "tunnelled" networks (split tunnelling)

What i have observed

1. The branch office networks are included in the "tunnelled networks" (split tunnelling)

2. Each end of the tunnel is configure effectively allowing x.x.x.x to any IP on the cryptomaps

3. Nat exemption is configured as the first rule between the RA client subnet and branch office subnets

4. same-security-traffic permit intra-interface is enabled

5. Default routing ensures traffic hits same outside interface 

6. Route print on the RA client points branch office networks though vpn interface

I cannot connect to any branch office networks and wanted some ideas on debugging to identify what the firewall is doing with the packets.

At this moment in time i do not have access to devices (permissions issue) to check if traffic is being received at the other end but will get this later in the week.

Thanks

[Marvin Rhoads]

The steps you outlined are correct in general.

Have you defined your NAT exemption as "outside,outside"?

To debug you can try using packet-tracer. Something like:

packet-tracer input outside tcp <some RA pool address> 1025 <some remote site address> 80

(The remote site address doesn't need to be a web server - just be an address over there. I used port 80 as an example to analyze the flow through the ASA.)

[diesel]

Tried that but the ASA drops the traffic according to this, i am guessing by the fact no acl is configured on the outside interface (which shouldn't be required)

not seeing anything on the logs either

traffic to all other tunneled subnets is fine.

[Marvin Rhoads]

Hmm - so just to confirm, the NAT statements for this traffic should be something like:

nat (outside,outside) source static client_vpn_pool client_vpn_pool destination static remote_office_net remote_office_net

What does packet-tracer tell you?

[diesel]

nat statement is

nat (outside,outside) source static client_vpn_pool client_vpn_pool destination static remote_office_net remote_office_net

packet tracer says traffic is denied by ACL