- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
04-06-2017 11:17 AM
Hi all. I am trying to setup a site to site VPN tunnel with one of our customer. I've got the dedicated layer 3 zone, tunnel interface, IKE Gateway, Virtual Router etc. configured per the Palo Alto admin guide. In the "IPSec Tunnels" section, it shows the VPN tunnel is up. However, I cannot access any of the server located at the customer's environment.
In the Traffic monitor tab, it shows the traffic is sending over to the customer's network, yet nothing is returning from them (Bytes Send = xxx; Bytes Received = 0; Packet Send = xxx, Packet Received = 0).
Am I missing something here?
Thank you.
04-06-2017 11:29 AM
Hi UXPSystems,
I'd say either the reply packet is getting dropped or we are simply not receiving any replies.
Take pcaps with filters:
1 - x.x.x.x - y.y.y.y
2 - y.y.y.y - x.x.x.x
The numbers '1' and '2' are the 2 rows you will create in the packet filter. The addresses x.x.x.x and y.y.y.y are the source and destination (and back) for the actual IPs you are pinging from and to. Configure packet capture for the drop, receive and transmit stage. Refer to this KB for more information on pcaps - https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Run-a-Packet-Capture/ta-p/62390
If we are simply not receiving packets, then the issue could be return route on the remote site. If we are receiving packets, then we'd have to check in the counters and flow basic (debug logs) to find out where it's going.
Additionally, select more colums in the traffic logs, like ingress and egress interfaces, etc.
Regards,
Anurag
04-06-2017 01:49 PM
Worth checking the below article:
> show vpn flow name - check encap/decap bytes
Just some additional info!
04-07-2017 08:34 AM
Hi. The PCAP Receive filter file shows bunch of TCP Retransmission to the target server. Wondering if the traffic doesn't know how to reach to the target ....
04-07-2017 08:39 AM - edited 04-07-2017 08:44 AM
Hi,
Packets received by the firewall from your side, right? Do you have a static route configured pointing to the tunnel interface to reach another end subnet?
FIB lookup.
04-07-2017 08:42 AM
is it a PA on both ends of the tunnel? or what device are they using? dunno if it's of any help, but just throwing it out there because there is the requirement of the use of proxy ids in order to establish a tunnel with a policy-based vpn device to essentially identify the interesting traffic.
04-07-2017 08:45 AM
@bradk14 another good point. Phase 2 definitely would not be up if proxy ID mismatch.
04-07-2017 09:46 AM
I am not sure about the VPN product that the other end is using. As a test, if I configured the Proxy ID, the tunnel status goes into "down" state (red).
A static route existed for the remote network
If I do a tracert to the remote server, the tracert stops at our PA firewall.
The PA traffic monitor will show packets has send to the remote network, but no packet receives (eg: no return traffic).
I am wondering if the remtoe network didn't configure their route properly. Otherwise I don't see any issue on the VPN tunnel side, it is up, just no traffic coming back. Also the tracert result bothers me, as it shows stopped on our PA.
04-07-2017 11:22 AM
If you don't configure ProxyID in Palo it falls back to default ProxyID and sends over 0.0.0.0/0
ProxyID is needed only if you connect to device that does policy based vpn instead of route based vpn.
Most likely other end does not have route back to you.
04-07-2017 11:35 AM
@Raido_Rattameister@UXPSystems as you said seems like other side having an issue to return traffic. You also can check encapsulation counters:
> show vpn flow name - check encap/decap bytes
Will give you a very good indication that the traffic is encapsulated and sent through the tunnel.
04-10-2017 09:52 AM
Hi all.
So I ran the "show vpn flow name" command, and I can see the "encap/decap bytes" field logs data there, and no authentication errors. The tunnel looks perfectly fine. Pretty much stuck on this one ...
04-10-2017 10:32 AM
You don't run this tunnel between Azure on PAN-OS 7.1.3 or previous versions, do you?
04-10-2017 02:23 PM
Hi. Nope, not running on Azure. It looks like the customer end is running on Juniper firewall if that helps.
04-10-2017 02:29 PM
Let's ask kindly @santonic
04-10-2017 03:54 PM
Did you check the reply traffic route in the routing table of the peer (Juniper)?
Take pcaps on the peer and see if it's receiving packets from PA and/or sending anything back.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!