Mit R81 ist GRE nun endlich unterstützt auf GAIA. Das hat gedauert. Den Standard gibt es nun doch auch schon seit 25 Jahren. Dass sich Check Point so lange Zeit mit der Unterstützung gelassen hat, wird vermutlich auch damit zu tun haben, dass Check Point GRE nicht als sicher ansieht und deshalb in jedem Fall IPsec über GRE als Tunnel empfiehlt.

There are some security implications when selecting GRE. Consequently, Check Point always recommends selecting the IPSec option.


IPsec vs GRE

Natürlich ist es richtig, dass IPsec das sicherere Protokoll ist. Im Gegensatz zu GRE bietet es Verschlüsselung und Validierung von Source und Destination. Da man bei Zscaler IPsec Verschlüsselung nur gegen Aufpreis haben kann, fällt dieser Vorteil in den meisten Fällen sowieso weg. Web-Seiten mit HTTPS sind zudem sowieso bereits verschlüsselt und die Destination validiert.  Zudem steht im Anwendungsfall mit Zscaler die Enkapsulierung und nicht die Verschlüsselung im Vordergrund.

Es gibt von Seiten Zscaler ausserdem die Einschränkung, dass man pro IPsec Tunnel nur 250Mbit/s erreichen kann. Allerdings muss man einräumen, dass GRE auf Check Point nicht CoreXL fähig ist und damit nur eine Firewall Instanz den Traffic pro Tunnel verarbeiten kann. Die Praxis wird zeigen, was das in Mbit/s bedeutet. Falls nötig, könnte man wie mit IPsec dann mehrere Tunnel zu Zscaler aufbauen.


Vorteil GRE

In Verbindung mit Zscaler und Check Point liegen die Vorteile von GRE auf der Hand. Schliesslich bietet GRE im Gegensatz zu IPsec eine einfache Möglichkeit ohne viel Overhead einen Tunnel aufzubauen, diesen vor allem out-of-the-box zu überwachen und im Fehlerfall automatisch zu „failovern“.

Zscalers Vorbehalte gegenüber Check Point sind nun mit R81 passé:

Zscaler currently doesn’t recommend forwarding traffic from Check Point (GAIA version 77.20 or later) because Check Point doesn’t support:

    • tunnel monitoring on third-party vendors
    • automatic tunnel Failover, so customers must perform this manually
    • sending all ports and protocols down the tunnel without complex configuration

Stolpersteine

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:

Check Point Cluster

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


Policy Based Routing

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.


Tunnel Monitor mit automatischem Failover

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


Anti-Spoofing

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. 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. 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.



El Fulano

El Fulano

El Fulano ist Senior Security Engineer bei AVANTEC und Spezialist für Informationssicherheit. Ihn interessieren neben Technik auch Management und Recht. Er mag Science Fiction und Sport. Am liebsten beschäftigt er sich mit Firewalls und Advanced Threat Prevention.

Privacy Preference Center