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?
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/contentid/7152037136
Ausgedruckt am: 04.11.2024 um 18:11 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...
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.
Das ist bekannt und iPhone spezifisch:
https://www.heise.de/news/Apple-raeumt-ein-iOS-Dienste-koennen-VPN-Tunne ...
https://www.heise.de/news/Apple-raeumt-ein-iOS-Dienste-koennen-VPN-Tunne ...
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!
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. 🤔
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.
Wenn's das denn war bitte nicht vergessen deinen Thread als erledigt zu schliessen!