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

vpn r80.20 vsx

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?

Tags (2)
7 Replies
Admin
Admin

Re: vpn r80.20 vsx

Sounds exactly like this thread:

Re: Strange behaviour after R80.20 upgrade

I recommend opening a TAC case so we can troubleshoot.

0 Kudos

Re: vpn r80.20 vsx

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.

0 Kudos
Admin
Admin

Re: vpn r80.20 vsx

No worries Smiley Happy

0 Kudos
Highlighted

Re: vpn r80.20 vsx

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

0 Kudos

Re: vpn r80.20 vsx

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.

0 Kudos

Re: vpn r80.20 vsx

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

Re: vpn r80.20 vsx

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

0 Kudos