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?
Best Answer
Ideally these things must match to pass VPN traffic properly:
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:
To check Phase 2:
to check your nat and acl:
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
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*:
*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