Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Site to Site VPN Tunnel is up, but no traffic pass through

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Site to Site VPN Tunnel is up, but no traffic pass through

L2 Linker

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. 

 

18 REPLIES 18

L4 Transporter

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

================================================================
ACE 7.0, 8.0, PCNSE 7

Worth checking the below article:

 

https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Troubleshoot-IPSec-VPN-connectivity-...

 

> show vpn flow name - check encap/decap bytes 

 

Just some additional info!

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 ....

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.

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.

--
CCNA Security, PCNSE7

@bradk14 another good point. Phase 2 definitely would not be up if proxy ID mismatch. 

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. 

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.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

L6 Presenter

@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 

 

UU.PNG

 

Will give you a very good indication that the traffic is encapsulated and sent through the tunnel.

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 ... 

You don't run this tunnel between Azure on PAN-OS 7.1.3 or previous versions, do you?

 

BUG.PNG

 

Hi.  Nope, not running on Azure.  It looks like the customer end is running on Juniper firewall if that helps. 

Let's ask kindly @santonic

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.

================================================================
ACE 7.0, 8.0, PCNSE 7
  • 34528 Views
  • 18 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!