- Products
- Learn
- Local User Groups
- Partners
-
More
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
IDC Spotlight -
Uplevel The SOC
Important! R80 and R80.10
End Of Support around the corner (May 2021)
I have 3 sites each fitted with a Check Point 1120 appliance running R77.20.75 on Central Management using a Smart-1 R77.30 Management Server.
FW-1
FW-2
FW-3
FWM
Each of these appliances have a public static address, and site-to-site VPN enabled, where FW-1 is the hub and FW-2 and FW-3 are spokes.
FW-1 is at the main site and has a MPLS connection to our datacentre with routes propagated via OSPF. In order to get OSPF routes over to the 2 Spoke Firewalls (as opposed to defining encryption domains on FW-1), I enabled VTI and got it to work wonderfully.
However after the VTIs were enabled, the RemoteAccess Office Mode stopped working. Remote workers usually connect to FW-1 and receive a 10.1.0.x/24 address. They still do, but after doing so the connection would either drop, or the client E80.92 would show a bunch of ENCRYPTED Packets and bytes but DECRYPTED will say 0.
I then went into the console of FW-1 and did a "vpn tu" command and the VPN Sessions are in the IKE SA/ISAKMP SA; however when I ping the office mode client from FW-1's Console, it shows "Destination Host Unreacheable". In Smart Log / Smart Event I do not get the "ENCRYPT" action any more. Nothing is logged.
It looks like theres some sort of bug or incompatbility with VTIs and Remote Access? AFAIK the Remote Access uses ENCRYPT i.e. no interface for the packets to route. but after enabling VTI Routing VPN, it looks like the firewall forgot how to ENCRYPT.
Anyone come across this and any way around it?
Many thanks!
Thanks for the reply. I figured out what was going on, it was a silly mistake. I got two subnets behind the firewall attached to a Layer3 switch that doesn't have OSPF or any routing protocol support, so to get those routes onto OSPF I created an aggregate route. The Office Mode IP happened to fall within the aggregate route, which is a Reject Route on the routing table. I moved the Office Mode IPs to another subnet outside the bounds of the aggregate route and everything is working fine now!
I thought R77.20.80 was the last one for 1100 series and R77.20.81 and higher are for the next generation 1400, 1200R series?
Thanks for the reply. I figured out what was going on, it was a silly mistake. I got two subnets behind the firewall attached to a Layer3 switch that doesn't have OSPF or any routing protocol support, so to get those routes onto OSPF I created an aggregate route. The Office Mode IP happened to fall within the aggregate route, which is a Reject Route on the routing table. I moved the Office Mode IPs to another subnet outside the bounds of the aggregate route and everything is working fine now!
I thought R77.20.80 was the last one for 1100 series and R77.20.81 and higher are for the next generation 1400, 1200R series?
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY