Internet routing through VPN case

[Nik_Bloemers]

Dear Check Mates,

I have a use case for which I'm not sure what the right/best solution would be, and I'm hoping your input can help.

Currently we have several branch offices that route all traffic (including internet traffic) over a VPN to a Juniper VPN device. The Juniper can put this traffic in a separate routing table so we can set the default gateway towards the internal core router, which then uses it's own default gateway to send the internet traffic through the perimeter Check Point cluster.

We are currently replacing this Juniper VPN device with a separate Check Point cluster. This of course has it's own default gateway to internet to establish various VPN's, so when we move the branch office VPN's to this cluster they will go to internet directly from this cluster, rather than the other perimeter CP cluster where we want the traffic to go to (which is a faster platform with HTTPS inspection, more blades enabled, etc).

How can we solve this? I haven't been able to think of a good way. I thought we could solve this with PBR easily, however sk100500 states that PBR is not supported for VPNs?

Thanks in advance for your insights.

[mdjmcnally]

Is there a reason why cannot use the existing Perimiter Check Point as your VPN Termination point?

That way would be the star community with the existing Check Point as the Central gateway and branches as the Satellites and just work.

Other Potential solution which would be a bit of cheat but would mean don't need to encrypt/decrypt on the existing Check Point Cluster,

Deploy the NEW VPN Check Point Gateway on a DMZ off the existing Check Point Perimeter.

Use the NAT option so that NAT the new VPN Gateway behind a Public IP on the existing perimeter for the purpose of establishing VPN.

Default Gateway would be the DMZ Interface of the Firewall.

Check Point Firewalls on the SAME Management would see the NAT IP so would connect.  Non-Check Point or OTHER Management boxes simply tell them the NAT IP and will be fine.

If is currently a different ISP circuit used for the VPN then as the VPN Gateway IP would be known then could place static routes on the existing permiter to send traffic out over the VPN ISP Circuit.   Obviously move the circuit so that IP range goes to the existing Check Point box.

Obviously would need to pass the Encrypted Traffic through the existing Gateway but not Encrypt/Decrypt

Used a similar topology for another customer (without the other circuit) for another customer using Cisco Branch Routers and a Cisco Router for the VPN Termination.

[Nik_Bloemers]

The customer has bought this new cluster specifically to move all site-to-site VPN's to. We rather not make it dependent on the other cluster, that would sort of defeat the point.

[mdjmcnally]

Is the new Cluster JUST for Site 2 Site VPN's or will there be Remote Access on the Cluster as well.

If is just S2S the could potentially route the Remote Gateways IP via the ISP Circuit and then Default Gateway into the Core.

The New Cluster would then connect to the Internet via the existing Check Point.

I have seen that as a topology done before.

Obviously if Remote Access as well then a None Starter.

[Nik_Bloemers]

So basically there is no way to solve this with routing? The only way Check Point can do this is to put the new cluster behind the existing cluster?

[mdjmcnally]

Is this going to be just for S2S VPN's in which case can Route the S2S VPN Gateways via ISP and Default Gateway towards the Internal Core.

The S2S Cluster then goes via the other Perimeter Firewall to the Internet as well as it forwarding traffic destined from the 

You can do this as you would know the S2S VPN Gateway IP so could route them out to the ISP.

However if you also use for Remote Access where don't know the IP Connecting from then that is a non-starter.

However all that you have mentioned is S2S VPN so this could work.

PBR is not supported once you start turning on certain features

he following features/blades are not supported with PBR:

• IPv6
• URL Filtering
• IPS
• Locally-generated traffic
• Security Servers
• Data Loss Prevention (DLP) blade
• VPN Domain Based
• VPN Route Based
• Anti-Spam blade
• Mail Transfer Agent (MTA) (relevant for Threat Emulation/Threat Extraction/Data Loss Prevention/Anti-Spam blades)
• ISP Redundancy
• The following applications (which use Check Point Active Streaming [CPAS]):
  
  • VoIP (H323, SIP, Skinny, etc.)
  • HTTPS Inspection
  • HTTP Header Spoofing
  • HTTP Proxy
  • IMAP in IPS

Hence why shouldn't use Policy Based Routing for this.

Juniper is fundamentally a very different architecture underneath with the Interface attached to a Zone then the Zone attached to a Router allowing sever routing tables to be used on the same box.

Check Point only allows 1 Routing Table per Firewall System.

If you confirm fully what the new cluster for, ie just S2S or will it be for RA as well then can give a definitive answer as to what can do.

[Nik_Bloemers]

It is just site-to-site VPNs, but a bunch of the sites have dynamic IP addresses, so statically routing the public peer IP's is not an option (we had already considered this).

[mdjmcnally]

With the Dynamic IP S2S Gateways then stuck with the Check Point NAT behind the Perimter Cluster if going to use the Check Point Cluster for the termination as the DG would have to route out to the Internet for the box.

Either that or terminate the VPN on the Perimeter Cluster and dispense with separate VPN Cluster.  Which I appreciate that purchased the new Cluster.

If the S2S Cluster and the Perimeter Cluster managed from the same Firewall then you could potentially enable the Additional Blades on the S2S and simply have the Internet bounce out straight from the S2S Cluster bypassing the existing Perimter Cluster altogether.

Could use a Shared Layer between the two Clusters so the same AppCtrl/URL policy is applied to both.

Logging would be to same place so if there is a SmartEvent then would be able to report still.

Whilst used the topology you want then wasn't with a Check Point Gateway as the seperate VPN.