Securepoint Support Forum

Heya liebes Securepoint-Team,

ich habe hier bei einem unserer Kunden ein Problem mit dem VPN Tunnel. Und zwar ist es so das ich den VPN Tunnel zwar aufgebaut bekomme, dieser allerdings eine Subnetzmaske erhält bei der ich nicht weiß woher er die nimmt. Eigentlich sollte er im Subnetz 255.255.255.0 ankommen, erhölt jedoch die 255.255.255.252. Weiterhin wird mir kein Standardgateway ausgegeben. Dies führt dazu das ich per RDP nicht ins Netz komme welches hinter der Dwarf ist.

Mittlerweile habe ich alle Einstellungen mehrmals überprüft und kann den Fehler nicht finden . Woran kann es denn noch liegen ?

LG
oLi

Bitte schicken Sie das komplette Client-Log einmal an support@securepoint.de (wenn Sie unseren Client verwenden: Doppelklick auf die mittlere Spalte der Verbindungsübersicht)

Log ist in diesem Augenblick zu euch unterwegs.

Vielen Dank schonmal

LG
oLi

Kann es sein, dass Sie im falschen Forum gepostet haben? Aus Ihrem Log ist ersichtlich, dass die "net30"-Topologie für das Tunnel-Netz (192.168.250.0/24) verwendet wird. Das ist eigentlich nur bei der UTMv10 der Fall und dort vollkommen in Ordnung.
Aus dem Log ist ebenfalls erkennbar, dass eine Route in ein /24er Netz gepusht und von Ihrem Client erfolgreich gesetzt wird.

Jetzt gibt es vier Möglichkeiten:

1. Ihr Client schickt die Pakete nicht in den Tunnel
Passiert manchmal, wenn AV-Software o.Ä. den Zugriff auf das TAP-Device unterbindet. Prüfen Sie zuerst die anderen Punkte.

2. Die Pakete können auf der UTM nicht entschlüsselt werden.
Stellen Sie sicher, dass die LZO-Compression sowohl auf der UTM als auch in Ihrem Client nicht aktiv ist. Im Log steht beim Verbindungsaufbau dann sowas wie "comp-lzo is present in remote config but missing locally" (oder eben umgekehrt)

3. Das Regelwerk auf der UTM ist nicht korrekt.
Öffnen Sie das Livelog und schauen Sie dort nach "DROP"s, die zum Tunnel-Interface hereinkommen ("IN=tun0"). Die sehen Sie natürlich nur, wenn Sie parallel mal einen Host hinter dem Tunnel pingen. Sind DROPs sichtbar, prüfen Sie ob die angelegten Netzwerkobjekte in der korrekten Zone sind, die Zone auf dem korrekten Interface (tun0) ist und ob die Firewall-Regeln korrekt angelegt worden sind.

4. Die (Windows-)Firewall bzw Netzwerk-Konfiguration auf dem Ziel-Host verhindert die Kommunikation.
Aktivieren Sie auf der UTM für die Firewall-Regel, die den Zugriff vom Tunnel-Netz auf ihr internes Netz erlaubt das Logging und drücken Sie dann auf "Regelupdate". Wenn Sie jetzt durch den Tunnel pingen und grüne "ACCEPT"-Pakete im Log sehen, müssen Sie auf dem Zielserver nach der Ursache schauen. Sehen Sie nichts grünes, machen Sie mit (1) weiter.

Und weil die Konsole sehr mächtig ist:
Das alles lässt sich auch schneller über eine root-Shell und tcpdump debuggen.

A)
B)
C)
"eth0" ist dabei das Interface, welches die Internetverbindung herstellt, "1194" der Port, über den die SSLVPN Verbindung aufgebaut wird und "eth1" das interne Interface.

Ist bei (A) kein 101 oder 125 Byte großes Paket sichtbar, wenn manin den Tunnel pingt, ist die Ursache vmtl (1)
Sieht man bei (A) entweder 101 oder 125 Byte große Pakete, aber bei (B) nichts, ist die Ursache vmtl (2)
Sieht man bei (B) den Ping, bei (C) aber nicht, ist die Ursache vmtl (3)
Sieht man den Ping bei (B) und bei (C), kommt nur Punkt (4) in Frage.

Hallo Erik....ich muss gestehen das ich noch gar nicht bemerkt habe das es unterschieldiche Foren für die V11 und V10 gibt....und ja du hast recht bei mir handelt es sich aufgrund von KV-Safenet um eine V10. Ich werde testen und berichten....vielen Dank schonmal.

So, nachdem ich der Tun0 Schnittstelle die OpenVPN-Zone zugewiesen habe funzt es nun auch. Vielen Dank für die Denkanstöße :-)