Hey! I finally see fit to show the world my first 'white paper'. Inspired by a genuine real life use case (Thanks Mr. P & Mr H) it details how OSPF can be used on Check Point gateways in conjunction with a VPN Virtual Tunnel Interface in order to use the VPN as a back up if the inter-site WAN were to fail.
It's useful in many ways, it shows you how to set up Route Based VPN, SecurePlatform Pro's routing suite, and gives you a solid single area OSPF scenario to play with.
Enjoy!
White Paper: Running OSPF on Check Point Gateways for WAN failover to VPN
FOOD FOR THOUGH:
You can also use this scenario (slightly modified) to tell OSPF to distributed a default route, and use this in conjunction with a suitable 'is the internet up' script so that if the UKs internet connection dies, the UK will re-route internet bound traffic over the WAN and through the internet link in the US office. A much simpler solution than BGP peering and a much cheaper solution than an ISP load balancing switch (Radware, F5, etc).
(Note: I didn't test the script above, it's used here as an example only)
If the script says the internet is up, maybe you create it to ping the ISPs DNS server and a few others, it will execute 'route add default gw 1.2.3.4'. If the link is down it will remove the default route with 'route del default'.
Since kernel routes (well, static routes) have a lower administrative distance than OSPF routes, when the internet is up, the gateway will always send traffic out of its internet facing interface, and when the internet is down, the gateway will use the default route it gained from OSPF, and route the traffic to it's peer gateway in the other country, over the WAN.
Yes, hardly a good solution to send all your web browsing across the globe, but much more compelling if your offices are both in the UK.
A little warning however:
If you implement this with the topology detailed you will see that there is an issue with NAT. Check Point gateways perform NAT on all interfaces, so when our traffic from the UK subnet hits the UKFW and is directed out of the WAN interface, it is STILL NAT'd by hide NAT. The solution to this is a topology change. In each office, add an additional router between the internal network and the Check Point gateways, connect them to the WAN (and disconnect the gateways from the WAN) and run OSPF on these. This will ensure that when traffic to the internet is being sent through the WAN, is it not NATed as it doesn't cross a Check Point gateway.
<Rant>
I must say, it's quite annoying to have to do this. If you could push NAT rules to different interfaces, like you can push QoS rules to different interfaces, then you would not need to change the topology. You could simply push a NAT rule to the WAN interface of the gateway that looked somewhat like below, which is effectively a 'don't NAT internal traffic that crosses the WAN' rule:
Interface - WAN Orig Packet - Src: UK Network Dest Any Xlate Packet: - Src: Orig Dst: Orig
(And yes, I did start hacking around in the .pf policy file ;) to see what I could see, but suddenly on looking up I noticed it was 3am!)
Oh well..... Anyone care to submit a request for enhancement with a nice tasty business case? ;)
</Rant>