VPN cisco ASA tcp connection issue -pcap inside

Question

I have set up a VPN between my company and a customer. Packet captures show that the customer receives a packet and then sends an ACK back as it hits our internet firewall, this is as far as the connection will go. The process then repeats itself a few times with the same results.

The packet capture shows all of this on the egress filter, is this normal? I see nothing on the ingress filter.

10.10.10.10.56638 > 56.132.112.29.3205: S 74549533:74549533(0) win 5840 <mss 1380,sackOK,timestamp 2566921403 0,nop,wscale7>

56.132.112.29.3205 > 10.10.10.10.56638: S712870551(0) ack 74549534 win 16384 <mss 1380,nop,wscale 0, nop,nop,timestamp 0 0,nop,nop,sackOK>

56.132.112.29.3205 > 10.10.10.10.56638: S712870551(0) ack 74549534 win 16384 <mss 1380,nop,wscale 0, nop,nop,timestamp 0 0,nop,nop,sackOK>

10.10.10.10.56638 > 56.132.112.29.3205: S 74549533:74549533(0) win 5840 <mss 1380,sackOK,timestamp 2566921403 0,nop,wscale7>

Then I decided to capture on the next firewall and found results that I do not understand:

ingress:

10.10.10.10.55640 > 56.132.112.29.3205: S 155629610:155629610(0) win 5840 <mss 1380, sackOK, timestamp 2568128672 0, nop, wscale 7>

10.10.10.10.55640 > 56.132.112.29.3205: S 155629610:155629610(0) win 5840 <mss 1380, sackOK, timestamp 2568128672 0, nop, wscale 7>

egress:

10.10.10.10.55640 > 56.132.112.29.3205: S 3671255214:3671255214(0) win 5840 <mss 1460, sackOK, timestamp 2568128672 0, nop, wscale 7>

10.10.10.10.55640 > 56.132.112.29.3205: S 3671255214:3671255214(0) win 5840 <mss 1460, sackOK, timestamp 2568128672 0, nop, wscale 7>

So of course the egress is fine, these are the packets leaving our network to the internet firewall. What does the ingress filter mean? To me it says that a packet has arrived at my internetdmz and matches the packet that left with regards to the source and destination IP. This does not make sense to me. Can anyone explain why this is?

Answer 1

Ideally these things must match to pass VPN traffic properly:

• ACLs
• NATs
• ISAKMP (or phase 1)
• IPSEC (or phase 2)

What you're seeing is probably that one side is encrypting traffic properly but the other side is not. That is why your ACKs are not making it past the firewall. When the firewall gets the packet on the outside interface, it doesn't know what to do with it. Typically, if your security association is formed but traffic is not flowing, it will come down to ACLs and/or NAT.

To check Phase 1:

• crypto isa sa (Here you should see "status active")

To check Phase 2:

• crypto ips sa (Look for packets rec and send)

to check your nat and acl:

• packet-tracer input inside tcp YourSRCIP SRCport(make it up, doesn't matter) REMOTEIP REMOTEPORT

In 8.4 ASA software you have Real IP, meaning all your traffic deals with the LAN IP's of the machines. So packet tracer would like like this considering

• Your Source IP: 10.10.10.10

• Remote LAN IP: 172.20.10.10

• packet-tracer input inside tcp 10.10.10.10 4444 172.20.10.10 80

This will simulate a pakcet from your inside interface to 172.20.10.10. You should be able to see each step, from ACL checks, to NAT checks, to if it actually hits a crypto map on the outside interface for encapsulation.

You can also see tunnel creation debug messages with*:

• debug crypto isa 130
• debug crypto ips 130

*careful with debug messages on production firewalls.

What it looks like right away:

Your Firewall does not appear to be getting packets from the outside interface to the inside. This is evident in your top code block, lines 1 and 4 are tcp retransmissions, meaning that lines 2 and 3, the requests for the next packets, never made it to your inside end device. Also at some point I'd expect to see packets with a src and dst ip of internal networks, these packets in your post are all LAN to WAN IPs.

This could be because the remote side is not encapsulating vpn traffic properly, or because your firewall is not handling the received traffic correctly.

I would suspect that your customers end device is receiving everything correctly, but that it's replies are not being encrypted for the return travel. That would result in the return traffic not matching your NAT statement. This is basically one way vpn communication.

Cisco KB has more info on these issues:

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/81824-common-ipsec-trouble.html

Answer 2

Could be a policy mismatch, I would like to see the configuration of both endpoints, including the policies (read: interesting traffic access-lists).

Also I would check if packets are being encapsulated and decapsulated on both ends:

# show crypto ipsec sa peer 1.2.3.4

And/or:

# show crypto ipsec sa peer 1.2.3.4 | inc pkts

You could also have a look at what the packet-tracer tells you (ASA built-in command line tool):

# packet-tracer input INSIDE tcp 10.10.10.10 55640 56.132.112.29 3205

But beware, when troubleshooting VPN's, packet-tracer only generates reliable results if the VPN tunnel is up at that moment. If the tunnel is not fully functional or isn't configured correctly when using packet-tracer, you might get unrealiable results.