IPSec VPN decapsulation bytes are increasing and encapsulation is constant

[TranceforLife]

Hi All,

Followed this article on teh troubleshooting session:

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

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

[Raido_Rattameister]

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?

[TranceforLife]

Hi @Raido_Rattameister,

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 (

[Raido_Rattameister]

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?

[TranceforLife]

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.  

[Remo]

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?

[TranceforLife]

Hello @Remo,

Yes, initial test was with RDP session. PAN-OS 7.1.5 and l will share VPN config tomorrow. Thx all

[TranceforLife · Accepted solution]

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.

https://live.paloaltonetworks.com/t5/Management-Articles/How-To-Test-Security-NAT-and-PBF-Rules-via-...

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.