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

IPsec to Zscaler

We have many 1100 and 1400 model firewalls that we have migrated over to Zscaler using IPsec VPN to send outbound internet traffic through the Zscaler datacenter for filtering.  We are running only FW and VPN blades.  The VPN is up and running, however, we are noticing very slow performance in speeds and file downloads.  We have an open case with TAC and not getting far after taking kernel debugs, fw monitor & packet captures.  When bypassing the VPN by using an explicit proxy or going through firewall directly, speeds are very fast.  I wouldn't expect 1/5 of the allocated circuit speed when going through the VPN tunnel.  Packet captures show MSS values without tunnel is 1460 and via tunnel is 1360 and seeing very small window size value via tunnel.

We have modified the following files without any improvement:

$FWDIR/modules/fwkern.conf
fw_clamp_vpn_mss=1
 
$FWDIR/modules/simkern.conf
sim_clamp_vpn_mss=1
sim_ipsec_dont_fragment=1

We have GRE tunnels working without any problem on our Cisco routers, but Checkpoint doesn't support GRE.  We have optimized the MTU and MSS values for the tunnel and speeds are great.  Unfortunately, you cannot modify these values for a VPN tunnel on a Checkpoint firewall. 

Any insight into a fix or solution would be appreciated.  We are running R80.10 management server.  Thanks

3 Replies
Timothy_Hall
Legend Legend
Legend

Unfortunately this is one of those situations where the appliance models involved are using embedded Gaia, which does not support some advanced features such as Dead Peer Detection (DPD) which would probably help.  Here is the long list of limitations:

sk105380: Check Point R77.20 for 600 / 700 / 1100 / 1200R / 1400 Appliance Known Limitations

What version of code are you running on the appliances?  There have been a ton of fixes related to your situation. 

Here are a few things to try:

1) Try enabling and forcing IKEv2 assuming the Zscaler supports it, IKEv2 has its own PMTUD mechanism to help deal with low MTUs in the network path and the resulting performance problems.

2) Try disabling SecureXL as there have been many known issues in the past with the TCP MSS Clamping feature and SecureXL.  These issues are described in sk101219.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Raj_Khatri
Advisor

Hey Tim,

These appliances are running the latest code/hotfix - R77.20.60.  I tried forcing IKEv2 but there wasn't any improvement.  They don't officially support it, but it does establish a tunnel.  The same goes with SecureXL, disabling doesn't show any improvement.  TAC's response it getting a bigger box which makes no sense as CPU/Memory resources are just fine...

0 Kudos
Timothy_Hall
Legend Legend
Legend

They are probably making that bigger box recommendation more for the capabilities of full Gaia (i.e. not embedded Gaia) to deal with this situation. 

As a last resort try setting the MTU to 1300 on the external interface of the Check Point appliance and on the Zscaler if you have access to it.  This is the equivalent of killing a housefly with a sledgehammer but it should work.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events