cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post

Strange behaviour after R80.20 upgrade

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
0 Kudos
8 Replies
Admin
Admin

Re: Strange behaviour after R80.20 upgrade

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

0 Kudos

Re: Strange behaviour after R80.20 upgrade

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)

0 Kudos
Admin
Admin

Re: Strange behaviour after R80.20 upgrade

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?

0 Kudos

Re: Strange behaviour after R80.20 upgrade

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!

0 Kudos
Admin
Admin

Re: Strange behaviour after R80.20 upgrade

Sounds like a TAC case is in order then.

0 Kudos

Re: Strange behaviour after R80.20 upgrade

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

Highlighted

Re: Strange behaviour after R80.20 upgrade

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

0 Kudos

Re: Strange behaviour after R80.20 upgrade

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