How can I confirm that traffic is going over a l2l VPN tunnel?

[DrStalker]

How can I confirm that traffic is going over a l2l VPN tunnel on a Cisco ASA 5510?

I'm trying to troubleshoot a lan-to-lan VPN, and I can see the expected packets with a capture command but the remote site indicates they are not seeing any traffic at all.

How can I confrm that the packets are being sent over the VPN tunnel, and not out on the general Public interface?

[Collin Clark]

Try the command show crypto ipsec sa

ASA# sh cry ipsec sa

interface: OUTSIDE

Crypto map tag: map1, seq num: 20, local addr: a.b.c.d

...

...

#pkts encaps: 65581, #pkts encrypt: 65772, #pkts digest: 65772

#pkts decaps: 85312, #pkts decrypt: 85312, #pkts verify: 85312

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 65581, #pkts comp failed: 0, #pkts decomp failed: 0

#pre-frag successes: 191, #pre-frag failures: 0, #fragments created: 382

#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 572

#send errors: 0, #recv errors: 0

...

...

Also, here is an excellent troubleshooting guide for VPNs.

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml

Hope that helps.

[DrStalker]

Thanks! This looks like a problem:

#pkts encaps: 0,

#pkts decaps: 2259,

I've gone through the VPN troubleshooting guide and havn't found anything that helped there, can anyone offer any pointers on what to look at next?

[Farrukh Haroon]

This happens mostly due to routing or firewall blocking ESP issues.

On the VPN end-point where encaps=0, verifiy that the routing is correct. The show command output reveals that packets are coming from the remote end, but this side does not know how to reach the other end.

If you can post configs,show ip route outputs, perhaps we could help further. You have to check the routing on both the VPN gateway(s) and the machines actually generating the VPN traffic(servers/workstations etc.)

Regards

Farrukh

[DrStalker]

What should I be looking for in the routing? As far as I can tell the ASA is managing the routes (any traffic matching the access-list goes over the tunnel) without exp[licit route entries - that is how it works for all the other tunnels.

Also, how can the routing affect packets based on the source IP? traffic from one local subnet is correctly encapsulated, traffic from the second local subnet is not even though the destination is exactly the same.

[Farrukh Haroon]

The Crypto ACL is never enough. The ROUTE lookup is performed BEFORE the encryption. So routes need to be there even for the remote side's LOCAL subnets.

The output you posted is from the ASA 5510? What device is on the other side?

Are the remote side's local subnet(s) or a deafult route present in the device having encaps = 0?

"show route | include x.x.x.0" for example

IF you are using 7.2.x or later, you can use the packet-tracer command to see exactly why the VPN is failing.

Regards

Farrukh

[DrStalker]

How is the routing rule meant to be defined? As in, if the remote subnet is 172.16.1.0/24 what gateway/interface do I use when I define the route?

I'll have a play around with the packet-tracer command, see what that shows.

[edit] remote device is a Checkpoint software firewall.

[edit2] No packet-tracer command, the ASA is version 7.0(5)

[Farrukh Haroon]

You can point it to anything, does not matter. It will never be routed out anyway. It just needs to be there (Unless you have a default route pointing out the same interface).

Assume your ISP's IP (next-hop) is 11.11.11.1, just put:

route outside 172.16.1.0 255.255.255.0 11.11.11.1

Regards

Farrukh

[DrStalker]

That explains why the other tunnels work fine without an explicit route - the default route is on the outside interface, the same interface the VPN tunnels run on.

This shoudln't be a routing issue, because packets with the same destination act diferently depending on the source subnet, and teh routing table only looks at the destination.

[Farrukh Haroon]

Using the capture command verify if traffic is reaching the ASA from both type of source IPs (working and non-working). If not, double check the routing/DNS on the troublesome machines.

Also from the troublesome source IPs behind the Cisco VPN Gateway, can you ping the remote sides? I mean to say does ICMP traffic work and TCP traffic fail? Then this could be a MTU related issue.

It could also be a configuration issue on the Checkpoint side.

Regards

Farrukh

[DrStalker]

capture shows the expected traffic. This affects ICMP and TCP.

What sort of setting on the Checkpoint router could cause the ASA to not encapsulate the outgoing data? Specific knowledge of Checkpoint aside, what could a remote ipsec endpoint do to make an ASA not encapsulate outgoing data?

[Farrukh Haroon]

To be honest, I was thinking the same, encaps = 0 means most probably something is wrong with the ASA side. But you never know, it could be some proxy ACL/VPN mode incomatiblity issue between the two peers.

These two IPs are in the same subnet? SOURCE IPs)?

Also you can now capture on the 'outside' interface if traffic is LEAVING the interface.

Can't you post your configs? (Sanitized)

Regards

Farrukh

[cisco24x7]

This is the reason it is difficult to find a Security Engineer who are good with a lot of major vendors (Cisco, Checkpoint, Juniper).

The easiest thing to do here is to run tcpdump on the checkpoint firewall and see if isakmp traffics actually leave the Checkpoint firewall. You can turn on additional on the checkpoint firewall by enable "vpn debug iketrunc", "vpn debug ikeoff" and "vpn debug ikeon" to capture the traffics in the ike.elg file. You can then use IKEView.exe to view how phase I and II are negotiated by the Checkpoint firewall. It is very simple. It will tell you exactly where things go wrong.

By the way, in Cisco, route takes place before encryption. However, in Checkpoint, encryption takes place before route. Just something to keep in mind.

Post your configuration and I may be able to help you. I have several L2L vpns between CP NGx and Cisco devices.