topic Re: IPSec VPN decapsulation bytes are increasing and encapsulation is constant in General Topics

IPSec VPN decapsulation bytes are increasing and encapsulation is constant

TranceforLife — Wed, 02 Aug 2017 14:23:31 GMT

Hi All,

Followed this article on teh troubleshooting session:

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

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

Re: IPSec VPN decapsulation bytes are increasing and encapsulation is constant

Raido_Rattameister — Wed, 02 Aug 2017 15:29:26 GMT

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?

Re: IPSec VPN decapsulation bytes are increasing and encapsulation is constant

TranceforLife — Wed, 02 Aug 2017 15:38:10 GMT

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 (

Re: IPSec VPN decapsulation bytes are increasing and encapsulation is constant

Raido_Rattameister — Wed, 02 Aug 2017 15:59:32 GMT

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?

Re: IPSec VPN decapsulation bytes are increasing and encapsulation is constant

TranceforLife — Wed, 02 Aug 2017 16:17:35 GMT

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.

Re: IPSec VPN decapsulation bytes are increasing and encapsulation is constant

Remo — Wed, 02 Aug 2017 17:14:23 GMT

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?

Re: IPSec VPN decapsulation bytes are increasing and encapsulation is constant

TranceforLife — Sun, 06 Aug 2017 12:09:27 GMT

Hello @Remo,

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

Re: IPSec VPN decapsulation bytes are increasing and encapsulation is constant

TranceforLife — Mon, 07 Aug 2017 12:08:10 GMT

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-the-CLI/ta-p/55911

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.