VPN Hairpinning Intermittent Issue

Unanswered Question
Dec 21st, 2007
User Badges:

Hello, I am using an ASA 5540 VPN edition to terminate VPN connections from software clients and PIX/ASA boxes using EasyVPN (in network extension mode).


I am trying to get the PIX/ASA remote networks and the VPN Clients to talk to each other (they both have no problems talking to the core) but intra-spoke communication is intermittent.


Just as an example, I was trying to ping from a client (192.168.200.4) to a remote network (192.168.8.1) and it wouldn't work, but when I initiated the ping from the remote network side (192.168.8.1) it started working "magically."


same-security-traffic permit intra-interface is enabled on the core pix.


Here is some of the relevant config:


access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip 192.168.1.0 255.255.255.0 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip 172.16.1.0 255.255.255.0 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip 172.16.2.0 255.255.255.0 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip any 10.1.131.0 255.255.255.224

access-list inside_nat0_outbound extended permit ip any 10.1.129.0 255.255.255.128

access-list inside_nat0_outbound extended permit ip any 10.1.129.0 255.255.255.192

access-list inside_nat0_outbound extended permit ip any 10.1.6.192 255.255.255.192

access-list inside_nat0_outbound extended permit ip 10.1.6.0 255.255.255.0 10.1.6.0 255.255.255.0

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 10.0.0.0 255.0.0.0

access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.240.0.0 10.0.0.0 255.0.0.0

access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.0.0 10.0.0.0 255.0.0.0

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 192.168.0.0 255.254.0.0

access-list inside_nat0_outbound extended permit ip 172.16.0.0 255.255.0.0 192.168.0.0 255.254.0.0

access-list inside_nat0_outbound extended permit ip 172.17.0.0 255.255.0.0 192.168.0.0 255.254.0.0

access-list inside_nat0_outbound extended permit ip 172.18.0.0 255.255.0.0 192.168.0.0 255.254.0.0

access-list inside_nat0_outbound extended permit ip 192.168.0.0 255.255.0.0 192.168.0.0 255.255.0.0


ip local pool VPN_CLIENTS 192.168.200.1-192.168.207.254 mask 255.255.248.0


global (outside) 1 209.17.173.11 netmask 255.255.255.0

global (outside) 101 209.17.173.9 netmask 255.255.255.192

global (DMZ) 101 209.17.173.9 netmask 255.255.255.192

global (DMZ) 2 192.168.1.8

nat (outside) 0 access-list inside_nat0_outbound

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 10.2.4.0 255.255.255.0

nat (inside) 101 172.18.1.0 255.255.255.0

nat (inside) 101 172.16.0.0 255.255.0.0

nat (inside) 101 10.0.0.0 255.0.0.0

nat (DMZ) 0 access-list inside_nat0_outbound



Help?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
husycisco Sat, 12/22/2007 - 09:11
User Badges:
  • Gold, 750 points or more

Hi Gordon

try this


access-list outside_nat0_outbound permit ip 192.168.200.0 255.255.248.0 192.168.8.0 255.255.255.0

no nat (outside) 0 access-list inside_nat0_outbound

nat (outside) 0 access-list outside_nat0_outbound outside


Regards

gordon.hawkins Sat, 12/22/2007 - 13:20
User Badges:

we have the "sysopt connection permit-vpn" command enabled..


i tried putting these commands in but it had no effect. When i run a debug icmp trace on the ping I can see a ping going from 192.168.200.4 (my remote IP) to 192.168.8.1 but there is no response.

When you say it "magically" worked after pinging from the 192.168.8.1 network, did you start getting a response pinging from 192.168.200.4 at this point? Try this:


1. Do a 'debug crypto isakmp 250'

2. Tear down the VPN to the 192.168.8.1 network by issuing the 'clear crypto sa peer ' command

3. Start pinging 192.168.8.1 from the remote client

4. See if the ASA tries to bring up the VPN from the debug output


I'm thinking the 192.168.8.1 peer may be configured to only initiate the tunnel, rather than respond and initiate.

gordon.hawkins Sat, 12/29/2007 - 19:47
User Badges:

Alright, I made the silly mistake of having an ACL on an outside interface and not having a line in the ACL that would permit the traffic from the outside tunnels. However, when I run packet-trace now i get an error - "IPSEC Spoof Detected".. any ideas?

Hi Gordon,


The "IPSEC Spoof Detected" message is the ASA saying its received a packet that should have been encrypted but was not.


packet-tracer will only simulate a non-encrypted packet. If you ran packet-tracer on the outside interface as input from 192.168.200.4 (for example), it would expect this to arrive as an encrypted packet from the remote host.


John

Actions

This Discussion