IPSec VPN Ingress traffic from two different interfaces not passing traffic.

[rswinter]

Hey All,  We're having a problem in adding new traffic to an existing VPN Tunnel.

We've had a VPN tunnel up for a few years working just fine, but now we are trying to put traffic from a different interface into the Tunnel and the PA is dropping the packets (found them in Traffic Capture).  The VPN is out to the Internet on Eth1/1 and the original ingress traffic to the firewall is on Eth1/5.  All traffic is Natted to a local IP address before entering the tunnel, so no update to the ProxyIDs should be necessary for the new traffic.   The new traffic (and Zone) has been added to the Security Policy and the NAT policy and in the logs it shows it's being natted and allowed, but no traffic passes, and I see it in the Drop file in a packet capture. 

My concern is that either the VPN can't be used for traffic coming from two different interfaces, or that the new traffic coming from a sub interface on Eth1/1 (same physical interface, but different zone and sub interface as outbound VPN tunnel) is not allowed..

Any thoughts/suggestions?

Thanks.

-Stephen

[reaper · Accepted solution]

you can use the filter you set for the packetcapture to inspect global counters:

show counter global filter delta yes packet-filter yes

this will tell you why packets are discarded, most likely a zone issue: the NAT source used for traffic into the tunnel, to which zone does it belong? are you accounting for u-turn zones?

you may need to set up Policy Based Forwarding with symmetric return

[rswinter]

Thanks for the reply.  We have determined it's a NAT issue due to one of the settings, only showing one NAT available.  I have a maintenance window tomorrow morning to make a change suggested by PA support, so we'll see if that fixes the issue.

The Source NAT doesn't have a zone, as it's a fake/virtual address only in the PA itself..  We'll see if the NAT policy change fixes things and go from there...

Thanks.

-Stephen

[rswinter]

Changing the NAT statement solved the issue.   The Source Translation type had originally been set to "Dynamic IP" and changing it to "Dynamic IP and Port" solved the issue.