VPN mit pfSense hinter FritzBox
-
Dann sollst du dein Regelwerk auf der B Seite noch mal prüfen, das dieses auch den gewünschten Datenverkehr nach A durchlässt, ich denke du wirst an diese Stelle scheitern, denn die Route hat die Fritz ja bereits.
-
Eine allow any any sowie ein "pfctl -d" brachten keine Besserung. Muss ich an der Outbound NAT noch etwas machen?
-
@mrsunfire said in VPN mit pfSense hinter FritzBox:
"B" hängt dabei nur mit ihrem LAN Port an der Fritzbox.
Das ist nicht ideal.
Warum läuft nicht das ganze B-Netz über die pfSense?@mrsunfire said in VPN mit pfSense hinter FritzBox:
Auf der Fritzbox habe ich eine statische Route ins Netz von "A" mit dem Gateway 192.168.178.100 angelegt. Dennoch geht es nicht.
Das reicht nicht. Es liegt ein asymmetrisches Routing vor.
Damit dieser Aufbau funktioniert, müsstest du auf jedem einzelenen Gerät in B, das mit A kommunizieren soll, eine statische Route anlegen.
-
Nein muss nicht, die Fritz ist GW in dem Netz und gibt das Netz von A, was hoffentlich ein anderes ist als 192.168.178.0/24 an die pfsense B weiter.
Die hat über den Tunnel das Netz von A in der Routing Tabelle und schickt es durch den Tunnel. Die ESP Pakete laufen dann zur Fritz und dann ins WAN, da sie an die Public IP von Standort A gerichtet sind. -
Netz A ist 192.168.1.0/24, Netz B ist 192.168.178.0/24. Die B hängt nur mit WAN (nicht LAN) an der Fritzbox. Von A kann ich B erreichen, aber umgekehrt nicht. Von der B pfSense kommt gefühlt nicht mal etwas bei A an, zumindest zeigen die Firewalllogs und ein Paketmitschnitt nichts an.
-
@mrsunfire said in VPN mit pfSense hinter FritzBox:
Die B hängt nur mit WAN (nicht LAN) an der Fritzbox.
Das macht die Sache auch nicht besser.
-
Ich verstehe nicht, wieso es nicht klappt. Bei den Routingtabellen sieht man auf der B auch schön, dass das korrekte Gateway für das A Netz genutzt wird.
-
@viragomann said in VPN mit pfSense hinter FritzBox:
Warum läuft nicht das ganze B-Netz über die pfSense?
Weil die Fritzbox WLAN und DECT macht.
-
Überzeuge dich erst mal, ob die Pakete bei der pfSense ankommen.
Diagnistic > Packet Capture ist hier das Werkzeug.Wähle das WAN, das am B-Netz hängt, und starte das Capture und versuche eine Verbindung von einem Gerät aufzubauen.
Sind die Pakete da, kannst du auf das OpenVPN Interface umschalten und da noch mal sniffen. Achte auch auf die Antwortpakete.Die Pings sollten eigentlich gehen, wenn die FB sie weiterroutet. Die sind nicht auf asymmetrisches Routing anfällig, weil sie zustandslos sind.
Falls nicht, ist vielleicht in der Interface-Konfiguration "Block private networks" angehakt.
Aber TCP-Verbindungen werden so nicht funktionieren. -
Auf dem WAN Interface von B sehe ich keine ICMP raus gehen. Ich sehe nur die TCP Verbindungen zwischen der öffentlichen IP von A und der 192.168.178.100 von B. Mein OpenVPN läuft via TCP.
Auf dem OpenVPN Interface bei B sehe ich dagegen ICMP ausgehend, es kommt aber nichts zurück. -
Das hier ist noch mal der OpenVPN Server bei B:
Und das der OpenVPN Client bei A:
-
Ich habe jetzt auf B meine Firewallregeln frisch durchgeladen und bekomme seitdem das bei einem Versuch nach A zu kommen:
Wieso antwortet hier die Fritzbox? (192.168.178.1)
-
@mrsunfire said in VPN mit pfSense hinter FritzBox:
Auf dem OpenVPN Interface bei B sehe ich dagegen ICMP ausgehend, es kommt aber nichts zurück.
Ist abstrakt, wenn man es nicht selbst sieht.
Die Pakete haben da nach wie vor die originale Quell-IP aus dem B-Netz?Ggf. auf A weiter untersuchen.
Was mir auffällt ist dass du ein /24 Tunnelnetz hast. Habe zwar hier schon einige Meldungen gelesen, dass dies belanglos sei, aber ich bevorzuge dennoch ein /30er für Site2Site plus ein eigenes Interface für die OpenVPN Instanz auf jeder Seite.
-
@mrsunfire said in VPN mit pfSense hinter FritzBox:
Wieso antwortet hier die Fritzbox? (192.168.178.1)
Der Host schickt seine Echo Requests auf die FritzBox, nachdem diese das Standardgateway ist und er keine bessere Route für die Remoteseite hat.
-
Ich habe gerade festgestellt, dass (wieso auch immer) eine Gatewaygruppe auf B erstellt war und dort WAN als Tier 2 und OpenVPN ohne Zuordnung hinterlegt war. Habe es nun gelöscht und starte frisch durch. Da ich nicht vor Ort bin und dort keinen Client zum spielen habe, bin ich auf die SSH und WebGUI Diagnosemöglichkeiten beschränkt. Mittelst SSH ist die Source IP die, des OpenVPN Gateways auf B.
Hier sieht man den Versuch das Netz hinter A zu erreichen:
EDIT: auch nach Reboot und ohne Gatewaygruppe gleiches Verhalten.
-
@mrsunfire said in VPN mit pfSense hinter FritzBox:
Mittelst SSH ist die Source IP die, des OpenVPN Gateways auf B.
Heißt, dass du auf dem VPN-Interface eine Outbound NAT Regel hast.
Aber die kann keine Erklärung dafür sein, dass nichts zurück kommt, im Gegenteil, das sollte es vereinfachen.192.168.1.1 ist die pfSense auf A? Ist diese auch das Standardgateway?
-
Die 192.168.1.1 ist die LAN IP der pfSense bei A, korrekt. Das OpenVPN Gateway auf A hat die 10.100.1.2. Auf A (Client) sieht es dann so aus:
Unbound NAT auf B so:
-
Wenn 192.168.1.1 die pfSense selbst ist und da am VPN Interface nichts zurückkommt, könnte nur eine Firewall-Regel auf A den Zugriff blockieren, am spezifischen VPN-Interface, auf OpenVPN oder eine Floating-Regel.
Ansonsten würde ich, wie oben erwähnt, den Tunnel auf ein /30er Netz reduzieren.
-
Du meinst so?
Die VPN bzw. OpenVPN Interfaces stehen aktuell komplett offen auf beiden Seiten, um genau das auszuschließen.
Das Problem scheint auch, dass meine ICMP irgendwo "gefressen" werden. Ich vermute da stark die Fritzbox. Ein Gerät das eben noch antwortete, bringt nun nichts mehr zurück. Ich erreiche es aber via HTTP und FTP. Ich werde morgen dort einen Client mittels Teamviewer laufen lassen um etwas besser zu diagnostizieren.
Vielleicht hat aber sonst noch jemand eine Idee.
-
Ja, auf beiden Seiten, natürlich.
Voraussetzung ist, dass es nur einen Client gibt.