Checkpoint 1120 Gateway RemoteAccess Broken After Using VTI

[alfreska]

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!

[PhoneBoy]

Not aware of any specific limitation here.
You may want to update to the latest firmware for the 1100 Series (R77.20.81) as there are a couple of VTI-related bug fixes.
You may also want to open a TAC case.

[alfreska · Accepted solution]

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?