P2P VPN One Way Issue

[John Apricena]

Hello Support,

I am having an issue with a P2P VPN. Our side is a Cisco ASA 5512 and the vendor's device is a Untangle Firewall. When we initiate the VPN from the Cisco ASA 5512 end, the VPN comes up fine with no issue and communication passes on both sides. If I take the VPN down, and then have them try to initiate the VPN, I never even see traffic come into our firewall, and it does not come up. When we do a trace from their inside network to our inside network (when initiating from their end), the trace goes to a few edge devices on thier end and out the ISP. We can actually see a few public IPs in the traceroute, however when we initiate the VPN from our end and then run a trace on their end, these same public IPs do not show in the trace.

It almost seems like they have a device on their end that is not properly handling the NAT or NONAT for the private subnets. Does this sound accurate? 

Just to reiterate, when we initiate the VPN, traces look clean and only private IPs show on both ends. When they initiate the VPN, the traffic never hits our firewalls and traces from their end show public IPs in the route. 

As of now we keep a running ping to keep the VPN alive, but this is not ideal. Any help here would be greatly appreciated.

[John Apricena]

bump for assistance.

[pjain2 · Accepted solution]

hey John,

are you sure that when they initiate the traffic from their inside subnet, it is hitting the vpn.

please ask them to run crypto debugs from thier end and check if the first udp 500 is even being sent from their end.

As of now, to keep the tunnel up you can configure SLA monitoring on the ASA:

please follow the below discussion to configure the same:

https://supportforums.cisco.com/discussion/11012751/ip-sla-monitor-vpn

[John Apricena]

Hello,

Thanks for the response. Yes the UDP packet get sent out from their end but never actually hits our firewall. Traces from their private network to ours show public IP in the hops which says to me that NATing is not occurring properly on their end. 

I can can look into the SLA monitor as a temp solution but do you think this is a NAT issue or something else may be going on here?

[pjain2 · Accepted solution]

not sure what exactly is the issue here but looks like the UDP 500 packet when sent from their is getting dropped somewhere.

you can ask the remote side to check each ad every hop on their end to see if something could be blocking the traffic from their end