topic Re: Strange behaviour after R80.20 upgrade in General Topics

Strange behaviour after R80.20 upgrade

Rene_Rosenkrant — Tue, 04 Dec 2018 12:05:55 GMT

I have a problem that occured on R80.20. In the end we had to move a VPN, Can someone explain why you can have an ESP and ARP broadcast at the same time?

10:12:10.207381 00:12:c1:ce:90:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: x.x.x.x ^ x.x.x.x: ESP(spi=0x78e02e92,seq=0xb7), length 100 10:12:13.210228 00:12:c1:ce:90:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: x.x.x.x ^ x.x.x.x: ESP(spi=0x78e02e92,seq=0xb8), length 100

Re: Strange behaviour after R80.20 upgrade

PhoneBoy — Wed, 05 Dec 2018 02:40:52 GMT

Without knowing anything about your configuration or other errors you encountered, what traffic you were trying to initiate through, etc, it's difficult to say why.

Explaining what the different IPs are would be helpful (having them all x.x.x.x doesn't help).

Re: Strange behaviour after R80.20 upgrade

Rene_Rosenkrant — Wed, 05 Dec 2018 09:47:55 GMT

Thank you for the answer. The IPs are both ends of a VPN tunnel. Source IP is the local gateway external IP and the destination is the peer gateway IP.

The IP packet is forwarded to the right interface, so to my understanding the layer 2 part is working. we see no ethertype ARP requests to know the IP.

Still, the packet is forwarded to the outgoing interface, but with a layer 2 broadcast MAC as destination.

Other VPNs are running fine via the same default gateway, the only difference is the peer IP, and for one specific IP, a layer 2 broadcast is send.

This is an example of something that works:

10:14:08.809013 00:12:c1:ce:90:08 ^ 00:00:5e:00:01:33, ethertype IPv4 (0x0800), length 134: 198.45.128.10 ^ 64.62.2.253: ESP(spi=0xce785fc9,seq=0x1f), length 100 (IPs changed)

The question is more, if there is any situation where the packet below is valid according to RFC. I have a ticket with Checkpoint but I wanted to ask here also.

10:12:10.207381 00:12:c1:ce:90:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: x.x.x.x ^ x.x.x.x: ESP(spi=0x78e02e92,seq=0xb7)

Re: Strange behaviour after R80.20 upgrade

PhoneBoy — Wed, 05 Dec 2018 17:42:11 GMT

The MAC address in question suggests it's going to a VRRP cluster of some sort.

See: Virtual Router Redundancy Protocol - Wikipedia

What should be the actual next-hop in this case?

Re: Strange behaviour after R80.20 upgrade

Rene_Rosenkrant — Fri, 07 Dec 2018 13:55:57 GMT

Yes.

when it Works, the package should be forwarded to 00:00:5e:00:01:33 which is the Internet routers VRRP MAC.

10:14:08.809013 00:12:c1:ce:90:08 ^ 00:00:5e:00:01:33, ethertype IPv4 (0x0800), length 134: 198.45.128.10 ^ x.x.x.x: ESP(spi=0xce785fc9,seq=0x1f), length 100

When it fails the VRRP MAC is replaced with a broadcast MAC.

10:12:10.207381 00:12:c1:ce:90:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: 198.45.128.10 ^ x.x.x.x: ESP(spi=0x78e02e92,seq=0xb7), length 100

It is important to mention that this only happened for one VPN!

Re: Strange behaviour after R80.20 upgrade

PhoneBoy — Fri, 07 Dec 2018 19:33:15 GMT

Sounds like a TAC case is in order then.

Re: Strange behaviour after R80.20 upgrade

Niels_van_Sluis — Thu, 14 Feb 2019 17:48:26 GMT

Did you ever solved this? Seeing the same thing on a VSX platform running R80.20 Take_33.

Re: Strange behaviour after R80.20 upgrade

Rene_Rosenkrant — Fri, 08 Mar 2019 11:31:36 GMT

Hi. I had a TAC case but its closed now. its not solved. RnD asked for more debugs but we need to continue our upgrades now. I can only encourage everybody, who sees this, to contact support. our ticket was this.

As long as we don't disable secure-XL 'fwaccel off' the VPNs will be stable.

If we disable 'fwaccel off' all VPNs will eventually fall apart and die. some VPNs are impacted at once so be carefull.

it seems like a R80.20 issue.

3-0641880071

Re: Strange behaviour after R80.20 upgrade

Niels_van_Sluis — Fri, 15 Mar 2019 14:52:35 GMT

Hi Rene,

Thanks for your reply. I can confirm it is related to fwaccel. For more info on that see my other post here:

https://community.checkpoint.com/t5/General-Management-Topics/vpn-r80-20-vsx/td-p/15269

Our case with TAC is still open, however Check Point claims that there are no other customers who have this specific issue.

Kind regards,

--Niels

Re: Strange behaviour after R80.20 upgrade

Martijn — Tue, 19 Nov 2019 15:03:28 GMT

Hi all,

We have a customer on R80.30 with the same problem and opened a case with TAC. And after a long time it seems to be solved in R80.30 ongoing take 76.

ID: PRJ-1420, PRJ-4740, GAIA-5136 "Improved the VPN connectivity for VSX and User-Space Firewall gateways.

ID: PRJ-4740, PRJ-1420 "In some scenarios, VPN Encryption Domain Routes are not added to kernel via RIM in VSX environment. Refer to sk154692."

Check Point support mentioned three customer for which ongoing take 76 was the solution. Our customer performed the first test and it seems his VPN problems are also solved.

Not sure this fix wil be merged into a jumbo on R80.20.

Regards, Martijn