08-02-2017 07:23 AM
Hi All,
Followed this article on teh troubleshooting session:
We currently have an issue with S2S VPN between Palo and WatchGuard Fws.
VPN is up (at least from Palo site). Traffic is initiated from the WatchGuard side (10.10.1.85 src ip) going to the dst ip 10.81.224.11 and visible from our side. From the VPN flow we can see that PA is doing decap bytes but not encap. WatchGuard side also can see that they are sending traffic but 0 bytes received back. I have checked policies and FIB lookup and all look good. But we must missing something.
Thx,
Myky
08-07-2017 04:12 AM - edited 08-07-2017 05:08 AM
Just FYI:
Had a TAC case opened for this issue. Some PBF rule had a misconfigured object, so the firewall was sending the traffic using that rule (reply traffic). Good to know to check next time not only FIB Lookup but also check PFB Lookup. Correcting the object fixed the issue.
EDIT:
We were not able to initiate any traffic from teh Palo side as by design we had no allow policy. It is one-way C2S traffic. Server cannot initiate the session.
08-02-2017 08:29 AM
If you ping 10.10.1.85 that is at peer site from behind Palo and check traffic log what is egress interface for this traffic?
Are those ping requests sent to correct tunnel interface?
08-02-2017 08:38 AM
When l was checking the logs l could see that the traffic was arriving on the correct tunnel.37 interface and going out the eth 1/5 interface. from the PCAPs from the PA FW l can see both ping request(10.10.1.85)/reply(10.81.224.11) as well as allow logs for this particular session:
test routing fib-lookup virtual-router default ip 10.10.1.85
--------------------------------------------------------------------------------
runtime route lookup
--------------------------------------------------------------------------------
virtual-router: default
destination: 10.10.1.85
result:
interface tunnel.37, metric 10
--------------------------------------------------------------------------------
Must be something fundamental (
08-02-2017 08:59 AM
Ok but can you ping from 10.81.224.11 to 10.10.1.85?
Is Egress interface tunnel.37
Do you see encap counter increasing?
08-02-2017 09:17 AM
I know what do you mean @Raido_Rattameister but unfortunately, l had no chance to test reverse traffic as the server admin was away.
Definitely, can confirm that PA can see the reply from the server and definitely based on the FIB Lookup it will forward to the tunnel.37 interface.
08-02-2017 10:14 AM
Did you only check with icmp or also with establishing a tcp connection (not just the tcp handshake?
In addition to that, as I have learn, there is also always the possibility that one side made mistakes in the implementation of the algorithms ... so could you also share the pan-os version and the algorithms you used for the connection?
08-06-2017 05:09 AM
Hello @Remo,
Yes, initial test was with RDP session. PAN-OS 7.1.5 and l will share VPN config tomorrow. Thx all
08-07-2017 04:12 AM - edited 08-07-2017 05:08 AM
Just FYI:
Had a TAC case opened for this issue. Some PBF rule had a misconfigured object, so the firewall was sending the traffic using that rule (reply traffic). Good to know to check next time not only FIB Lookup but also check PFB Lookup. Correcting the object fixed the issue.
EDIT:
We were not able to initiate any traffic from teh Palo side as by design we had no allow policy. It is one-way C2S traffic. Server cannot initiate the session.
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!
