VPN on ASA 5510 Working but Workstations Not

[dhyland]

We have an ASA running 8.2(3) and have two site-to-site VPNs running on it.  The second VPN we just established the other day and, from the ASA itself, it appears to be working.  We are able to ping remote hosts from the ASA without issue.  However, on this second VPN any hosts on our LAN cannot reach the remote side...  Trying to figure out what might be going on.  Applicable config below (please forgive errors and formatting):

interface Ethernet0/0

nameif outside

security-level 0

ip address WAN.IP.ADDR 255.255.255.224

!

interface Ethernet0/1

nameif inside

security-level 100

ip address 192.168.21.1 255.255.255.0

!

interface Ethernet0/2

shutdown

nameif intf2

security-level 0

no ip address

!

interface Ethernet0/3

shutdown

no nameif

no security-level

no ip address

!

interface Management0/0

shutdown

nameif management

security-level 100

no ip address

management-only

!

access-list outside_cryptomap extended permit ip 192.168.21.0 255.255.255.0 10.50.50.0 255.255.255.0

access-group acl_out in interface outside

crypto ipsec transform-set ATLAS-TS esp-3des esp-sha-hmac

crypto ipsec security-association lifetime seconds 28800

crypto map mymap 2 match address outside_cryptomap

crypto map mymap 2 set peer PEER.WAN.IP.ADDR

crypto map mymap 2 set transform-set ATLAS-TS

crypto map mymap 65535 ipsec-isakmp dynamic dynmap

crypto map mymap interface outside

crypto isakmp identity address

crypto isakmp enable outside

crypto isakmp policy 5

authentication pre-share

encryption 3des

hash sha

group 2

crypto isakmp nat-traversal 10

tunnel-group PEER.WAN.IP.ADDR type ipsec-l2l

tunnel-group PEER.WAN.IP.ADDR ipsec-attributes

pre-shared-key *****

[Jouni Forss]

Hi,

Are you saying that you have 2 L2L VPN connections and your LAN hosts can PING/ICMP through the original L2L VPN connection but not through the new L2L VPN?

To me this seems that the remote site for the new L2L VPN simply doesnt allow ICMP or its blocked on the actual destination hosts.

None of the above settings should prevent any ICMP between the sites.

You could always configure traffic capture on the LAN interface of the ASA to determine if it sees the ICMP Echo and if it sees the ICMP Echo reply coming back from the remote site.

- Jouni

[dhyland]

"Are you saying that you have 2 L2L VPN connections and your LAN hosts can PING/ICMP through the original L2L VPN connection but not through the new L2L VPN?"

Yes.  But, on the ASA itself, I can ping either of the remote ends hosts (including hosts on the newest VPN LAN) from the inside interface.

[dhyland]

Logging shows the following when performing a traceroute from the ASA (so it appears that ping/ICMP works but not traceroute...):

6          Aug 09 2013          10:31:49                    192.168.21.1          1728          10.50.50.60          39554          Routing failed to locate next hop for udp from NP Identity Ifc:192.168.21.1/1728 to inside:10.50.50.60/39554

[Jouni Forss]

Hi,

That should not be possible unless you have included your ASAs public IP address to the L2L VPN configurations since ASA uses its "outside" interface IP address when sending ICMP through that interface.

I am slightly confused here. Your above post would seem to indicate everything is working from behind "inside" interface?

- Jouni

[dhyland]

Pinging from the ASA:

ping

Interface: inside

Target IP address: 10.50.50.60 (remote host)

Repeat count: [5]

Datagram size: [100]

Timeout in seconds: [2]

Extended commands [n]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.50.50.60, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 30/34/40 ms

[Jouni Forss]

Hi,

Can you post the routing table of the ASA.

- Jouni

[dhyland]

Gateway of last resort is WAN.GATEWAY.IP.161 to network 0.0.0.0

C    WAN 255.255.255.224 is directly connected, outside

S    172.16.3.20 255.255.255.255 [1/0] via 192.168.21.2, inside

C    192.168.21.0 255.255.255.0 is directly connected, inside

S    10.1.21.25 255.255.255.255 [1/0] via 192.168.21.5, inside

S    10.1.21.20 255.255.255.255 [1/0] via 192.168.21.5, inside

S    10.1.21.21 255.255.255.255 [1/0] via 192.168.21.5, inside

S    10.1.17.0 255.255.255.0 [1/0] via 192.168.17.6, inside

S    10.1.21.120 255.255.255.255 [1/0] via 192.168.21.5, inside

S    10.1.21.121 255.255.255.255 [1/0] via 192.168.21.5, inside

S    10.1.21.112 255.255.255.255 [1/0] via 192.168.21.5, inside

S    10.1.21.113 255.255.255.255 [1/0] via 192.168.21.5, inside

S    10.1.21.110 255.255.255.255 [1/0] via 192.168.21.5, inside

S    10.1.21.111 255.255.255.255 [1/0] via 192.168.21.5, inside

S    10.1.21.130 255.255.255.255 [1/0] via 192.168.21.5, inside

S*   0.0.0.0 0.0.0.0 [1/0] via WAN.GATEWAY.IP.161, outside

S    192.168.0.0 255.255.0.0 [1/0] via 192.168.21.5, inside

[Jouni Forss]

Hi,

Seems there is only LAN routes and the default route. So you most likely are not using the "crypto map set reverse-route" which would insert the routes automatically for the remote networks for each L2L VPN connection. (Would need the command for each L2L VPN connection)

Though I dont think this is any problem as your default route should handle forwarding traffic through the VPN.

I very rarely use traceroute or ICMP to test actual L2L VPN connections from hosts or ASAs themselves. I mostly use "packet-tracer" to confirm that the ASA configurations are correct and that the L2L VPN negotiation goes through.

If I can confirm with the "show crypto ipsec sa peer " that my side is encapsulating/encrypting traffic on the L2L VPN connection and there is no return traffic THEN I would usually ask the remote end to confirm that ICMP messages are received and check their site.

I am guessing the reason your ICMP from the ASA works directly is because even though the ASA uses the "inside" interface for the source IP address for ICMP it doesnt apply any NAT to that traffic. And in this case it naturally isnt needed.

Have you checked that the NAT0 configuration for your new L2L VPN connection exists?

There is no NAT0 configuration in the original post.

You could also take this "packet-tracer" output

packet-tracer input inside icmp 192.168.21.100 8 0 10.50.50.60

Issue the command twice. As we are talking about the L2L VPN connection testing the first output might end in a VPN Phase DROP.

- Jouni

[dhyland]

Thanks for your response, Jouni.  The following is the result of the packet-tracer (so, if I'm not mistaken it appears that NAT is probably the issue?  I just used the wizard for this VPN and, in the past, it has created the necessary NAT exemption..?):

packet-tracer input inside icmp 192.168.21.100 8 0 10.50.50.60

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

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: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside) 1 0.0.0.0 0.0.0.0

  match ip inside any outside any

    dynamic translation to pool 1 (WAN.IP.ADDR.162 [Interface PAT])

    translate_hits = 6186208, untranslate_hits = 145616

Additional Information:

Dynamic translate 192.168.21.100/0 to WAN.IP.ADDR.162/12936 using netmask 255.255.255.255

Phase: 7

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

nat (inside) 1 0.0.0.0 0.0.0.0

  match ip inside any outside any

    dynamic translation to pool 1 (WAN.IP.ADDR.162 [Interface PAT])

    translate_hits = 6186230, untranslate_hits = 145616

Additional Information:

Phase: 8

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 6483357, 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

[Jouni Forss · Accepted solution]

Hi,

Seems to me that its hitting the Dynamic PAT rule meant for Internet traffic

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside) 1 0.0.0.0 0.0.0.0

  match ip inside any outside any

    dynamic translation to pool 1 (WAN.IP.ADDR.162 [Interface PAT])

    translate_hits = 6186208, untranslate_hits = 145616

Additional Information:

Dynamic translate 192.168.21.100/0 to WAN.IP.ADDR.162/12936 using netmask 255.255.255.255

So you might be missing the NAT0 configuration for this connection

So do the following things

Issue the command "show run nat" and you should see a NAT0 configuration for the "inside" interface. Something like this

nat (inside) 0 access-list

Then you will have to check the ACL configuration

show run access-list

You will have to add the local and remote network that need to communicate through this L2L VPN connection to that ACL

So for examples sake lets presume that your ASAs directly connected "inside" subnet needs to access the remote network, then you would add

access-list permit ip 192.168.21.0 255.255.255.0 10.50.50.0 255.255.255.0

So use the above configuration format with the correct source and destination network and also the correct ACL name and add the needed lines to the ACL and then try the connections from LAN hosts again.

Hope this helps

Please do remember to mark a reply as the correct answer if it answered your question.

Feel free to ask more if needed

- Jouni

[dhyland]

Thank you for your help and attention this morning, Jouni!  That seems to have done the trick!

[Jouni Forss]

Hi,

Glad to hear its working

I dont really use ASDM to configure anything on the ASA myself. Though I seem to remember that the few times I did configure L2L VPN through the Wizard that I was sometimes missing the NAT0 configuration.

As you can now compare the "packet-tracer" output above and the one you get after the configuration change it should probably help  you in the future if you run into similiar problem.

Naturally writing here on the CSC is always an option.

- Jouni

[Jouni Forss]

Hi,

I am kind of wondering why the log message indicate that it would be sending traffic destined to 10.50.50.60 to "inside"?

- Jouni