Check Point + SDWAN + OSPF + SMB DAIP - TIP

[israelfds95]

I will share my discoveries with you.

Check Point + SDWAN + OSPF + SMB DAIP

I will talk here about an implementation I did using SD-WAN + OSPF + SMB.
It was an interesting approach while trying to solve a complex project. In the end, it moved forward with a BGP deployment, but I always document my work, and this documentation turned out to be very interesting, covering some important details:

Simple topology:

Underlay MPLS 1, MPLS 2 and LTE
Overlay Tunel over the underlays to encrypt/decrypt Traffic

Check Point SD-WAN abstracted the entire underlay, building the overlay and managing all links in a very interesting way, using only a single VPNT — without literally needing, for example, three VPNTs per link and turning it into an exponential complexity problem.

The SD-WAN activation process:

1 - Enabling SD-WAN starts by installing the Nano-agent via CLI on the Quantum Spark device.

2 - Activating the SD-WAN configuration by applying the TAG on the interfaces that will participate in the SD-WAN WAN Link Mapping.

3 - Then, proceed to the Infinity Portal to associate the gateway and create the WAN Link Mapping.

4 - Configure the SD-WAN rules with behaviors and other related settings. However, I will not cover all of that in this article — maybe in a future one.

This configuration was implemented using two MPLS links and one LTE 4G link. The main complexity of this project was that all traffic from the remote branches had to mandatorily go to the headquarters, and from there exit to the Internet.

The Quantum Spark appliances were deployed at the branch offices. They were connected via MPLS to two geographically separated data centers. We used Site-to-Site IPsec VPN with VTI.

Note: In this project, we discovered and validated that only one VPNT is required between the headquarters and the branch — not two VPNTs per interface, regardless of whether the VPNT configuration is numbered or unnumbered. Check Point SD-WAN can handle link failure detection and link switching with only one established VPNT, even though it works differently from other vendors that require per-interface configuration.

Here, we used OSPF ASE.

Circuit ID

In Check Point SD-WAN, the Circuit ID allows tunnel establishment between interfaces that share the same Circuit ID.

Since these were MPLS links, we could not leave them with the default configuration. For example, we could not configure all MPLS 01, MPLS 02, and LTE interfaces as Public within the SD-WAN Portal, because SD-WAN would attempt to establish VPN tunnels between interfaces that would not be able to form tunnels in this topology.

This Circuit ID configuration was edited directly on the interfaces through Gaia, either on the SMB or Enterprise gateway.

Therefore, I modified the Circuit ID for MPLS 01 and MPLS 02 accordingly:

        - MPLS 01 – CIRCUIT ID 10
        - MPLS 02 – CIRCUIT ID 20

This way, HQ 1, HQ 2, and the Remote Site would establish site-to-site VPN tunnels only with their respective Circuit IDs, for example:

HQ 1 MPLS 01 CID 10 - > Branch  MPLS 01 CID 10
HQ 2 MPLS 01 CID 10 - > Branch  MPLS 01 CID 10

HQ 1 MPLS 02 CID 20 - > Branch  MPLS 02 CID 20
HQ 2 MPLS 02 CID 20 - > Branch  MPLS 02 CID 20

HQ 1 WAN1 CID 0       - > Branch  LTE4G CID 0
HQ 2 WAN2 01 CID 0 - > Branch  LTE4G CID 0

For VPNs over LTE 4G using DAIP:

It was necessary to create the gateway in SmartConsole as Dynamic Address (DAIP). This made it possible to establish an IPsec VPN over the dynamic LTE link, as described in the SD-WAN Guide. This was another valuable discovery.

Another Discovery HTTPS and SSH traffic initiated form a Quantum Spark Appliance is not Encrypted When sent through a VPN tunnel.

In this scenario, where the firewall must access the Internet entirely through the overlay, the firewall’s HTTPS traffic — which is essential for the Nano Agent to synchronize with the Infinity Portal — does not go through the overlay; only the LAN traffic does. As a result, the Nano Agent stops communicating with the Infinity Portal.

The solution was described in the SK article below, which explains the issue. We needed to apply a specific parameter so that the firewall’s HTTPS traffic would also go out through the VPN tunnel overlay.

HTTPS and SSH traffic initiated from a Quantum Spark appliance is not encrypted when sent through a VPN tunnel

https://support.checkpoint.com/results/sk/sk181491

SPARK Configuration

Below are the configuration details required on the Quantum Spark devices.

Three links.

MPLS 01

Connection monitoring was disabled, as it was causing automatic monitoring processes linked to ISP Redundancy.

ISP Redundancy was disabled, as it was creating automatic routes, which resulted in a higher priority ranking than the OSPF ranking we were using.

Configured Circuit ID and TAG, keeping the “Part of SD-WAN” option enabled.

MPLS 02

For MPLS 02, we applied the same configurations, changing only the defined Circuit ID.

LTE

For the LTE link, we left it as dynamic, and in the SD-WAN configuration we only changed the default Circuit 0 to Public.

VPNT1 DC HQ 1

VPNT  DC HQ 2

OSPF

Routing will be controlled using the dynamic routing protocol OSPF.

On the Quantum Spark side, OSPF configuration is quite simple:

Router ID is the unique identifier of the router within the AS. For clusters, a VIP IP address must be used. For standalone Security Gateways (without a cluster), it is considered a best practice to create a loopback interface in the 128.0.0.x/24 range to use as the Router ID, as described in the “CP_R81.20_Gaia_Advanced_Routing_AdminGuide,” page 228.

Interfaces are the ones that will participate in OSPF communication.

Add the VPNT interfaces and the transit interface

The operation mode was also changed to external point-to-point on the HQ 1 and HQ 2 external firewalls. On the Spark side, this was not necessary.

It was only required to adjust the ASE (Autonomous System External) rank so that routes learned via OSPF ASE in different areas would have better priority.

OSPF external rank adjustment on Quantum Spark:

set protocol-rank protocol ospfase rank 50

For information about the default ranks, you can refer to the Advanced Routing Guide..

Route Redistribution

Route Redistribution allows networks to be redistributed through OSPF communication.

It makes it possible to advertise directly connected networks, static routes, kernel routes, and others.

Routes

The 10.195.9.4/32 route pointing to the MPLS 01 gateway will be essential on all firewalls to maintain communication with the SMS through the underlay.

The DC HQ 1 and DC HQ 2 routes will be learned via OSPF.

Monitoring was kept enabled on only one of the routes via VPNT, as this would be the mechanism for the firewall to withdraw the default route if necessary.

In this case, it was necessary not to advertise the default route via OSPF, because it was causing issues.

Therefore, on the second default route, it was not necessary to configure monitoring.

[the_rock]

AMAZING bro, just amazing. I will make a logical prediction...another post soon enough from Val about new MVP member 😉

[israelfds95]

Hehe, I'm really excited about this project, and we'll be contributing together. But this project was very complex; I even tried to summarize it well, creating documentation totaling over 400 pages in various tests and configurations. 😂

[the_rock]

Man, not so sound cheesy now when I say this, but this is EXACTLY the proof I always keep talking about as to why we should strive to be better every day and help others.I been to literally 99% of this planet and if there is one thing I learnt, its this...no matter where you go and who you meet, what skin color and religion people are and who they pray for and what they believe in, if you are NICE to them, they will be NICE to you.

This community is total proof of that.

[israelfds95]

That’s absolutely true, and I believe in that as well. Let’s keep moving forward, progressing day by day together.

[WiliRGasparetto]

And I'll say more: Andy, our future diamond.

[the_rock]

I do my best!

[WiliRGasparetto]

Wow, simply incredible, it turned out great, Israel!

[israelfds95]

Thank you my friend, this was really nice. I learn a lot

[PhoneBoy]

One small issue with this write-up: the "Circuit ID" section appears to be in Portuguese.
Otherwise, this is fantastic!

[israelfds95]

I’ve just adjusted it on post and on PDF. Thank you for pointing that out. 
Best Regards