3

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?

4
  • I don't think 10.10.10.10 is receiving any acknowledgment packets from 56.132.112.29. S 74549533 is the sequence number in the first line of code, which is acknowldged by the second/third line, ack 74549534 (sequence +1) which is then retrainsmitted by 10.10.10.10 in the fourth line with S 74549533.
    – Ryan Foley
    Mar 5, 2014 at 16:49
  • 1
    Can you please edit and post the config relevant to your VPN setup?
    – A L
    Jul 22, 2014 at 14:50
  • 1
    A picture of your Network Topology would also help. You may have some asymmetric routing going on, ASA's don't play well with asymmetric routing.
    – Eddie
    Oct 20, 2014 at 3:06
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 10, 2017 at 3:08

2 Answers 2

2

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

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.