SSL-VPN Ping& Zugriff auf Roadwarrior Client

[c.kehr]

Hallo liebe Firewaller & Netzwerker :-)

Ich möchte gerne von einem Terminalserver im internen Firmennetzwerk auf einem freigegebenen Drucker eines per SSL-VPN eingewählten Clients im Home Office drucken. Der Drucker ist an diesem Client per USB angeschlossen und freigegeben. Über die IP des SSL-VPN Clients 192.168.XX.5 wollte ich den Drucker auf dem Terminalserver verbinden.

Nun ist es mir aber nicht möglich aus unserem LAN die IP des SSL-VPN Clients zu erreichen z.B. per Ping. Es scheint mir so, dass die UTM die Pakete zum Client hin nicht weiter routet. Lediglich das Interface SSL-VPN Roadwarrior 192.168.xx.1 in der UTM bekomme ich noch erreicht mit einem erfolgreichen Ping. Ich sehe auch im Log der UTM keinerlei Meldungen, dass in die Richtung etwas blockiert wird, geschweige denn überhaupt eine Anfrage meines LAN Clients in die Richtung geht. Ich weiß nur, dass in der Vergangenheit (damals ein Linux Server mit openVPN installiert) genau für solche Anforderungen in der Client-Config am Server eine "iroute" hinterlegt war, wodurch der SSL-Client dann auch erreichbar wurde/war.

Grundsätzlich funktioniert das Arbeiten aus dem Home Office wunderbar und die Terminalserver sind erreichbar. Dadurch das unsere UTM noch nicht das Std. Gateway im Netzwerk ist, habe ich auf unserem noch aktuellen Std. Gateway entsprechend die Route eingetragen, die auch wunderbar funktioniert. Nur mit dem direkten Zugriff aus dem LAN zum SSl-VPN Client hin klappt es nicht so wie ich mir das dachte und es noch aus der Vergangenheit kannte.

Also kurz um:
SSL-VPN Client -> Anfrage -> LAN Client -> Rückantwort -> SSL-VPN Client = OK
LAN Client -> Anfrage -> SSL-VPN Client -> Rückantwort -> LAN Client = NICHT OK

Bei Fragen einfach melden.

Ich hoffe ihr könnt mir weiter helfen. Vielen Dank vorab.

Gruß, Christian

[Mario]

Hier koennte die Firewall des Client selbst das Problem sein.

Auch braucht es eine passende Portfilterregel (Server > SSL-VPN-IP)

Der Server kommt aus einem Netz, welches die Firewall des Clients nicht kennt. Das koennte das Problem sein. Mit der Firewall koennen Sie mit dem Interface des Tunnels pingen und bekommen auch eine Antwort, weil der VPN-Client sich im Tunnelnetz befindet.

[c.kehr]

Hallo Mario,

vielen Dank für die Antworten/Hinweise. Die lokale Firewall des SSL-VPN Clients (Windows 10) kann ich ausschließen. Mit entsprechender Regel am SSl-VPN Client oder gar komplett deaktivierter Client Firewall kann ich mittels des Netzwerktools Ping von der UTM aus, bei ausgewähltem TUN-Interface als Quelle für dieses Subnetz, die IP des SSL-VPN Clients erreichen und bekomme auch eine Antwort zurück.

Ich habe mir dann einmal den TAP-Adapter am SSL-VPN Client angeschaut. Dieser bekommst standardmäig eine IP von der UTM vergeben (also DHCP), allerdings ohne Gateway. Ich habe daraufhin einmal die Adressen manuell im TAP-Adapter eingetragen inkl. des Gateway, aber leider ohne Änderung/Erfolg.

Die erwähnte Portfilterregel von Dir habe ich auch explizit nochmal gesetzt, aber ebenfalls ohne Wirkung. Ich kann maximal von beiden Seiten aus das TUN-Interface der UTM per Ping/Tracert erreichen. Also Ping aus dem Firmen LAN zum TUN-Interface = ok und Ping aus dem SSL-VPN Client Netz zum TUN-Interface auch = ok (mit entsprechnder Portfilterregel). Über das Interface geht aber nichts (Ping/Traceroute) drüber hinweg UND ich sehe auch im Log der UTM keinerlei Pakte (Accept/Drop) zu meinen Anfragen.

Kann es eventuell doch eine Routing Thematik der UTM selber sein? Ich tippe zumindest darauf, wüsste aber nicht wo ich dazu Einstellungen finden könnte.

Viele Grüße, Christian

[Mario]

Noch einmal: Das Sie den Client vom Tunnelinterface der UTM aus anpingen koennen, ist mit Sicherheit normal. Aber wenn ein anderes Netz den Client anpingt, ist die Lokale Firewall des Clients dann -bei Standardeinstellungen- nicht mehr so gnaedig.

Eine Route muessen Sie nicht setzen, dies passiert automatisch bei Verbinden. Die Netze, die sie Tunnelserverseitig freigeben, sind ueber das Gateway des Tunnelserver fuer den Client erreichbar. (Auf einen Ping kann der Client also technisch gesehen antworten, solange der Echo Request aus einem der freigegebenen Netze im Tunnel kommt) Ein Gateway sollten Sie nicht angeben, da Sie sich dann, je nach Metrik, keinen Internetzugang mehr haben/ der Tunnel zusammen bricht. Denn in den Netzwerkeinstellungen handelt es sich dann um ein Standardgateway, also die Default-Route

[c.kehr]

Ok, die Firewall des SSL-VPN Clients ... werde ich mir einmal genauer anschauen.
Aber dann stellt sich mir die Frage. Warum klappt es dann nicht bei komplett deaktivierter Firewall?

Viele Grüße, Christian

[Mario]

Dann koennte es noch einen anderen Grund geben.

Schon mal in das Log der Firewall geschaut? (Paketfilter)

Eine Routen-Problematik sollte theoretisch nicht vorliegen. Sonst wuerde ich empfehlen, ein Ticket bei uns aufzumachen, damit man sich das einmal anschauen kann.

[c.kehr]

Ja, in das Paketfilter Log der Firewall hatte ich geschaut, wie bereits erwähnt. Doch vom Firmen LAN aus, erreiche ich nur das TUN-Interface der UTM und nichts dahinter in Richtung der SSL-VPN Clients. Vom SSL-VPN-Client ins Firmen LAN hingegen ist alles in Ordnung. Die Richtung macht keine Probleme. Nur der umgekehrte Weg zum Roadwarrior Client hin wenn die Verbindung aus dem Firmen LAN heraus initiiert wird "funktioniert" nicht.

Aber mal ganz allgemein gefragt, diese umgekehrte Richtung sollte ja normalweise grundsätzlich auch möglich sein oder?

Viele Grüße, Christian

[Mario]

Wenn eine Regel existiert, die dem z.B. Internen Netz Zugriff auf das Roadwarrior-Tunnelnetz gibt, dann klappt das auch, wenn das interne Netz im Tunnel als Servernetz angegeben ist.


Sonst bitte Ticket im Support erstellen. Dann stimmt etwas mit Ihrer Portfilterkonfiguration nicht.

[c.kehr]

Dann erstmal vielen Dank an der Stelle für die Untetrstützung :-)
Ich werde die Tage mal auf den Support zugehen.

Gruß, Christian