[Gelöst] pfSense OpenVPN Site to Site Routing
-
Guten Morgen,
zunächst einmal möchte ich mich bei Euch beiden (viragomann und orcape) für die Unterstützung und Hilfe bedanken!!!"… D.h. dein VPN Client hat die IP 10.111.111.2, soweit richtig? ...."
-> Ja, wie bereits geschrieben erreiche ich beide Tunnelenden incl. der dahinter liegenden LAN's über den Tunnel.
"... Wenn das alles so eingerichtet ist, müsste es funktionieren. Das Problem kann eigentlich nur mehr am Routing oder an den Regeln liegen. ..."
-> Das vermute ich auch, zumal ich z. B. die Pings auf 8.8.8.8 auf den ovpns1 Schnittstelle am Server mitgeloggt sehe.
"... Nachdem du am Client das VPN Interface hinzugefügt hast, sind auch auf diesem Regeln zu konfigurieren, damit der VPN-Traffic erlaubt wird. Hast du das gemacht? Am neuen Interface einfach any to any. ..."
-> Ja, ich habe zunächst überall pass any to any auf die Schnittstellen gelegt.
"... Nach Änderungen ggf. den VPN-Server bzw. -Client neu starten. ..."
-> Habe ich gemacht.
" ... Ansonsten würde mir nur noch Troubleshooting einfallen. Dazu achte darauf, dass in den Log-Settings auch das Logging der Default-block Rule aktiviert ist.
Ob das Routing und NAT auf Serverseite in Ordnung ist, lässt sich einfach über das pfSense Ping-Tool überprüfen. Dazu als Host eine externe IP/Namen und als Source Adresse den VPN Server einstellen.
Wenn in Logs nicht zu sehen ist, kannst du Packet Capture an den diversen Interfaces einsetzen, um zu sehen, was die Paket machen. ..."Das werd ich mir sicher noch genauer ansehen müssen.
Es kann eigentlich nur ein Routingproblem sein und muss doch zu lösen sein.
Ich melde mich.Gruß
Peter -
Hi,
nur mal so eine Vermutung.
Wenn ich bei mir, pfSense (Diagnostics-Ping) vom OpenVPN-Interface auf die IP 216.58.216.228 (google.com) einen Ping mache (ICMP any-to-any Rule), erhalte ich eine Antwort. Check das mal ab.
Wenn dem so ist, solltest Du auch Internetverbindung haben.
Bei mir steht NAT-Outbound auf automatic, dabei sind alle Interfaces, incl. der OpenVPN-Interfaces als Source aktiviert.
Wenn Du pf-Version 2.2 hast, und es steht auf manuell, stell das einfach mal auf Hybrid.
Gruß orcape -
Hallo,
werde ich heute Abend mal testen.
NAT-Outbound hatte ich sowohl auf Automatic, Hybrid, Manuell.
Leider gab es hier keine Veränderung bezüglich des Internetzugriffs über den Tunnel zum Standort A.
Ich setze in beiden Standorten pfsense 2.2 ein.Das ganze Scenario läuft z. Z. in einer Testumgebung.
Gruß
Peter -
Hallo,
bis jetzt keinen Erfolg.
Ich kann von der pfsense OpenVPN Client Standort B ohne Probleme von allen Schnittstellen aus Pings setzen.
Nur scheint der Traffic ins Internet trotzdem über die eigene WAN Schnittstelle zu laufen.
Das scheint aber auch normal, weil in der Routing Tabelle die Default Route immer noch die WAN-Schnittstelle ist.
Nur wenn ich diese lösche, d. h. das Default GW explizit auf die OpenVPN Schnittstelle lege, wird der Traffic über den Standort A geleitet.Nur die angeschlossenen Clients erreichen auch hiermit das Internet nicht.
Das ist schon komisch.Scheinbar ist die pfsense OpenVPN Client am Standort B nicht in der Lage den gesamten Traffic von der LAN-Schnittstelle durch den Tunnel
zum Standort A zu führen um dort ins Internet auszusteigen.Ich bin ratlos, zumal ich echt nicht der Anfänger in diesem Bereich bin.
Danke nochmal für Eure Hilfe.
Gruß
Peter -
Bei welcher pfsense hast denn denn an den NAT-Einstellungen rumgespielt? Richtig wäre eigentlich am Standort A. Da müßtest du dann manuell Regeln für das Netz von Standort B anlegen.
-
Hallo,
die Regeln existieren ja im Standort A (pfSense OpenVPN Server) wie auch im Standort B (pfSense OpenVPN Client) .
Nur kommt der Traffic am Server scheinbar gar nicht erst an.Oder habe ich dich falsch verstanden?
Gruß
Peter -
Die Regeln bei Standort A sollten eigentlich reichen. Kommen die Clients denn ins Netz von Standort A? Hast du die Firewall-Regeln schon überprüft?
-
Ja alle Clients im Standort B kommen zum Standort A und umgekehrt.
Nur eben funktioniert der Zugriff zum Internet nur über die jeweilige Standort pfsense.
Das darf oder soll nicht sein, weil der gesamte Traffic aller Clients im Standort B durch den Tunnel zum Standort A geführt werden soll und
der Internetzugriff nur im Standort A realisiert werden soll.Gruß
Peter -
Hi!
Das kann ja nicht sein!
Was sagen die Logs? Der Traffic von den LAN clients ins Internet am Standort B muss ja von einer Regel erlaubt werden. Wenn du alles loggst, dann kannst du dir ja ansehen, welche Regel das ist. Und genau dieser Regel setzt du das VPN-Gateway, wie zuvor beschrieben. Das nennt sich "Policy based routing", also die FW-Regel ist gleichzeitig fürs Routing zuständig.
Wenn keine Regel den direkten Traffic ins WAN erlaubt, kann es auch keinen geben. Also bitte prüfe deine Logs und deine Regeln.
Hast du etwa eine Floating rule?? Die haben nämlich Vorrang. Aber wie auch immer, das Log wird dich darüber aufklären, wie der Traffic ins WAN gelangt.Wenn ohnehin der ganze Traffic von B übers VPN laufen soll, kannst du auch das VPN Gateway als default setzen, dann ersparst du dir das Troubleshooting. Das Default-Gateway zu löschen ist nicht schlauste Weg.
Grüße
-
Das mit dem Löschen des Default GW habe ich anders gemeint. Ich habe das VPN Gateway als Default GW definiert.
Dennoch konnte kein Client aus dem Standort B über Standort A das Internet erreichen.
Da ist der Wurm drin!
Ich werde mir das nächst Woche nochmal genau ansehen (habe gerade alles heruntergefahren).Für alle die hier mitlesen, eine NW-Übersicht über mein Vorhaben.
Gute Nacht!
Peter
-
Hallo,
@viragomann:…
Wenn ohnehin der ganze Traffic von B übers VPN laufen soll, kannst du auch das VPN Gateway als default setzen, dann ersparst du dir das Troubleshooting.
...Ich habe mir das noch mal durch den Kopf gehen lassen.
Wenn als Default das VPN GW gesetzt ist, würde doch der pfsense OpenVPN Client für den Verbindungsaufbau des Tunnels sein
Gegenüber nicht mehr finden, weil der pfsense OpenVPN Server ja irgendwo im Internet über zahlreiche Hops zu erreichen ist.
D. h., die Route dahin wäre für den Tunnelaufbau unbekannt.
Oder sehe ich hier was falsch?In meiner Testumgebung werde ich das aber nochmal ausprobieren.
Ich habe gerade diese Anleitung gefunden:
https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_OpenVPN-connection_in_PfSense_2.1Gruß
Peter -
Hallo!
Ich habe mir das noch mal durch den Kopf gehen lassen.
Wenn als Default das VPN GW gesetzt ist, würde doch der pfsense OpenVPN Client für den Verbindungsaufbau des Tunnels sein
Gegenüber nicht mehr finden, weil der pfsense OpenVPN Server ja irgendwo im Internet über zahlreiche Hops zu erreichen ist.
D. h., die Route dahin wäre für den Tunnelaufbau unbekannt.
Oder sehe ich hier was falsch?Grüße
Das siehst du wohl richtig. So einfach ist es also doch nicht. Das war zu schnell geschossen. -
Hi,
irgendwie macht mich Dein doppelter Eintrag (push "redirect-gateway def1") in der openvpn-csc etwas stutzig.
Das muss nur über die Server.conf so funktionieren.
Der Standartgateway muss so bleiben, das ist klar.
Lies Dir das mal durch….
http://openvpn.net/index.php/open-source/documentation/howto.html#redirect
Eine NAT-Rule…iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
…ist dann zwingend erforderlich um vom Tunnel ins Internet zu kommen, das dürfte klar sein.
Ebenfalls die DNS-Funktion..push "dhcp-option DNS 10.8.0.1"
Letzteres sollte allerdings einen Ping von Standort B noch Internet A nicht stören, vorrausgesetzt es besteht eine ICMP-Rule.
Gruß orcape -
Hallo,
danke für die Infos.
Nächste Woche beschäftige ich mich noch mal intensiv mit der Problematik.
Ich werde Euch auf dem Laufenden halten.Schönes Wochenende!
Gruß
Peter -
Hallo,
das Problem ist gelöst.
Danke an Euch beide für die Unterstützung!!!Das wichtigste was bei meiner Config fehlte:
Auf der pfsense OpenVPN Serverseite muss manuell eine NAT Outbound Regel für das pfsense OpenVPN Client Netzwerk
erstellt werden. Es reicht nicht nur das OpenVPN Netzwerk zu definieren.
Weiter muss auf der pfsense OpenVPN Serverseite unter Advanced configuration der Eintrag "redirect-gateway def1;"
vorgenommen werden.
Quelle: https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_OpenVPN-connection_in_PfSense_2.1Was mir aber aufgefallen ist:
Wenn aus irgendwelchen Gründen der Tunnel unterbrochen wird, dann routet wieder jeder Standort für sich den
Traffic ins Internet. Das ist ja zunächst auch normal, da das Default GW dafür verantwortlich ist.
Für mein Vorhaben ist das aber unerwünscht.
D. h., nur Internetzugang für die Clients über den Tunnel zum pfsense OpenVPN Server, oder keinerlei Verbindung.Ich habe lange gerätselt und mir fiel keine Firewallregel dafür ein, welche nur den Internetzugang an der
pfsense OpenVPN Client verbietet und alles ander zulässt.
Dann habe ich den Gedanken mit dem "Policy based routing" aufgegriffen.
Das funktioniert dann genauso wie ich mir das vorgestellt habe.Habt ihr vielleicht einen Gedanken hierzu?
Gruß
Peter -
Hi Peter,
schön das Du hier schon gewisse "Vorarbeit" geleistet hast. ;)
Redirect Gateway ist eines meiner nächsten Projekte, welches aber nicht im produktiven Umfeld stattfindet, also auch nicht wirklich kritisch ist.
Nun hatte ich mit meiner Vermutung, NAT-Problem doch nicht ganz unrecht.
Hätte eigentlich auch gleich drauf kommen können. :(
Beim Routing mehrerer Serverinstanzen reicht auch das Routing auf den anderen Tunnel nicht aus.
Da musst Du auch zwingend zum remoten Netz mit routen.Dann habe ich den Gedanken mit dem "Policy based routing" aufgegriffen.
Ist eine Möglichkeit.
Bei den Clients als Gateway nicht mehr den default Gateway eintragen, sondern den Tunnel ?
Die soll´n ja eh nicht mehr direkt ins Netz.
Gruß orcape -
Hallo!
Ich habe lange gerätselt und mir fiel keine Firewallregel dafür ein, welche nur den Internetzugang an der
pfsense OpenVPN Client verbietet und alles ander zulässt.
Dann habe ich den Gedanken mit dem "Policy based routing" aufgegriffen.
Das funktioniert dann genauso wie ich mir das vorgestellt habe.Habt ihr vielleicht einen Gedanken hierzu?
Was jetzt? Funktioniert es nun oder nicht?
Eine Regel, die Internettraffic verbietet könnte am LAN Interface so aussehen:
Block IPv4 * LAN net * ! <vpn tunnel="" gateway="">* * none</vpn>
Diese sollte aber gar nicht nötig sein, weil eh schon eine Regel den Traffic ausschließlich übers VPN Gateway erlaubt. Wenn, dann sollte sie unterhalb dieser stehen.
Grüße
-
Hallo,
@orcape:… Bei den Clients als Gateway nicht mehr den default Gateway eintragen, sondern den Tunnel ?
Die soll´n ja eh nicht mehr direkt ins Netz.
...Ich denke das wird so nicht funktionieren, da ein GW sich zwingend immer im selben Subnet wie die Clients befinden muss.
Und die Clients befinden sich in meinem Fall im NW 192.168.39/24.
Das Gateway hierfür ist 192.168.39.254.
Der Tunnel ist aber im NW 10.111.111.0/30.Gruß
Peter -
…
Was jetzt? Funktioniert es nun oder nicht?Eine Regel, die Internettraffic verbietet könnte am LAN Interface so aussehen:
Block IPv4 * LAN net * ! <vpn tunnel="" gateway="">* * none</vpn>
Diese sollte aber gar nicht nötig sein, weil eh schon eine Regel den Traffic ausschließlich übers VPN Gateway erlaubt. Wenn, dann sollte sie unterhalb dieser stehen
…Ja es funktioniert.
Ich habe auf die Client LAN Regel das Tunnel Gateway gesetzt. Damit funktioniert alles 100%ig.
Pass IPv4 * LAN net * * * OPT1_VPNV4 none <beschreibung>Aber ohne diese Regel gibt es ein Problem falls es eine Tunnelunterbrechung gibt.
Alle Clients gehen dann nämlich über die Default Gateway ins Internet.
Das dürfen sie aber nicht.
Leider kenne ich keine Regel, welche verhindert dass im Falle der Tunnelunterbrechung die Clients ausversehen am
Standort pfsense OpenVPN Client in das Internet gehen können.Gruß
Peter</beschreibung> -
Also die Regel mit dem Tunnel Gateway wird praktisch deaktiviert, wenn das Gateway weg ist?
Das wusste ich auch nicht. Wieder was gelernt. :)Einen Vorschlag für eine Regel, die den direkten Internetzugriff verhindert, habe ich ja oben gepostet.
Das ist eine Block-Regel auf dem LAN Interface oder wo immer die Clients dranhängen, die sämtlichen Traffic unterbindet mit Ausnahme des Tunnel-Netzes.
Die Ausnahme setzt man, indem man bei Destination "not" anhakt und das entsprechende Netz (Tunnel) einstellt. Wenn du mehrere Ausnahmen benötigst, lege dir dazu erst einen Alias an und verwende diesen in Destination.Gruß