I've got a rather bizarre setup that I'm trying to integrate with a new customer using a vm-series 300 in AWS. I have setup and established an IPSEC tunnel (that even comes up when we attempt to send traffic over the tunnel). Where it gets complicated is that their expectation is that we NAT all traffic using public IPs and send the traffic through the tunnel (I should mention that the other side is a Cisco ASA device).
I've attached a fairly simple diagram of the setup that's been proposed by the customer on the other side ( IP addresses changed for safety). To sum it up quickly:
* we have a tunnel established between 1.1.1.1 and 2.2.2.2, this tunnel comes up when I attempt to send traffic through it
* I've routed both 3.3.3.3/32 (our side of the nat translation) and 4.4.4.4/30 (their side of the nat translation) into the tunnel interface
* when i attempt to send traffic through the tunnel over port 443 (ex: curl https://10.0.0.2) from our server the tunnel comes up
* i can also see in the traffic monitor that the NAT policy appears to be applying (I can see the 10.x addresses NAT'd to the 3.3.3.3 and 4.4.4.4) addresses respectively.
The customer is reporting that no traffic is coming through on their side. When I try to use the packet capture tool on our side and filter based on interface (tunnel.1 in this case), then try to send traffic, I don't see any packets. Is there anyway to verify that traffic is indeed flowing over the tunnel?
I could also have done something really wrong here, but I'd expect that if the tunnel comes up, some traffic is attempting to be sent.
Hi @birdperson ,
Yes, you can see encaps and decaps from Network > IPSec Tunnels > Tunnel Info next to your VPN.
You can also see them on the CLI with the command 'show vpn flow tunnel-id <tunnel-id> | match "p p"'. This doc is an excellent VPN troubleshooting reference -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClivCAC.
Thanks,
Tom
