vpn r80.20 vsx

[PEO]

I face a situation in a VSX R80.20 environment, where IPsec ESP traffic are send to the broadcast MAC instead of the HSRP multicast MAC of the the adjacent routers.

The VPN tunnel is established and other IPsec ESP traffic between the same two VPN terminating gateways are send correctly.

14:40:23.536514 00:12:c1:60:60:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: 195.245.193.10 ^ 14.140.181.162: ESP(spi=0x2a89b0a5,seq=0x1), length 100
14:40:31.365572 00#:12:c1:60:60:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: 195.245.193.10 ^ 14.140.181.162: ESP(spi=0x2a89b0a5,seq=0x2), length 100
14:40:31.366350 00:12:c1:60:60:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: 195.245.193.10 ^ 14.140.181.162: ESP(spi=0x2a89b0a5,seq=0x3), length 100
14:40:31.549969 00:12:c1:60:60:08 ^ Broadcast, ethertype IPv4 (0x0800), length 134: 195.245.193.10 ^ 14.140.181.162: ESP(spi=0x2a89b0a5,seq=0x4), length 100

Any thoughts?

[PhoneBoy]

Sounds exactly like this thread:

Re: Strange behaviour after R80.20 upgrade‌

I recommend opening a TAC case so we can troubleshoot.

[PEO]

Yes, you are right. It is the exactly the same.

Sorry, I was not aware that my colleague already had posted this issue on CheckMates.

[PhoneBoy]

No worries

[Niels_van_Sluis]

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

[PEO]

Not really. We still have an open case with TAC.

Seems to be related to SecureXL(do not disable) and CoreXL. Helped to give the vs 2 cores instead of 1, but the immedate resolution could be due to restart of the vs.

[Niels_van_Sluis]

Hi Poul,

Thanks for your reply. I've opened also a case with TAC. Does this issue has impact on the operation of the tunnels that are having this issue? In our setup Check Point droppes this traffic, due to 'local interface spoofing'. As a workaround I have disabled local interface spoofing and it seems to have a positive effect on the tunnel. I hope we can get a fix for this issue soon.

Kind regards,

     --Niels

[Niels_van_Sluis]

Hi Poul,

Here a small update. Like you mentioned, the issue seems to be related to SecureXL. It seems that VPN acceleration was added in R80.20. Traditional SecureXL (fwaccel on/off) and the new VPN acceleration (vpn accel on/of) can disturb each other. When investigating in my lab I've noticed that the new 'vpn accel on/of' commands, are added when installing a Jumbo HFA (I'm using Take 47). See below:    

[Expert@cp-fw-01:0]# vpn accel

Usage:
vpn accel off
vpn accel off -y
vpn accel off <peer_1_main_ip>
vpn accel off <peer_1_main_ip> <peer_2_main_ip>
vpn accel off -y <peer_1_main_ip>
vpn accel off -y <peer_1_main_ip> <peer_2_main_ip>
vpn accel on
vpn accel on -y
vpn accel stat
vpn accel -h
[Expert@cp-fw-01:0]#

With the command 'vpn tu tlist' you can see if a tunnel has acceleration on or off. The acceleration flag is marked by the 'p'. See example below:

[Expert@cp-fw-01:0]# vpn tu tlist
+-----------------------------------------+-----------------------+---------------------+
| Peer: 10.23.92.25 - cp-fw-02 | MSA: ffffc20033ee0030 | i: 1 ref: 4 |
| Methods: ESP Tunnel AES-128 SHA1 | | |
| My TS: 10.23.99.0/24 | | |
| Peer TS: 10.23.93.0/24 | | |
| MSPI: 800001 (i: 1, p: 0) | Out SPI: 995c78ea | |
+-----------------------------------------+-----------------------+---------------------+
[Expert@cp-fw-01:0]# vpn accel off

You are about to disable acceleration of VPN tunnels
Note: Relevant accelerated VPN connections will be lost and IPsec SAs will be deleted.
Would you like to continue? (y/n) [n] ? y

VPN acceleration has been disabled (for all peers) and IPsec SAs deleted.
[Expert@cp-fw-01:0]# vpn tu tlist
+-----------------------------------------+-----------------------+---------------------+
| Peer: 10.23.92.25 - cp-fw-02 | MSA: ffffc20033ee0030 | i: 1 ref: 4 |
| Methods: ESP Tunnel AES-128 SHA1 | | |
| My TS: 10.23.99.0/24 | | |
| Peer TS: 10.23.93.0/24 | | |
| MSPI: 800001 (i: 1, p: - ) | Out SPI: 9b408d0b | |
+-----------------------------------------+-----------------------+---------------------+
[Expert@cp-fw-01:0]#

So to fix (workaround) the issue with the nexthop in the ESP packets set to ff:ff:ff:ff:ff:ff, make sure that SecureXL is enabled (fwaccel on) and that all tunnels are accelerated too (make sure the 'p' flag is set to 0).

Kind regards,

     --Niels

[Alex_Shpilman]

Hi Niels,

Did you ever get this issue resolved?

Thanks

[Martijn]

Hi all,

Posted the following in the other item on CheckMates:

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

[MeravAlon]

Hi

Please note this fix was already merged into R80.20 Jumbo HF take 103 (GA since Sep 22nd) . 

Regards,

Merav