admeen
Goto Top

VPN mit Libreswan klappt, Routing funktioniert nicht ins Subnetz

Hallo,

ich habe folgenden Szenario mit einem Site to Site VPN:

Site A: ein IPSEC-VPN fähiger Router hinter ein VDSL-Modem
Site B: eine Debian-Maschine mit Libreswan hinter einem Telekom Router

Das Problem: Die Verbindung ist stabil und kann zwischen Site A und Debian Daten tauschen. Leider komme ich vom Site A nur bis zur Debian-Maschine durch.

Die Frage: Wie soll ich die Routing und Firewall im Debian einstellen, dass ich auf anderen Netzwerk-Komponenten in Site B von Site A aus und umgekehrt zugreifen kann?

Gruß

Content-ID: 465660

Url: https://administrator.de/forum/vpn-mit-libreswan-klappt-routing-funktioniert-nicht-ins-subnetz-465660.html

Ausgedruckt am: 28.12.2024 um 19:12 Uhr

the-buccaneer
the-buccaneer 25.06.2019 um 02:10:20 Uhr
Goto Top
Hi!

1.: wie definierst du "durchkommen"?
2.: Regel setzen, die auf dem IPSec-Interface Zugriff aufs Netzwerk erlaubt?

tracert machen und schauen, wo's hängt. Firewall-Logs betrachten. (Wird was geblockt?)

Mehr geht um die Zeit nicht mehr. face-wink
Bin froh, dass ich eben nen PfSense (StrongSwan) IP-Sec wieder mit nem IPSec-VPN-fähigen Router zum rennen gekriegt habe.

3.: Genauer beschreiben. face-wink

VG
Buc
aqui
Lösung aqui 25.06.2019 aktualisiert um 09:44:32 Uhr
Goto Top
Leider komme ich vom Site A nur bis zur Debian-Maschine durch.
Das hat 2 Mögliche Gründe:
1.)
Es fehlt das Aktivieren von IP Forwarding auf dem Debian VPN Server ! Der muss ja auch routen zwischen seinen internen VPN Interface und seinem LAN Interface ! Folglich muss hier also auf dem Debian Rechner IPv4 Forwarding aktiviert werden.
Das erreicht man mit dem Entkommentieren der Zeile #net.ipv4.ip_forward=1 in der Datei/etc/sysctl.conf und einem anschliessenden Reboot.
2.)
Der Telekom Router benötigt zwingend eine statische Route !
Ist ja auch logisch, denn andere Endgeräte in diesem LAN, wo auch der Debian VPN Server liegt, haben ganz sicher diesen Telekom Router als Default Gateway eingetragen.
Erhalten diese Endgeräte nun Pakete mit Absender IP Adressen aus dem remoten VPN Netz, senden sie die Antwort ja an dieses Default Gateway.
Fehlt dort die Route ins remote Netz via Debian Server (der ja Router ist) routet der Telekom Server die Antwort Pakete zu seinem Default Gateway, was der Internet Provider ist, und damit dann ins Nirwana statt zum Debian VPN und nix geht mehr !

Fazit:
Eins oder sehr wahrscheinlich beide Anfänger Fehler hast du begangen, so das du nur lokal auf den VPN Server kommst.
Zusätzlich kann man nur hoffen das dein Telekom Router KEINE gruselige Speedport Schrott Gurke ist, denn die hat ein stark kastriertes Featureset und supportet nicht einmal sowas Banales wie statische Routen.
Sollte das der Fall sein, musst du auf den via VPN zu erreichenden Geräten jeweils einzeln eine statische Route definieren ! (Optionale Client Route im u.a. Bild)
Noch besser ist es den Router dann auszutauschen gegen einen der das kann !

So sähe es aus wenn du routingtechnisch alles richtig gemacht hast:

debianvpn

Grundlagen dazu auch hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
admeen
admeen 25.06.2019 um 22:22:28 Uhr
Goto Top
Hallo,

danke für die Antwort und für die Skizze (diese ist genao so, wie es bei mir aussieht). Punkt 1 hat mir weitergeholfen. Punkt 2 braucht man nur, wenn die Kommunikation aus dem 10.2.2.0 Netz startet. Auf alle fälle habe eine ähnliche Situation mit einer Ubuntu-Maschine, worauf ein Openvpn als Server läuft. Wenn ein Client mit diesem Verbindet, kann er problemlos auf andere Komponenten im Netzwerk zugreifen, ohne dass man auf dem Router (außer einer Portweiterleitung) etwas einstellen muss. Ich hoffe, dass ich es richtig sehe.

Gruß
aqui
aqui 26.06.2019 um 09:54:50 Uhr
Goto Top
Du hast Recht. Hatte das im Eifer des Gefechts mit OpenVPN verwechselt. Punkt 2 bezog sich auf ein OpenVPN was ja noch ein internes separates internes IP Netz hat. Bei IPsec ist das natürlich nicht so, sorry.