VPN Site 2 Site - Keine Kommunikation aber Verbindung OK?

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
Snoopy77
Beiträge: 42
Registriert: Mo 17.02.2014, 19:57

VPN Site 2 Site - Keine Kommunikation aber Verbindung OK?

Beitrag von Snoopy77 »

Hallo,

ich habe zwei UTM11 Dwarf und Wifi Dwarf beim Kunden am Laufen. Diese sollen über Site2Site VPN vernetzt werden.
Die Verbindung steht. Ich habe es über openvpn ssl gemacht.
Gemäß Anleitung und Hilfe von hier: http://support.securepoint.de/viewtopic.php?f=30&t=5667

Soweit so gut. Leider finden die Clients auf der Filiale die Server nicht. Es scheint so, als wenn die Pakete nicht übertragen werden.
Die Hauptniederlassung hat eine Glasfaserverbindung von einem lokalen Anbieter mit fester IP. Die Niederlassung hat einen Standard DSL von der Telekom. Ohne feste IP.

Ich habe schon die Regeln auf LOG gesetzt. Die Pakete werden auch akzeptiert, es gibt kein DROP.
Wenn ich z.B. den Client neu starte, habe ich keinen Zugriff auf den Windows-Server, ich kann keine IP oder Hostnamen in der Hauptniederlassung anpingen.
Nach ca. 10 Minuten, kann ich diese anpingen und auch browsen, aber ein Netzwerkweiter Browse funktioniert nicht.

Hat jemand ein Idee, welche Einstellung hier fehlt. Ich habe schon unter SSL-VPN die Subnetze und die Search Domain eingestellt. Auch beim Remote-Client-Profil.
Es geht ja wie gesagt, aber nicht beim Neustart der Rechner in der Niederlassung.

Ich stehe hier erstmal im Wald und weiss nicht weiter.

Tunnel wird auf beiden UTMs als aktiv angezeigt. Auch schon, bevor ich einen Ping durch den Tunnel vom Windows-Rechner bekomme.

Gruß

Snoopy77
Beiträge: 42
Registriert: Mo 17.02.2014, 19:57

Beitrag von Snoopy77 »

Ach ja, bei weiterer Kontrolle der Einstellungen ist mir aufgefallen, dass ich das Transfernetz nicht erwähnt hatte.
Wegen eines IP-Anschlusses brauche ich die Einwahl des Speedports. Ich habe den Firewall auf dem 723V ausgeschaltet und die Ports 1194-1195 an die UTM weitergeleitet.

Bei dem SSL-VPN Server habe ich den Port auch umgestellt. Es läuft nicht ein zweiter auf 1194 für die Roadwarrier.

Bjoern
Securepoint
Beiträge: 685
Registriert: Mi 03.07.2013, 10:06

Beitrag von Bjoern »

Hallo,

schauen Sie per Konsole einmal nach ob die Pakete in den Tunnel gehen und ggf. auch beantwortet werden. Hierzu legen Sie auf beiden Seiten den Benutzer root an und geben diesem Amdinistrator Rechte. Nun melden Sie sich per ssh (zum Beispiel mit putty) auf der Firewall an.

Niederlassung:
tcpdump -i eth1 proto 1 -nnp (Zeigt an ob dern Ping auf eth1 ankommt/rausgeht)
tcpdump -i tun0 proto 1 -nnp (Zeigt an ob Pakete im Tunnel ankommen/rausgehen)

Hauptniederlassung:
tcpdump -i tun0 proto 1 -nnp (Zeigt an ob Pakete im Tunnel ankommen/rausgehen)
tcpdump -i eth1 proto 1 -nnp (Zeigt an ob dern Ping auf eth1 ankommt/rausgeht)

Nun schicken Sie von der Niederlassung ein Ping auf einen Server in der Hauptniederlassung.
Im besten Falle sehen Sie jeweils ein ICMP echo request und ein ICMP echo reply.

Sollten schon in der Niederlassung auf eth1 keine pakete ankommen müssen Sie intern schauen. Wer vergibt DHCP? Wie sieht die Standardroute aus? Switch schon einmal getauscht?

Gruß Bjoern

Snoopy77
Beiträge: 42
Registriert: Mo 17.02.2014, 19:57

Beitrag von Snoopy77 »

Hallo,

danke für die Hilfe.
Noch ein paar Angaben zu dem Setup.
Niederlassung Speedport 723v, Firewall aus, macht die Einwahl per DSL, IP-Adresse 192.168.2.1 (Transfernetz), Freigabe Ports 1194-1195 und 443 und 11115 auf UTM
UTM IP-Adresse 192.168.2.2
Internes Netz Eth1 192.168.40.1,

DHCP über UTM für Pool 192.168.40.x
hier aber eine Fehlermeldung im Log:
DHCPINFORM from 192.168.40.54 via eth1: not authoritative for subnet 192.168.40.0
54 ist ein Client in der Niederlassung, der eine IP-Adresse anfordert.

SSL-VPN Site2Site Netzwerk 192.168.5.x
Frage für mein Verständnis:
Ich habe eine Regel von dem SSL-VPN Netzwerkobjekt ins internal networks und all eingerichtet und umgekehrt,
muss dann nicht schon sämtlicher Verkehr zugelassen werden?
Oder muss ich noch eine Regel für das SSL-VPN Netzwerk in das internet Netzwerk anlegen, also ein eigenes Netzwerkobjekt für das interne 40er Netz?

Ausgabe des TCPDumps Eth0 Niederlassung:
18:23:20.170590 IP 192.168.40.50 > 192.168.1.10: ICMP echo request, id 1, seq 723, length 40
18:23:24.860491 IP 192.168.40.50 > 192.168.1.10: ICMP echo request, id 1, seq 724, length 40
18:23:29.860889 IP 192.168.40.50 > 192.168.1.10: ICMP echo request, id 1, seq 725, length 40
18:23:34.861229 IP 192.168.40.50 > 192.168.1.10: ICMP echo request, id 1, seq 726, length 40

Ausgabe TCPDump Tun0 Niederlassung
18:30:38.988302 IP 192.168.40.50 > 192.168.1.10: ICMP echo request, id 1, seq 731, length 40
18:30:43.803193 IP 192.168.40.50 > 192.168.1.10: ICMP echo request, id 1, seq 732, length 40

Sieht also meiner Ansicht nach gut aus.
192.168.1.10 ist der Server in der Hauptniederlassung, den ich brauche.

Die Hautniederlassung mache ich dann gleich.

Snoopy77
Beiträge: 42
Registriert: Mo 17.02.2014, 19:57

Beitrag von Snoopy77 »

In der Hauptniederlassung bekomme ich keinerlei Antwort aus dem Dump.
Also weder auf Eth1, noch auf Tun1. Dort ist bereits ein VPN Server aktiv, daher der Port 1195.

Hier scheint also etwas mit dem Routing im Argen zu sein.
Ich habe Routen für das SSL-VPN Netz über den Tunnel und für das jeweils interne Netz über den Tunnel angelegt.
Bei beiden UTMs gibt es nur einen Weg ins Internet.

Der Tunnel ist laut dem Server unter Anmeldungen aktiv. Ein Ping bekomme ich aber nicht rüber. :-(

Irgendeine Idee?

Snoopy77
Beiträge: 42
Registriert: Mo 17.02.2014, 19:57

Beitrag von Snoopy77 »

Noch eine Ergänzung, wenn ich von der Hauptniederlassung in die Zweigstelle pinge, bekomme ich auf Eth1 ein Echo, auf dem Tun1 jedoch keine Reaktion.
Hier liegt wohl das Kommunikationsproblem. Die Paket finden den Weg nicht zurück?

Snoopy77
Beiträge: 42
Registriert: Mo 17.02.2014, 19:57

Beitrag von Snoopy77 »

Beim Auslesen der Logs auf den UTMs habe ich auf der Niederlassung diverse Einträge wegen eines falschen Kennwortes für root:

26.08.2014 19:31:20 spauthd root: local authentication failed
26.08.2014 19:31:24 spauthd root: local authentication failed
26.08.2014 19:31:24 spauthd root: local authentication failed
26.08.2014 19:31:26 spauthd root: local authentication failed
26.08.2014 19:31:29 spauthd root: local authentication failed
26.08.2014 19:31:29 spauthd root: local authentication failed
26.08.2014 19:31:30 spauthd root: local authentication failed
26.08.2014 19:31:30 spauthd root: local authentication failed
26.08.2014 19:31:30 spauthd root: local authentication failed
26.08.2014 19:31:31 spauthd root: local authentication failed
26.08.2014 19:31:33 spauthd root: local authentication failed
26.08.2014 19:31:34 spauthd root: local authentication failed

Läßt sich hier die Quelle feststellen.
Die Administration über das Internet ist frei. Das Kennwort ist recht lang und sicher.
Eine interne Anmeldung gibt es von mir oder jemanden anderen meiner Ansicht nach nicht.
Hängt dies mit dem Site2Site zusammen oder ist die ein Angreifer auf den UTM?

Snoopy77
Beiträge: 42
Registriert: Mo 17.02.2014, 19:57

Beitrag von Snoopy77 »

OK, und noch eine Info:
Es scheint so, als wenn die Verbindung nach einer Weile einfach aufgelöst wird. Eine Ursache ist nicht erkennbar. Timeout? Im Log steht etwas davon. Dann wird die Verbindung wieder aufgebaut und es steht alles wieder.
Das Rekeying seht auf 8h.
Die Verbindung soll dauerhaft 24/7 laufen. Gibt es eine Möglichkeit, die irgendwo einzustellen?

Wenn ich einfach ca. 15 Minuten warte, geht die Verbindung wieder.

Snoopy77
Beiträge: 42
Registriert: Mo 17.02.2014, 19:57

Beitrag von Snoopy77 »

Ich glaube inzwischen, dass es am MTU Fenster liegt.
Hier sind ja 1500 voreingestellt.
Gibt es einen empfohlenen Wert für OpenVPN über Telekom DSL und Glasfaser von Wilhelm Tel?
1200 funktioniert besser, als 1400 und 1500. Die Verbindung bricht aber leider immernoch manchmal ab bzw. es dauert sehr lange, bis sie wieder steht.

Durch das Transfernetz möchte ich die Verbindung gerne per OpenVPN machen, aber es muss natürlich sicher laufen.

Gibt es noch etwas, was ich ändern kann?

Bjoern
Securepoint
Beiträge: 685
Registriert: Mi 03.07.2013, 10:06

Beitrag von Bjoern »

Hallo,
DHCPINFORM from 192.168.40.54 via eth1: not authoritative for subnet 192.168.40.0
Die Ursache wird sein, dass es in dem Netz noch weitere DHCP Server gibt. Der Client hat ja schon eine IP bekommen und zwar die 192.168.40.54

Ich habe eine Regel von dem SSL-VPN Netzwerkobjekt ins internal networks und all eingerichtet und umgekehrt,
muss dann nicht schon sämtlicher Verkehr zugelassen werden?
Oder muss ich noch eine Regel für das SSL-VPN Netzwerk in das internet Netzwerk anlegen, also ein eigenes Netzwerkobjekt für das interne 40er Netz?
Sie müssen bei den Regeln für eine S2S Verbindung immer das "echte" Netzwerk angeben und nicht das geroutete Netzwerk, also das 40.x Netzwerk und umgedreht.

Ist in der Niederlassung beim SSL-VPN auch der Port 1195 bei der IP hinterlegt? Ersichtlich unter VPN => SSL-VPN => REMOTE-SERVER-PROFILE
Wenn nicht bitte bearbeiten IP:1195

Noch eine Ergänzung, wenn ich von der Hauptniederlassung in die Zweigstelle pinge, bekomme ich auf Eth1 ein Echo, auf dem Tun1 jedoch keine Reaktion.
Hier liegt wohl das Kommunikationsproblem. Die Paket finden den Weg nicht zurück?
Das hört sich so an als würde die Route unter Netzwerk => Netzwerkkonfiguration => Routing fehlen oder falsch sein. Da der S2S Server hier auf tun1 läuft muss der Routingeintrag so lauten
Gateway: tun1 Ziel: 192.168.40.0/24

Beim Auslesen der Logs auf den UTMs habe ich auf der Niederlassung diverse Einträge wegen eines falschen Kennwortes für root:

26.08.2014 19:31:20 spauthd root: local authentication failed
26.08.2014 19:31:24 spauthd root: local authentication failed
26.08.2014 19:31:24 spauthd root: local authentication failed
Hier versucht sich einer mit dem Benutzer root anzumelden. Warum ist denn die Administration über das Internet freigegeben? Hierfür gibt es die bessere Lösungen zum Beispiel die direkte Freigabe für einzelne IPs/Netzwerke unter Netzwerk => Servereinstellungen => Administration

Sie können hier per Dump nachschauen von welcher IP er kommt.

tcpdump -i eth0 port 22 or port 11115 -nnp

Es scheint so, als wenn die Verbindung nach einer Weile einfach aufgelöst wird. Eine Ursache ist nicht erkennbar. Timeout? Im Log steht etwas davon. Dann wird die Verbindung wieder aufgebaut und es steht alles wieder.
Das Rekeying seht auf 8h.
Die Verbindung soll dauerhaft 24/7 laufen. Gibt es eine Möglichkeit, die irgendwo einzustellen?
Das wäre im SSL-VPN bei Renegoation auf nie setzten.

Antworten