l2l VPN with NAT troubleshooting

scottziehr · ‎12-13-2017

I have an l2l vpn established with a partner, I have no control over the partners endpoint. We have some overlapping subnets so I am natting my internal traffic before sending it over the vpn. I have never done this before so am not clear on the order of operations but think I have it right. A sanitized version of my commands is attached.

While trying to browse a website on the REMOTE-SUBNET I run

show cry ipsec sa det

and get the following output:

sho cry ipsec sa det
interface: Outside
Crypto map tag: VPN-CMAP, seq num: 10, local addr: x.x.x.x

access-list VPN-ACL extended permit ip host 10.2.2.1 10.3.3.0 255.255.255.0
local ident (addr/mask/prot/port): (10.2.2.1/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (10.3.3.0/255.255.255.0/0/0)
current_peer: y.y.y.y

#pkts encaps: 2097, #pkts encrypt: 2097, #pkts digest: 2097
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 2097, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#pkts no sa (send): 0, #pkts invalid sa (rcv): 0
#pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
#pkts invalid prot (rcv): 0, #pkts verify failed: 0
#pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
#pkts invalid pad (rcv): 0,
#pkts invalid ip version (rcv): 0,
#pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
#pkts replay failed (rcv): 0
#pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
#pkts internal err (send): 0, #pkts internal err (rcv): 0

So I'm wondering if I have things set correctly or am missing something. I am not sure if there is a way to show for sure whether I would accept any packets over the vpn, i.e. prove or disprove that it's them and not me.

Thanks in advance for any help!

mikael.lahtela · ‎12-13-2017

Hi,

This tells you that something has been sent over the tunnel to the other peer.
#pkts encaps: 2097, #pkts encrypt: 2097, #pkts digest: 2097

ASA will hit NAT first and then Crypto Tunnel configuration, so your crypto tunnel needs to be configured to use the NAT'ed address.
You can also do a packet trace twice to see that you NAT the traffic and VPN goes up.
If that looks correct with the NAT, then the problem is probably on the other end.

br, Micke

scottziehr · ‎12-13-2017

Ok thanks Micke.

So if I run

packet input inside tcp 10.1.1.1 http 10.3.3.3 http detailed

I get 13 Phases, all Allow, including NAT and VPN

but if i run the opposite,

packet input Outside tcp 10.3.3.3 http 10.2.2.2 http detailed

Phase 1 is UN-NAT and that is Allow and looks right but then Phase 2 Access-List is Drop, Drop-reason: (acl-drop) Flow is denied by configured rule

Here is what I don't understand about packet trace. How does it know whether it came across the VPN. so I would expect the ASA to drop traffic coming from 10.3.3.3 on the Outside IF it wasn't encapsulated by the tunnel. So is this test accurate? Am I missing something?

mikael.lahtela · ‎12-13-2017

I don't think you can test VPN with incoming traffic as you have noted there isn't a way to tell packet tracert that the traffic is coming from the tunnel.
But if you packet trace looks ok from you to peer, then the problem is most likely on the other end.

br, Micke