IP Masquerading bei Verbindung über VPN

Hallo Steffi,

wir haben ein ähnliches Szenario wie du es beschreibst. 

Hinter unserer UTM, an der sich die Kollegen per SSLVPN von extern verbinden, befinden sich diverse Subnetze, auf die teilweise zugegriffen werden muss.
Um den Zugriff darauf zu ermöglichen brauchst du aber kein NAT oder Masquerading, sondern lediglich die Subnetze in den erlaubten lokalen Netzwerken freischalten.

Das kannst du wie folgt:

Remote Access --> SSL --> SSLVPN Profil auswählen

Dort kannst du unter Local Networks die gewünschten Subnetze hinterlegen.

Bei der Anmeldung am SSLVPN bekommt dein Laptop das notwendige Routing übertragen und du kannst auf die PCs dahinter zugreifen.

Gruß

Matthias

Danke für Deine Antwort, Matthias.

Ich habe das so konfiguriert, wie Du gesagt hast.

Dass die Routen übertragen werden, kann ich sehen. Sie werden auch in der Routing Tabelle des Hosts, der die VPN-Verbindung aufmacht, angezeigt.
Pingen kann ich jedoch leider keinen Host hinter meinem lokalen 77er Netzwerk. Die Hosts dahinter sind nicht erreichbar.

LG
Steffi

Danke für Deine Antwort, Matthias.

Ich habe das so konfiguriert, wie Du gesagt hast.

Dass die Routen übertragen werden, kann ich sehen. Sie werden auch in der Routing Tabelle des Hosts, der die VPN-Verbindung aufmacht, angezeigt.
Pingen kann ich jedoch leider keinen Host hinter meinem lokalen 77er Netzwerk. Die Hosts dahinter sind nicht erreichbar.

LG
Steffi

Hast du den Haken "Automatic firewall rules" zu deiner Config im SSLVPN Profil mit aktiviert?
Ggf. fehlt dir nur noch das entsprechende Firewalling.

Gibt das Log nähere Informationen her?

Ich habe den Haken für "Automatic firewall rules" weg genommen und nochmals probiert, leider ohne Erfolg.

Die Logs der Firewall und SSL zeigen keine Einträge für die IP 192.168.7.1, die ich zu pingen versuchte...

OK, hast du die Firewall Rules mal geprüft?

Kannst du die relevanten IPs über die UTM pingen? (Support --> Tools --> Ping Check)?

Wenn du einen Trace Route auf dem über SSLVPN eingewählten PC machst - wie weit kommst du denn? Bis zur UTM solltest du kommen.

Viele Grüße

Matthias

Die 192.178.7.1 von der UTM aus zu pingen funktioniert einwandfrei mit einer round trip time von ca. 19 ms

Das Trace mit der IP 192.168.7.1 auf dem per OpenVPN verbundenen Laptop zeigt mir, dass ich bis zur IP 10.242.2.1 komme. Das wird sicherlich die IP der UTM auf der anderen Seite des Tunnels sein. Hier ist die round trip time ca. 26 ms.

OK, dann sollte das soweit alles passen.

Die Windows Firewall ist auf den betreffenden PCs deaktiviert bzw. entsprechend konfiguriert?

Prüfe mal bitte Folgendes:

- Pinge den betreffenden PC auf dem über SSL VPN angemeldeten PC
- öffne parallel das Firewall Log (Logging & Reporting --> View Logfiles --> Firewall --> Live Log)
- siehst du hier den Traffic ankommen?
- wird der Traffic geblocked (rot) oder geht das Firewalling soweit durch (grün)?

Viele Grüße

Matthias

Ich habe parallel die 192.168.7.1 gepingt und das Firewall Live Log angesehen.

In dem Firewall Log ist zu diesem Zeitpunkt kein einziger ICMP-Request aufgepoppt, weder accept noch deny.

OK, das würde aber bedeuten, dass dein SSLVPN Host die Route nicht findet und deshalb die ICMP Requests nicht an der Firewall ankommen.

Siehst du dein Netz aufgeführt, wenn du auf dem Host einen "route print" im cmd ausführst?

Ja, sehe ich:

192.168.7.0/24 via 10.242.2.1 dev tun0

Der Client, der derzeit verbunden ist, ist eine Linux-Box. Aber das ist ja egal.

Bist Du sicher, dass das bedeutet, dass der OpenVPN-Client die Route nicht findet? Es kommt eine Antwort von 10.242.2.1 auf das Ping zurück: Destination Host unreachable.

Wir hatten solche Themen in der Vergangenheit auch des Öfteren, dabei waren es meist die bereits angesprochenen Themen:

• Subnetz war im SSL VPN Profil nicht als erlaubte Netzwerke hinterlegt -> dadurch kein Routing auf den Hosts
• Firewalling auf der SG/XG war nicht gepflegt
• lokale Firewall (gibt es auch im Linux) war aktiv

Ehrlich gesagt wäre ich jetzt aus der Ferne am Ende mit meinem Latein.