14.05.2023, aktualisiert um 18:51:43 Uhr

2219

Problem mit Routing über VPN

Moin,

folgendes Szenario:

Standort A ist über IPSec mit Standort B verbunden. Am Standort B ist ein Konnektor installiert, welche u.a. den Zugriff auf das KV Safenet ermöglicht.
In der Firewall am Standort B ist eine statische Route mit Verweis auf den Konnektor gesetzt. Der Aufruf des KV Safenet von Standort B ist soweit problemlos möglich.

Nun habe ich an Standort A ebenfalls eine Route gesetzt, welche den Datenverkehr für das entsprechende Subnet über den VPN Kanal schickt.
An Standort B ist eine Firewallregel gesetzt, welche Benutzern von Standort A den Zugriff auf das KV Safenet erlaubt.

Sobald ich nun von Standort A einen Zugriff auf das KV Safenet starte, protokolliert die Firewall Standort B den Zugriff, erlaubt es und leitet die Anfrage (mit korrekter Ziel IP) an den Konnektor weiter. Der Zugriff auf das Safenet ist jedoch nicht möglich.
Tracert von Standort A zeigt das Hopping auf den Konnektor an, danach verläuft es im Nichts.
Am Konnektor am Standort B ist eine statische Route mit dem Subnet am Standort A gesetzt, ein Ping Versuch von beiden Seiten ist problemlos möglich.

Übersehe ich irgendwas offensichtliches?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 7152037136

Url: https://administrator.de/forum/problem-mit-routing-ueber-vpn-7152037136.html

Ausgedruckt am: 22.12.2024 um 06:12 Uhr

17 Kommentare

Neuester Kommentar

Übersehe ich irgendwas offensichtliches?

Ja vermutlich, denn du hast sehr wahrscheinlich deine Phase 2 SAs nicht berücksichtigt bei IPsec. Routing ist nicht alles bzw. ist bei native IPsec überhaupt gar nicht erforderlich, denn du definierst mit den Phase 2 SAs bei IPsec welche IP Netze in den Tunnel geroutet werden und welche nicht. Statische Routen sind bei IPsec deshalb nicht erforderlich bzw. wirkungslos.
Vermutlich hast du vergessen hier die Safenet Zielnetze oder eine Summary Maske für diese IP Netze in einer zusätzlichen P2 zu definieren so das diese dann nicht in den VPN Tunnel geroutet werden.

Leider machst du keinerlei hilfreiche Angaben zu deiner IP Adressierung bzw. speziell der IPsec Konfig so das eine zielführende Hilfe ohne die Kristallkugel zu bemühen nur schwer bis gar nicht möglich ist.

Das KV Safenet ist nicht Teil meiner in Phase 2 definierten Netze... muss das unbedingt sein? Ich hatte gehofft mit Routing alleine eine Verbindung aufbauen zu können.
Das Zielnetz 188.144.0.0/15 für das KV Safenet verweist mittels Policy Routing am Standort A auf den VPN Tunnel.

Das KV Safenet ist nicht Teil meiner in Phase 2 definierten Netze...

Das ist der Fehler!

muss das unbedingt sein?

Bei IPsec VPNs schon. Diese Frage ist eigentlich keine, denn bei jedem VPN Protokoll musst du das bekanntlich auf irgendeine Art und Weise definieren...

verweist mittels Policy Routing am Standort A auf den VPN Tunnel.

Ist, wie oben schon gesagt irrelevant wenn es in einer P2 Definition fehlt, denn dann gelangen Pakete mit dieser Ziel IP nicht in den VPN Tunnel egal ob du routest oder nicht.
Trage schlicht und einfach zur bestehenden Phase1 für den Tunnel noch eine 2te Phase 2 ein mit: Local: 10.5.1.0/24, Remote: 188.144.0.0/15 und am anderen Ende vice versa dann klappt das auch sofort im Handumdrehen.

Mit dem Phase 2 Eintrag für 188.144.0.0/15 klappt es.

Jetzt habe ich aber noch ein weiteres Problem:
wenn ich mit meinem Iphone auf das KV Safenet zugreifen will, klappt der Verbindungsaufbau idR nicht. Wenn ich
das Iphone Private Relay deaktiviere, funktioniert es wie gewünscht (nach DNS Anfrage wird anscheined nicht mehr über den VPN geroutet, zumindest in 99% der Fälle nicht).
Wenn ich eine Seite aus dem 188.144.0.0/15 Netz direkt ansteuere, erfolgt der Verbindungsaufbau, ich werde jedoch auf eine ungültige Seite geleitet.

Kann ich irgendwie sicherstellen, dass beim Aufruf der IP Adresse eine Weiterleitung auf die korrekte Domain erfolgt?

Das ist bekannt und iPhone spezifisch:
https://www.heise.de/news/Apple-raeumt-ein-iOS-Dienste-koennen-VPN-Tunne ...

Mit dem iCloud Privat-Relay betreibt Apple einen eigenen Dienst, der die IP-Adresse des Nutzers vor Webseiten und Netzwerkbetreibern verbergen soll. Dieser Schutz greife nicht mehr, wenn eine VPN-Verbindung aufgebaut wird, so Apple.

Ich wünschte das wäre der Fall, Privat-Relay scheint bei aktivierter VPN Verbindung weiterhin aktiv zu sein und die Möglichkeit, eine Ausnahme hinzuzufügen, scheint ebenfalls nicht vorhanden zu sein.

Ich wundere mich aber dass es zwischenzeitlich doch funktioniert, immer nur für ein paar Sekunden.

Ich bin jetzt noch auf ein zusätzliches Problem gestoßen: über den VPN Tunnel kann ich den pfSense DNS Resolver nicht verwenden.
Zwar sehe ich in der Firewall-Regel, dass von meinen IPSec Clients eine Verbindungen versucht wird aufzubauen (mehrere States aktiv), der DNS Resolver antwortet aber nicht. Im lokalen Netz wer pfSense dagegen funktioniert der DNS Resolver.

DNS Resolver ist so eingestellt, dass er auf allen Interfaces lauschen soll. ACL für IPSec Phase 2 Subnetze mit Allow ist eingetragen.

Unter Mobile Clients ist Provide a DNS server aktiviert und verweist auf die lokale IP Adresse der pfSense. Übersehe ich hier noch irgendetwas?

der DNS Resolver antwortet aber nicht.

Gibst du den VPN Clients denn auch einen DNS Server mit bei der VPN Einwahl?? Leider muss man jetzt wieder mal die Kristallkugel bemühen, weil man nicht weiss WELCHES der zahllosen möglichen Client VPNs du auf der pfSense realisiert hast?!

L2TP oder IPsec IKEv2 oder Wireguard oder OpenVPN?? Die pfSense kann ja alles...

Im VPN Setup aller o.a. VPN Spielarten kann man dediziert einen lokalen DNS Server an die VPN Clients übergeben was man z.B. mit ipconfig -all bei Windows Clients oder mit den bekannten HE.net Tools auf allen Smartphones testen kann bei aktivem VPN Tunnel.

und verweist auf die lokale IP Adresse der pfSense.

Welche denn wenn du es auf ALLEN Interfaces aktiviert hast?
Wenn man den Resolver auf der pfSense dann auch richtig customized funktioniert das absolut fehlerfrei und der DNS der pfSense antwortet dann auch fehlerlos.
Beim Regelwerk in der FW wird auch gerne mal vergessen das DNS TCP und UDP mit Port 53 verwendet!

Zitat von @aqui:

der DNS Resolver antwortet aber nicht.

Ja genau. Eingerichtet ist IPSec IKEv2, bin hier nach deiner Anleitung für die Anbindung für mobile Clients vorgegangen.

Im VPN Setup aller o.a. VPN Spielarten kann man dediziert einen lokalen DNS Server an die VPN Clients übergeben was man z.B. mit ipconfig -all bei Windows Clients oder mit den bekannten HE.net Tools auf allen Smartphones testen kann bei aktivem VPN Tunnel.

Unter mobile Clients habe ich die lokale IP Adresse der pfSense angegeben, auf dessen Interface der DNS auch lauschen sollte.

Beim Regelwerk in der FW wird auch gerne mal vergessen das DNS TCP und UDP mit Port 53 verwendet!

Ist soweit auch so eingerichtet

192.168.1.0/24 entspricht dem Network Interface 'TK_WIFI'. Phase 2 tunnelt mit 0.0.0.0/0 den gesamten Datenverkehr der mobilen Clients an die Pfsense.

Unter mobile Clients habe ich die lokale IP Adresse der pfSense angegeben

WELCHE denn?? Die vom LAN Interface?
Hast du dann auch bedacht diesen DNS Traffic im Regelwerk auf dem IPsec Tunnelinterface zu erlauben sofern dort nicht so oder so eine any zu any Scheunentorregel definiert ist?
Hast du zudem DNSSEC deaktiviert und den Forwarding Mode im Resolver aktiviert? Das ist auf deinem o.a. Screenshot leider nicht zu sehen.

Dein Fehler ist hier auf einem aktuellen 2.6.0er Setup leider nicht reproduzierbar.
Wenn man bei einem aktiven VPN Client z.B. mit nslookup oder dig die DNS Afrage checkt wird als DNS die pfSense mit einem korrekten Ergebnis angezeigt. 🤔

Zitat von @aqui:

Unter mobile Clients habe ich die lokale IP Adresse der pfSense angegeben

WELCHE denn?? Die vom LAN Interface?

Ja genau. Ich habe mehrere Lan Interfaces, in meinem Fall lauscht der DNS Resolver auf allen Interfaces, eingetragen ist hier 192.168.1.1 und eine FW Regel mit UDP/TCP auf Port53 verweist auf 192.168.1.1 (oben der erste Screenshot)

Hast du dann auch bedacht diesen DNS Traffic im Regelwerk auf dem IPsec Tunnelinterface zu erlauben sofern dort nicht so oder so eine any zu any Scheunentorregel definiert ist?

Hast du zudem DNSSEC deaktiviert und den Forwarding Mode im Resolver aktiviert? Das ist auf deinem o.a. Screenshot leider nicht zu sehen.

Ja genau, DNSSEC ist deaktiviert und Forwarding Mode ist aktiviert.

eine FW Regel mit UDP/TCP auf Port53 verweist auf 192.168.1.1 (oben der erste Screenshot)

Auf WELCHEM Interface ist die definiert??
Bedenke das auf dem LAN Interface diese Regel sinnfrei ist, weil der Request intern über das Loopback Interface bzw. das virtuelle VPN Interface kommt.
Außerdem gelten die LAN Regeln bekanntlich immer nur inbound also immer nur eingehend vom Netzwerkdraht zum Interface. Sie gelten NICHT outbound. Reihenfolge zählt wegen der "First match wins Regel" entsprechend auch.
Hast du einmal einen nslookup Check auf einem VPN Client gemacht? Was kommt dabei raus?

Generell ist auch nicht ganz verständlich warum du die pfSense selber als DNS für die VPN Clients mitgibst. Sie kann ja keine internen DNS Hostnamen auflösen. Was ist also der tiefere Sinn diese DNS Requests mit durch den Tunnel zu schleifen? Sinn würde das doch nur machen wenn du auch einen lokalen DNS betreibst (MS AD mit DNS usw.) und dessen IP an die Client durchreichst sofern du lokale Hostnamen auflösen willst. Lediglich rein öffentliche DNS Namen können die VPN Clients doch auch lokal auflösen.

Zitat von @aqui:

Auf WELCHEM Interface ist die definiert??
Bedenke das auf dem LAN Interface diese Regel sinnfrei ist, weil der Request intern über das Loopback Interface bzw. das virtuelle VPN Interface kommt.

Die FW Regel ist auf dem IPSec Interface definiert

Hast du einmal einen nslookup Check auf einem VPN Client gemacht? Was kommt dabei raus?

Ohne Erfolg

Firewall Log zeigt auch keine Deny Einträge

Zitat von @aqui:
Generell ist auch nicht ganz verständlich warum du die pfSense selber als DNS für die VPN Clients mitgibst. Sie kann ja keine internen DNS Hostnamen auflösen. Was ist also der tiefere Sinn diese DNS Requests mit durch den Tunnel zu schleifen?

Web Content Filterung und hatte eigentlich gehofft Host Overrides des DNS Resolvers an die IPSec Clients übergeben zu können.