Cisco ASA 5500 - VPN Works in One Direction

KB ID 0000759

Problem

The title of this article can cover a multitude of possible causes, however I recently had a strange problem where a client with a remote site protected by an ASA5505 had a VPN tunnel connected to their main site which had an ASA5510. The tunnel established at phase 1, and phase 2, the main site could talk to the remote site, but the remote site refused to talk back to the main site.

Update 23/04/19: Seen again this time, the ASA at the ‘problem end’ had a static route pointing 10.0.0.0/8 internally, but VPN traffic needed to get to 10.4.0.0/24 at the other end of the VPN tunnel, so traffic was reputed back into the LAN again and dropped.

Update 13/08/14: Seen again, this time from ASA at the problem end, I could ‘ping inside {IP at the remote site}’ and get a response, and the tunnel established. But internal clients could not send traffic over the VPN.

Solution

Usually if you can only “Establish” a tunnel from one side, and it still works, the culprit is normally that PFS has only been specified at one end of the tunnel. On both ends issue a ‘show run crypto map’ command and make sure both ends either use PFS or do not use PFS.

crypto map outside_map 1 match address outside_1_cryptomap
 crypto map outside_map 1 set pfs
 crypto map outside_map 1 set peer 123.123.123.123 
 crypto map outside_map 1 set ikev1 transform-set ESP-3DES-SHA

However in this case there was a ‘Rogue NAT entry’ on the ASA5505, that looks like a throwback from an OS upgrade.

 nat (inside,outside) source static LocalSN LocalSN destination static Site1SN Site1SN
 nat (inside,outside) source static LocalSN LocalSN destination static Site2SN Site2SN
 nat (inside,outside) source static LocalSN LocalSN destination static Site3SN Site3SN
 nat (inside,outside) source static LocalSN LocalSN destination static Site4SN Site4SN
 nat (inside,outside) source dynamic any interface
 nat (inside,outside) source static LocalSN LocalSN destination static Site5SN Site5SN
 !
 object network OBJ-NAT-ALL
 subnet 0.0.0.0 0.0.0.0 
 nat (inside,outside) dynamic interface

Note: The line in red should not have been there. The last three lines are all you need (Note: your object may be called obj_any).

You can see why it’s causing a problem if you do a packet-trace on some traffic, (see the two examples below).

Packet-Tracer Results (Misconfigured)

PetesASA# packet-tracer input inside icmp 192.168.2.2 8 0 192.168.1.1

Phase: 1
 Type: ROUTE-LOOKUP
 Subtype: input
 Result: ALLOW
 Config:
 Additional Information:
 in 0.0.0.0 0.0.0.0 outside

Phase: 2
 Type: ACCESS-LIST
 Subtype: log
 Result: ALLOW
 Config:
 access-group inside_access_in in interface inside
 access-list inside_access_in extended permit ip any any
 Additional Information:

Phase: 3
 Type: CONN-SETTINGS
 Subtype:
 Result: ALLOW
 Config:
 class-map class-default
 match any
 policy-map global_policy
 class class-default
 set connection decrement-ttl
 service-policy global_policy global
 Additional Information:

Phase: 4
 Type: NAT
 Subtype:
 Result: ALLOW
 Config:
 nat (inside,outside) source dynamic any interface <Problem!
 Additional Information:
 Dynamic translate 192.168.2.2/0 to 123.123.123.123/21205 <Problem!

Phase: 5
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 6
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 7
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 class-map inspection_default
 match default-inspection-traffic
 policy-map global_policy
 class inspection_default
 inspect icmp
 service-policy global_policy global
 Additional Information:

Phase: 8
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 Additional Information:

Phase: 9
 Type: NAT
 Subtype: rpf-check
 Result: ALLOW
 Config:
 nat (inside,outside) source dynamic any interface <Problem!
 Additional Information:

Phase: 10
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 11
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 12
 Type: FLOW-CREATION
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:
 New flow created with id 32065, packet dispatched to next module

Result:
 input-interface: inside
 input-status: up
 input-line-status: up
 output-interface: outside
 output-status: up
 output-line-status: up
 Action: allow

Packet-Tracer Results (Configured Correctly)

PetesASA# packet-tracer input inside icmp 192.168.2.2 8 0 192.168.1.1

Phase: 1
 Type: ROUTE-LOOKUP
 Subtype: input
 Result: ALLOW
 Config:
 Additional Information:
 in 0.0.0.0 0.0.0.0 outside

Phase: 2
 Type: UN-NAT
 Subtype: static
 Result: ALLOW
 Config:
 nat (inside,any) source static NETWORK_OBJ_192.168.2.0_24 NETWORK_OBJ_192.168.2.0_24 destination static NETWORK_OBJ_192.168.1.0_24 NETWORK_OBJ_192.168.1.0_24 no-proxy-arp route-lookup < That's Better!
 Additional Information:
 NAT divert to egress interface outside
 Untranslate 192.168.1.1/0 to 192.168.1.1/0  < That's Better!

Phase: 3
 Type: ACCESS-LIST
 Subtype: log
 Result: ALLOW
 Config:
 access-group inside_access_in in interface inside
 access-list inside_access_in extended permit ip any any
 Additional Information:

Phase: 4
 Type: CONN-SETTINGS
 Subtype:
 Result: ALLOW
 Config:
 class-map class-default
 match any
 policy-map global_policy
 class class-default
 set connection decrement-ttl
 service-policy global_policy global
 Additional Information:

Phase: 5
 Type: NAT
 Subtype:
 Result: ALLOW
 Config:
 nat (inside,any) source static NETWORK_OBJ_192.168.2.0_24 NETWORK_OBJ_192.168.2.0_24 destination static NETWORK_OBJ_192.168.1.0_24 NETWORK_OBJ_192.168.1.0_24 no-proxy-arp route-lookup < That's Better!
 Additional Information:
 Static translate 192.168.2.2/0 to 192.168.2.2/0 < That's Better!

Phase: 6
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 7
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 8
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 class-map inspection_default
 match default-inspection-traffic
 policy-map global_policy
 class inspection_default
 inspect icmp
 service-policy global_policy global
 Additional Information:

Phase: 9
 Type: INSPECT
 Subtype: np-inspect
 Result: ALLOW
 Config:
 Additional Information:

Phase: 10
 Type: VPN
 Subtype: encrypt
 Result: ALLOW
 Config:
 Additional Information:

Phase: 11
 Type: NAT
 Subtype: rpf-check
 Result: ALLOW
 Config:
 nat (inside,any) source static NETWORK_OBJ_192.168.2.0_24 NETWORK_OBJ_192.168.2.0_24 destination static NETWORK_OBJ_192.168.1.0_24 NETWORK_OBJ_192.168.1.0_24 no-proxy-arp route-lookup  < That's Better!
 Additional Information:

Phase: 12
 Type: VPN
 Subtype: ipsec-tunnel-flow
 Result: ALLOW
 Config:
 Additional Information:

Phase: 13
 Type: NAT
 Subtype: per-session
 Result: ALLOW
 Config:
 Additional Information:

Phase: 14
 Type: IP-OPTIONS
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:

Phase: 15
 Type: FLOW-CREATION
 Subtype:
 Result: ALLOW
 Config:
 Additional Information:
 New flow created with id 33263, packet dispatched to next module

Result:
 input-interface: inside
 input-status: up
 input-line-status: up
 output-interface: outside
 output-status: up
 output-line-status: up
 Action: allow

Cisco ASA 5500 – VPN Works in One Direction

Problem

Solution

Packet-Tracer Results (Misconfigured)

Packet-Tracer Results (Configured Correctly)

Related Articles, References, Credits, or External Links