Check Point R81 – GRE mit Zscaler

Ich habe dieses, für Check Point neue, Feature mit Zscaler in unserem Labor getestet. Es gibt für die Konfiguration ein paar Stolpersteine, welche ich im Folgenden erläutere:

Zscaler bietet für ihren GRE Tunnel für die internen Tunnel Adressen nur eine /30 Subnet Maske an. Daran «kann» Zscaler nichts ändern, wie eine Nachfrage beim Hersteller ergeben hat.

In einem /30 Netz können von den vier IPs nur zwei IPs für Hosts verwendet werden. Die erste und Letzte IP des Subnetzes werden für die Netz ID bzw. die Broadcast Adresse verwendet. In einem Check Point Cluster mit zwei Membern benötigt man normalerweise bereits drei IPs. Also was kann man tun? Es gibt die Möglichkeit die Member IPs in ein anderes Subnet, als die VIP zu konfigurieren. Man benötigt dazu auf jedem Cluster pro GRE Interface eine «scopelocal» Route. Das sieht dann bei zwei GRE Tunneln so aus:

set static-route 192.168.100.0/30 nexthop gateway logical gre1 on
set static-route 192.168.100.0/30 scopelocal on
set static-route 192.168.200.0/30 nexthop gateway logical gre2 on
set static-route 192.168.200.0/30 scopelocal on

Statische Routen, welche man bei Explicit Proxy eigentlich verwenden könnte, funktionieren leider nicht. Die Pakete werden zwar ins richtige Interface geroutet, aber der Tunnel wird damit nicht aufgebaut. Es ist also zwingend PBR nötig. Bei Transparent Proxy muss man sowieso auf diese zurückgreifen. Man hat dabei die Möglichkeit die «match» Kriterien aufgrund von folgenden Eigenschaften zu definieren: Interface, Source IP, Destination IP, Service Port, Protocol oder Firewall Rule.

Mit der Option ip-reachability-detection kann die interne Peer IP von Zscaler per ICMP überwacht werden. Sobald die interne Peer IP von Zscaler nicht mehr antwortet, wird damit automatisch ein Failover auf die Route mit der nächst höheren Priorität gewählt. PBR mit Tunnel Monitor sieht dann ohne Match Kriterien wie folgt aus:

set ip-reachability-detection ping address <peer ip gre ZH> enable-ping on
set ip-reachability-detection ping address <peer ip gre FRA> enable-ping on
set pbr table GREZurich static-route default nexthop gateway address <peer ip gre ZH> priority 1
set pbr table GREZurich static-route default nexthop gateway address <peer ip gre ZH> monitored-ip <peer ip gre ZH> on
set pbr table GREZurich static-route default nexthop gateway address <peer ip gre ZH> monitored-ip-option fail-any
set pbr table GREFrankfurt static-route default nexthop gateway address <peer ip gre FRA> priority 2
set pbr table GREFrankfurt static-route default nexthop gateway address <peer ip gre FRA> monitored-ip <peer ip gre FRA> on
set pbr table GREFrankfurt static-route default nexthop gateway address <peer ip gre FRA> monitored-ip-option fail-any

Wegen Tunnel Failover und Cluster Adressen in einem anderen Subnetz, kann Anti-Spoofing ein weiterer Stolperstein sein. Im Falle von Explicit Proxy sollte man das GRE Interface als Internal definieren und fürs Anti-Spoofing eine Gruppe mit folgenden vier Netzen eintragen:

1. 1. Internen GRE Tunnel Range (/30) in der sich die VIP befindet
   2. Member IP Range
   3. Zscaler ZEN Range 1 (zrh1-2.sme.zscaler.net)
   4. Zscaler ZEN Range 2 (fra4-2.sme.zscaler.net)

Das Interface, auf dem GRE terminiert, ist im Normalfall als External definiert. Die Primary und Secondary IPs befinden sich in den ZEN Ranges und dürften somit eigentlich aufgrund der Anti-Spoofing Konfiguration nicht auf diesem Interface aufschlagen. Es benötigt deshalb zwei Ausnahmen auf dem External Interface:

1. 1. Primary Destination: 225.94.12
   2. Secondary Destination: 225.26.12

Im Fall von Transparent Proxy fällt dieser Stolperstein weg, da das Interface auch als External konfiguriert wird. Damit werden auch die Ausnahmen auf dem Interface, auf welchem GRE terminiert, obsolet.