Checkpoint NGAI und RemoteAccess - Ruleset wird ignoriert

#1 Hi !

Ich habe ein Problem das sich sicher logisch erklären lässt,
aber leider nicht von mir Bitte um Hilfe oder einfach nur Verbesserungsvorschläge:

Eine Regel im Ruleset wird richtiggehend "übersprungen" - erst die
nachstehende Regel (eine Fallback Rule mit gleichen Triggerwerten) greift.

Das Szenario sieht so aus:

Ich möchte mittels einer Safe@ Box von SofaWare (4.1er Checkp. Kernel)
eine VPN Verbindung zu einer Checkpoint NG AI R54 VPN-1 aufbauen.
Dies klappt eigentlich auch einwandfrei.

Die Topology des VPN definiere ich selbst, damit Packete an das Zielnetz 192.168.10.0 durch das VPN auf die VPN-1 geroutet wird.

Die VPN-1 hat ein bestehendes VPN zu einem unserer Kunden
(eben mit der Netzadresse 192.168.10.0).

Die Theorie besagt jetzt folgendes:

Client 192.168.0.100 verbindet sich mit 192.168.10.x
Die Safe-Box erkennt den Aufruf anhand seiner Topology als VPN-würdig,
und schickt die Pakete durch das Internet über den Tunnel an die VPN-1.
Dort angekommen werden die Pakete decrypted, Source ist selbstverständlich aufgrund des VPN immernoch die IP des Clients (192.168.0.100), und dann laut Ruleset durch das bestehende VPN zwischen der Checkpoint und des Kunden an den Zielhost 192.168.10.x geschickt.

Die Praxis sieht aber so aus:

Die Verbindung und das Routing durch das 1. VPN zwischen RAC User und der Checkpoint klappt bestens, im Ruleset tauchen die an 192.168.10.x versandten Pakete mit Source-IP 192.168.0.100 auf, alles läuft wie gewünscht.

Es gibt 2 Rules, eine für den Versand der gewünschten Pakete in das Zielnetz des Kunden, und eine als Fallback um unverschlüsselten Verkehr zu blockieren.

Hier ein Screenshot der betroffenen Rules:



Rule 11 wird einfach ignoriert - ohne jeglichen Kommentar im Tracker.
Rule 12 im Gegensatz dazu greift und blockt den Datentransfer - das beweist das Source und Target richtig definiert sind und auch erkannt werden (d.h. definitiv kein NAT Problem oder ähnl.).

Wenn ich in die Source-Spalte einen Testhost einfüge der nicht via Remote Access zur Checkpoint getunnelt wird, sondern der sich im selben Netz wie die Checkpoint befindet, funktioniert die Verschlüsselung und der Transport via VPN zum Kunden tadellos - mit den selben rules.

Und hier ist der Punkt - hier weiß ich nicht mehr weiter

lg.
Daniel[/b]

#2 Hi Daniel!

Mir ist nicht ganz klar welche Safe@ Appliance du verwendest, bzw. welche Version. Ich nehme jetzt einfach mal an, dass du die Safe@Office 105 verwendest und dezentral administrierst. (Die VPN-1 Edge kann auch vom SmartCenter administriert werden! evtl. mal eine Überlegung wert?

Das VPN mit der Safe@Office wird per RemoteAccess VPN betrieben (nicht Site-to-Site, Star/Mesch), soweit das aus dem Text hervorgeht.

Versuche mal folgendes:
1. Lösche in Rule 11 die VPN Community Kunde-xy_VPN.
2. Installiere die Policy
3. Öffne den SmartView Tracker und sieh nach ob die Regel immer noch nicht greift.

Wenn du weiterhin Probleme hast melde dich einfach noch mal!

Grüße,
Simon

#3 Es sind eigentlich 6 Safe@'s, aber die kleine Version - eine Safe@Office auf einer SBox-100.

Der SmartCenter Connector ist soweit ich mich erinnern kann relativ Kostenintensiv, .. oder wars der ServiceCenter Server? .. wie auch immer,

du gehst recht in der Annahme dass es sich um ein Star/Mesch handelt,
Site-to-Site ist in dem Fall nicht angebracht da keine Verbindung von den Kundennetzen zu den Netzwerken der Safe@ gewünscht ist.

Ich werds mal mit deinem Vorschlag versuchen,
nur rechne ich dann damit dass die Pakete unverschlüsselt ins Kundennetz weitertransportiert werden - die Checkpoint beim Kunden verwirft aber unverschlüsselte sofort - dadurch hätte ich wieder keine Chance,
aber vielleicht irre ich mich auch bezüglich der Reaktion UNSERER FW-1.

Danke für deine Hilfe auf jeden Fall, ich meld mich gern nochmal wenns geklappt hat, ... wenns nicht - sowieso

liebe Grüße,
Daniel

NACHTRAG

Morgen, Simon

so ich habs jetzt versucht - nur wurde die Verbindung im Tracker mit der
Begründung "Encryption Failure: cannot identify peer for encrypted connection (VPN Error Code 04)" abgeblockt.

Hab mich durch Google gearbeitet aber bin auf keine einleuchtende Erklärung
gestossen (Ausser ein Tip wegen NAT der nicht geklappt hat)...

auch der gute alte Phoneboy hat hier keinen Artikel auf Lager ..

bin ratlos derzeit..

#4 Hallo bei diesem Punkt bin ich nun auch angelangt.


"Encryption Failure: cannot identify peer for encrypted connection (VPN Error Code 03)"

Aber mit VPN Error Code 01

Auf http://www.boerderie.com/VPNdebugging.html hab ich das gefunden:

The times (once or twice) that we've seen this, it seems to mean "I have this peer defined with correct phase 1 parameters. Perhaps SOME subnets or hosts can be negotiated correctly with this peer, but THIS particular address is not in the Checkpoint's encryption domain."

Hat sich bei dir shcon eine Lösung ergeben?

na dann
pherison

#5 Eine Lösung .. naja im Prinzip schon -
ich hab gekündigt und bin mittlerweile nicht mehr für die Checkpoint verantwortlich.

Schade eigentlich .. einiges an Ausbildung die nun ungenutzt bleibt

Ich wünsch dir viel Glück!

#6 Naja aber danke!

schönen Tag noch
Gruß Pherison

#7 Hi,

wie sieht euere VPN Community und die jeweilige Topologie der beteiligten Gateways aus?

Hatte ebenfalls das gleiche Problem, das die Regel übersprungen wurde und im Log der Encryption Failure auftauchte.
Nachdem ich jedoch für die Checkpoint VPN-1 Edge die Topologie manuell bestimmt habe,
d.h. das entsprechende Netzwerk angelegt und der Encryption Domain zugewiesen habe, ging es.

Allerdings habe ich ein Site-to-Site VPN und kein RemoteAccess, aber vielleicht hilft es euch ja trotzdem.