ZScaler GRE to CP Cluster

[Nathan_Ressel]

See attachment for solution.

[Raj_Khatri]

Hi Nathan,

Thanks for providing the solution in the attached cluster guide.  I have a few questions - 

If a cluster is setup in an active/standby HA configuration, there is a single external VIP.  This is used to provision the Zscaler GRE tunnel.   Zscaler provides a /29 subnet to be used for the GRE tunnel configuration for 2 tunnels.  This does not provide a configuration for 4 tunnels.

As mentioned in the guide, it mentions 2 separate tunnel configurations.  Please advise if 2 public IPs were utilized on the firewall cluster.  This is not clearly noted.

Also, can you share a screenshot of the SmartConsole Network Management window showing the interface configuration?

If the same GRE configuration is mirrored onto both firewalls, what issues would that present as only a single firewall will be active at any given time.

Thanks

[Guerric_LM]

Hello Raj,

For one of my customer i configured GRE tunnels with 2 tunnels, even if in GRE tunnel configuration you specified local address of gateway, active member will replace it by cluster VIP in GRE tunnel establishment and to encapsulate traffic.

So you can use the same local address for differents tunnels, that's what i did and it works.

Also i disagree the configurations steps regarding network topology, here is what i configured :

As Zscaler do not provide enough IP address i used the IP provided for my node as cluster VIP in topology. As local address in tunnel i used another IP address.
I declared the VIP as scopelocal route as explained in Configuring Cluster Addresses on Different Subnets (checkpoint.com)

I attach GRE tunnel configuration, scopelocal routes and the topology configured

 

[MaheshCheck]

@Guerric_LM  could you please share the total configuration steps with screenshot

[Guerric_LM]

Hello,

i could not provide it, it's customer configuration.
But with the 1st post and mine you should be able to configure it.

[KamilZet]

Maybe this will help:

Check Point Cluster -- GRE with Zscaler:

During creation of tunnel in Zscaler you will get following info:

(just examples without real data)

Zscaler public pool: 1.1.1.1 and 2.2.2.2 ( t basing on location they recomend which dc should be used )

Zscaler Internal GRE pool: 172.25.0.0/29 ( you can choose from avaliable /29 pools)  = it means that you have x2 /30 = 172.25.0.0/30 & 172.25.0.4/30

Basing on above :

primary_fw-vip_internal_peer - 172.25.0.1 ( 1st usable host)

primary_zscaler_internal_peer- 172.25.0.2

secondary_fw-vip_internal_peer - 172.25.0.5 ( 1st usable host)

secondary_zscaler_internal_peer - 172.25.0.6

Our fw data:

e.g

Fw public pool: fw-01 - 100.100.100.2 , fw-02 -100.100.100.3 , fw-vip - 100.100.100.1

gre1_local_fw01_address & gre1_local_fw02_address   - different subnet than delivered by Zscaler, only local significance

e.g 192.168.0.1/30 & 192.168.0.2/30

gre2_local_fw01_address & gre2_local_fw02_address -  different subnet than delivered by Zscaler, only local significance

e.g 192.168.0.5/30 & 192.168.0.6/30

Fw-01

add gre id 1 local <pubic_fw-01_ip = 100.100.100.2 > remote <primary_public_zscaler = 1.1.1.1> ttl 255 ip <gre1_local_fw01_address = 192.168.0.1> mask 30 peer <primary_zscaler_internal_peer = 172.25.0.2 >

set interface gre1 comments "Primary GRE to Zscaler"

set interface gre1 state on

add gre id 2 local <pubic_fw-01_ip = 100.100.100.2> remote  <secondary_public_zscaler = 2.2.2.2 > ttl 255 ip <gre2_local_fw01_address = 192.168.0.5> mask 30 peer <secondary_zscaler_internal_peer = 172.25.0.6>

set interface gre2 comments "Secondary GRE to Zscaler"

set interface gre2 state on

Fw-02

add gre id 1 local <pubic_fw-02_ip = 100.100.100.3> remote <primary_public_zscaler = 1.1.1.1> ttl 255 ip <gre1_local_fw02_address = 192.168.0.2> mask 30 peer <primary_zscaler_internal_peer = 172.25.0.2>

set interface gre1 comments "Primary GRE to Zscaler"

set interface gre1 state on

add gre id 2 local <pubic_fw-02_ip = 100.100.100.3> remote  <secondary_public_zscaler = 2.2.2.2> ttl 255 ip <gre2_local_fw02_address = 192.168.0.6> mask 30 peer <secondary_zscaler_internal_peer = 172.25.0.6>

set interface gre2 comments "Secondary GRE to Zscaler"

set interface gre2 state on

set static-route <primary_zscaler_internal_peer_range/30 = 172.25.0.0/30> nexthop gateway logical gre1 on

set static-route <primary_zscaler_internal_peer_range/30= 172.25.0.0/30> scopelocal on

set static-route <secondary_zscaler_internal_peer_range/30 = 172.25.0.4/30> nexthop gateway logical gre2 on

set static-route <secondary_zscaler_internal_peer_range/30 = 172.25.0.4/30> scopelocal on  

Scope Local

Use this setting on a Cluster Member when the cluster virtual IPv4 address is in a different subnet than the IPv4 address of a physical interface. Now the Cluster Member can accept static routes on the subnet of the cluster virtual IPv4 address.

set ip-reachability-detection ping address <primary_public_zscaler = 1.1.1.1> enable-ping on

set ip-reachability-detection ping address <secondary_public_zscaler= 2.2.2.2> enable-ping on

set pbr table GRETable static-route default nexthop gateway address <primary_zscaler_internal_peer = 172.25.0.2> priority 1

set pbr table GRETable static-route default nexthop gateway address <primary_zscaler_internal_peer = 172.25.0.2> monitored-ip <primary_public_zscaler = 1.1.1.1> on

set pbr table GRETable static-route default nexthop gateway address <primary_zscaler_internal_peer = 172.25.0.2> monitored-ip-option fail-any

set pbr table GRETable static-route default nexthop gateway address <secondary_zscaler_internal_peer = 172.25.0.6> priority 2

set pbr table GRETable static-route default nexthop gateway address <secondary_zscaler_internal_peer = 172.25.0.6> monitored-ip <secondary_public_zscaler = 2.2.2.2> on

set pbr table GRETable static-route default nexthop gateway address <secondary_zscaler_internal_peer = 172.25.0.6> monitored-ip-option fail-any

Get topology:

Nat:

From fw-01_public = 100.100.100.2 and fw-02_public = 100.100.100.3 do a source nat 100.100.100.1 toward zscaler 1.1.1.1 & 2.2.2.2