37
2 PfSensen mit OpenVPN verbinden 1x Server 1x Client
N'abend! Noch wer wach?
Da ich nicht 100% OVPN-sicher bin
kurze Frage:
Ich möchte 2 PfSense mit OpenVPN verbinden um vorübergehend, bis die feste IP geschaltet ist, auf eine externe Büchse (und das Netz dahinter) zugreifen zu können.
Da die Büchse 2 in einem privaten Range ist, habe ich mir überlegt, das mit OVPN zu machen und sich diese auf Büchse 1 im Clientmodus einwählen zu lassen.
Büchse 1 (Server) ist konfiguriert als Remote Access (SSL/TLS + User Auth)
Da man bei der PfSense ja im Client-Mode keine .ovpn Config importieren kann, muss ich es händisch machen.
In der Client Config der PfSense sehe ich aber nur Peer to Peer. Das irritiert mich gerade ein wenig...
Kanns leider vorher nicht testen, da ich aus anderen Gründen grade keine VM starten kann...
Hat das so seine Richtigkeit oder übersehe ich was relevantes?
THX!
Buc
Da ich nicht 100% OVPN-sicher bin
kurze Frage:Ich möchte 2 PfSense mit OpenVPN verbinden um vorübergehend, bis die feste IP geschaltet ist, auf eine externe Büchse (und das Netz dahinter) zugreifen zu können.
Da die Büchse 2 in einem privaten Range ist, habe ich mir überlegt, das mit OVPN zu machen und sich diese auf Büchse 1 im Clientmodus einwählen zu lassen.
Büchse 1 (Server) ist konfiguriert als Remote Access (SSL/TLS + User Auth)
Da man bei der PfSense ja im Client-Mode keine .ovpn Config importieren kann, muss ich es händisch machen.
In der Client Config der PfSense sehe ich aber nur Peer to Peer. Das irritiert mich gerade ein wenig...
Kanns leider vorher nicht testen, da ich aus anderen Gründen grade keine VM starten kann...
Hat das so seine Richtigkeit oder übersehe ich was relevantes?
THX!
Buc
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 534696
Url: https://administrator.de/forum/2-pfsensen-mit-openvpn-verbinden-1x-server-1x-client-534696.html
Ausgedruckt am: 22.12.2024 um 01:12 Uhr
37 Kommentare
Neuester Kommentar
Hallo Buc,
wenn ich dich richtig gelesen habe, arbeitest du schon lang und ausgiebig mit pfsense'? Dann dürfte so eine Kleinigkeit doch keine Frage wert sein?
Site to Site und gut ist...
VG
wenn ich dich richtig gelesen habe, arbeitest du schon lang und ausgiebig mit pfsense'? Dann dürfte so eine Kleinigkeit doch keine Frage wert sein?
Site to Site und gut ist...
VG
Moin,
konfiguriere den Tunnel doch mit nen PSK. Dann ist das einfach auf beiden seiten identisch einzurichten. Ansonsten eben die Zertifikats Nummer wie im guide.
Gruß
Spirit
konfiguriere den Tunnel doch mit nen PSK. Dann ist das einfach auf beiden seiten identisch einzurichten. Ansonsten eben die Zertifikats Nummer wie im guide.
Gruß
Spirit
Site-to-Site mit einer Büchse die in nem privaten Range ist ohne Portweiterleitung?
Das ist sozusagen ein DS-Lite Provider da.
Bei IPSec sehe ich da schwarz. EDIT: Wäre nach nachdenken zu testen... Könnte auch gehen...
Habe wirklich noch keine (Site-to-Site) Verbindung eingerichtet, die nicht ne öffentliche IP oder mindestens ne Portweiterleitung auf beiden Seiten hatte. (Sonst tät ich ja nicht so doof fragen...)
DS-Lite hat hier keiner. Kenn ich nur vom Hörensagen.
Wenn ihr beide sagt: Site-to Site geht (ich war halt unsicher, da ich den Verbindungsaufbau nicht kenne) dann ists ja super. Werd ich als erstes testen.
Ob PSK oder Zertifikate ist doch egal??? Hier gehts doch eher um: "Wer initiiert wann und wie den Tunnel auf welchem Port und erwartet auf der Gegenseite abc,,,)
Was ist nun mit dieser Client-Auswahl? Es ist doch merkwürdig einen Client einzurichten und dem zu sagen, dass die Gegenseite im Peer-to-Peer Modus arbeitet???)
VG
Buc
Das ist sozusagen ein DS-Lite Provider da.
Bei IPSec sehe ich da schwarz. EDIT: Wäre nach nachdenken zu testen... Könnte auch gehen...
Habe wirklich noch keine (Site-to-Site) Verbindung eingerichtet, die nicht ne öffentliche IP oder mindestens ne Portweiterleitung auf beiden Seiten hatte. (Sonst tät ich ja nicht so doof fragen...)
DS-Lite hat hier keiner. Kenn ich nur vom Hörensagen.
Wenn ihr beide sagt: Site-to Site geht (ich war halt unsicher, da ich den Verbindungsaufbau nicht kenne) dann ists ja super. Werd ich als erstes testen.
Ob PSK oder Zertifikate ist doch egal??? Hier gehts doch eher um: "Wer initiiert wann und wie den Tunnel auf welchem Port und erwartet auf der Gegenseite abc,,,)
Was ist nun mit dieser Client-Auswahl? Es ist doch merkwürdig einen Client einzurichten und dem zu sagen, dass die Gegenseite im Peer-to-Peer Modus arbeitet???)
VG
Buc
Wichtig ist nur, das einzig eine Seite den Tunnel initiiert. Das ist dann der client.
Peer to Peer ist wohl auch der falsche Begriff.
Probier die Site-to-Site, wenn das nicht geht, hast du ggf. sogar ganz andere Probleme.
Probier die Site-to-Site, wenn das nicht geht, hast du ggf. sogar ganz andere Probleme.
Zitat von @Spirit-of-Eli:
Wichtig ist nur, das einzig eine Seite den Tunnel initiiert. Das ist dann der client.
Wichtig ist nur, das einzig eine Seite den Tunnel initiiert. Das ist dann der client.
Wo ist aber diese Einstellung bei OpenVPN? Bei der IPSec kenne ich sie.
Dann mach ich das im Zweifel mit IPSec. Das kann ich.
Zitat von @certifiedit.net:
Peer to Peer ist wohl auch der falsche Begriff.
Probier die Site-to-Site, wenn das nicht geht, hast du ggf. sogar ganz andere Probleme.
Peer to Peer ist wohl auch der falsche Begriff.
Probier die Site-to-Site, wenn das nicht geht, hast du ggf. sogar ganz andere Probleme.
Die PfSense nennt das "Peer to Peer" kann ich nicht ändern.
Mal sehen, danke für die Tipps euch beiden! Klappen wird das schon. Die Frage ist nur immer, wieviel Nerven man verliert und wieviele graue haare wachsen.
CU
Buc
Du richtest doch nur einen simplen OVPN Server auf der einen Seite und auf der anderen einen Client ein.
Die Client Konfig wird unter dem (Clients) Tab eingerichtet. Die Konfig ist hier erstmal identisch. Einzig die (Tunnel Settings) müssen entsprechend gesetzt werden.
An dieser Stelle im PfSense Book wird es genau beschrieben:
https://docs.netgate.com/pfsense/en/latest/book/openvpn/site-to-site-exa ...
//Das nur von der Client Seite eine Verbindung aufgebaut wird, kommt bei IPsec zum tragen. Bei OVPN ist das bei Design schon so fest gegeben wenn du dieser Anleitung folgst.
Die Client Konfig wird unter dem (Clients) Tab eingerichtet. Die Konfig ist hier erstmal identisch. Einzig die (Tunnel Settings) müssen entsprechend gesetzt werden.
An dieser Stelle im PfSense Book wird es genau beschrieben:
https://docs.netgate.com/pfsense/en/latest/book/openvpn/site-to-site-exa ...
//Das nur von der Client Seite eine Verbindung aufgebaut wird, kommt bei IPsec zum tragen. Bei OVPN ist das bei Design schon so fest gegeben wenn du dieser Anleitung folgst.
Hi,
Mit 2 pfSensen ist die EInrichtung des Tunnels ein Kinderspiel. Einfacher wie wenn Du einen DD-, oder OpenWRT Router auf der remote Seite hast.
Kreier Dir Deine Schlüssel auf der Serverseite, richte den Server und die Firewallregeln ein und exportiere den Client einfach mit der pfSense-internen Software (zusätzliches Paket, nachinstallieren) auf die remote pfSense.
Und wenn Du ein Problem hast, einfach @aquis Tutorial richtig lesen, dann klappt das schon.
Gruß orcape
Wo ist aber diese Einstellung bei OpenVPN? Bei der IPSec kenne ich sie.
Der OpenVPN-Client initiiert den Tunnel automatisch, da gibt es nichts einzustellen und das selbst bei einem UMTS-Anschluss.Mit 2 pfSensen ist die EInrichtung des Tunnels ein Kinderspiel. Einfacher wie wenn Du einen DD-, oder OpenWRT Router auf der remote Seite hast.
Kreier Dir Deine Schlüssel auf der Serverseite, richte den Server und die Firewallregeln ein und exportiere den Client einfach mit der pfSense-internen Software (zusätzliches Paket, nachinstallieren) auf die remote pfSense.
Und wenn Du ein Problem hast, einfach @aquis Tutorial richtig lesen, dann klappt das schon.
Gruß orcape
Die Client Konfig kann man bei einer Sense nicht importieren soweit ich weiß. Das wäre mir neu.
Die Client Konfig kann man bei einer Sense nicht importieren soweit ich weiß. Das wäre mir neu.
Ich habe auch nicht von Import gesprochen, sondern von Export.Vom Server zum Client.Da gibt es in "System-Package Manager" ein Paket namens "openvpn-client-export", welches man nachinstalliert.
Wie im Bild zu sehen gibt es dann einen zusättzlichen Reiter zum Client-Export sowie den Reiter zum Schlüsselexport.
Funktioniert tadellos.
Das schon. Er will ja allerdings zwei PfSense koppeln.
Das schon. Er will ja allerdings zwei PfSense koppeln.
Und wo soll da das Problem sein? Funktioniert genau so, wie ich das beschrieben habe.Eine pfSense erhält den OpenVPN-Server, die andere den Client und den kann ich von der ersten exportieren.
Oder wo siehst Du da das Problem?
Nach @aquis Tutorial richten, geht nix schief.
Zitat von @Spirit-of-Eli:
//Das nur von der Client Seite eine Verbindung aufgebaut wird, kommt bei IPsec zum tragen. Bei OVPN ist das bei Design schon so fest gegeben wenn du dieser Anleitung folgst.
//Das nur von der Client Seite eine Verbindung aufgebaut wird, kommt bei IPsec zum tragen. Bei OVPN ist das bei Design schon so fest gegeben wenn du dieser Anleitung folgst.
DAS war mir nicht klar. Danke. Mittlerweile habe ich das rausgefunden, aber die Bezeichnungen (das Design?) erscheinen mir hier genauso sinnvoll wie die Master / Slave Platten beim IDE. Warum nicht 2 Peers eine Verbindung aushandeln, wissen nur die Entwickler... Wird wohl historisch bedingt sein...
@ all: aqui's Tutorial? Gucks mir nochmal an, bevor das hier peinlich wird...
Wusste aber nicht, dass es das auch im OVPN-Flavour gibt. @Spirit-of-Eli: Er will überhaupt nicht, er MUSS, weil die Nasen von Colt-Telecom den Anschluss mit der öffentlichen IP nicht gebacken kriegen...
Tunnel steht soweit in der Testumgebung, aber das Routing klappt nicht. Jetzt lese ich aqui und dann kommt die Frage.
Buc
Jo... Nun kommt die Frage...
Das OpenVPN ist etwas weniger trivial, als ich dachte, nachdem ich mal einen Server eingerichtet hatte und den Windows-Client zum laufen bekam... Trotzdem an sich kein Hexenwerk, (oder doch, wie der E.v.D. sagen würde?)
Mittlerweile behaupte ich, das grundlegend gerafft zu haben, jedoch habe ich im Testaufbau ein Problem:
Der Tunnel routet nicht. Oder nur zur Hälfte.
Testaufbau:
PfSense in Virtualbox mit Host-only-Adapter. Client Win 7 ebenfalls so. Damit habe ich das doppelte NAT beim Kunden nachgestellt.
Funktioniert super, Traffic kommt auf meiner dyn. IP (Server) an. Internet geht eh. Hier sitzt also der Client.
OpenVPN-Server eingerichtet auf meiner PfSense mit Shared-Key entsprechend der Netgate-Anleitung. Client-PfSense in der V-Box eingerichtet. Tunnel steht. Und nun kommts:
Die routen nicht vom jeweiligen LAN ins andere LAN. OVPN-Interface pingt auf der PfSense jeweils prima. Also Ping --> Address Remote-Client --> Interface OVPN. Aber: Ping --> Address Remote Client --> Interface LAN bringt auf BEIDEN Seiten timeouts.
Traceroute kommt vom jeweiligen LAN bis zum Tunneladapter der Gegenseite. Also: 10.0.81.1 --> 10.0.81.2 ok. Danach Funkstille. Aha, denkt man: Müssen die Routen oder die Firewallregeln sein. Nö. Ist nicht. Route ist gesetzt. Auf beiden Seiten. Firewall erlaubt den Traffic auf dem OVPN-Interface ("any") und auf dem WAN-Port 1194 des Servers ebenfalls.
Das ganze gilt also vice-versa: PfSense1-->OVPN-Interface--> LAN 2 gut. PfSense1 LAN-Interface-LAN 2 tot. Und umgekehrt.
Und LAN-Client --> PfSense Gegenseite oder Client Gegenseite auch tot. Aber OVPN Interface Gegenseite gut.
Definitiv die Routen, aber warum? Auch das von @aqui vorgeschlagene "Push Route" bringt nix. (Ist das überhaupt nötig?)
Durch gesetzte existierende Routen geht kein Traffic obwohl er in der Firewall erlaubt ist. Hatte ich so noch nicht. Im Netgate-Forum war ein sehr ähnlicher Fall. Bei dem ging es nach Neuinstallation der OVPN-Server und Clients. Habe ich gemacht: Nix.
Was würdet ihr machen?
Buc-tracker
Das OpenVPN ist etwas weniger trivial, als ich dachte, nachdem ich mal einen Server eingerichtet hatte und den Windows-Client zum laufen bekam... Trotzdem an sich kein Hexenwerk, (oder doch, wie der E.v.D. sagen würde?)
Mittlerweile behaupte ich, das grundlegend gerafft zu haben, jedoch habe ich im Testaufbau ein Problem:
Der Tunnel routet nicht. Oder nur zur Hälfte.
Testaufbau:
PfSense in Virtualbox mit Host-only-Adapter. Client Win 7 ebenfalls so. Damit habe ich das doppelte NAT beim Kunden nachgestellt.
Funktioniert super, Traffic kommt auf meiner dyn. IP (Server) an. Internet geht eh. Hier sitzt also der Client.
OpenVPN-Server eingerichtet auf meiner PfSense mit Shared-Key entsprechend der Netgate-Anleitung. Client-PfSense in der V-Box eingerichtet. Tunnel steht. Und nun kommts:
Die routen nicht vom jeweiligen LAN ins andere LAN. OVPN-Interface pingt auf der PfSense jeweils prima. Also Ping --> Address Remote-Client --> Interface OVPN. Aber: Ping --> Address Remote Client --> Interface LAN bringt auf BEIDEN Seiten timeouts.
Traceroute kommt vom jeweiligen LAN bis zum Tunneladapter der Gegenseite. Also: 10.0.81.1 --> 10.0.81.2 ok. Danach Funkstille. Aha, denkt man: Müssen die Routen oder die Firewallregeln sein. Nö. Ist nicht. Route ist gesetzt. Auf beiden Seiten. Firewall erlaubt den Traffic auf dem OVPN-Interface ("any") und auf dem WAN-Port 1194 des Servers ebenfalls.
Das ganze gilt also vice-versa: PfSense1-->OVPN-Interface--> LAN 2 gut. PfSense1 LAN-Interface-LAN 2 tot. Und umgekehrt.
Und LAN-Client --> PfSense Gegenseite oder Client Gegenseite auch tot. Aber OVPN Interface Gegenseite gut.
Definitiv die Routen, aber warum? Auch das von @aqui vorgeschlagene "Push Route" bringt nix. (Ist das überhaupt nötig?)
Durch gesetzte existierende Routen geht kein Traffic obwohl er in der Firewall erlaubt ist. Hatte ich so noch nicht. Im Netgate-Forum war ein sehr ähnlicher Fall. Bei dem ging es nach Neuinstallation der OVPN-Server und Clients. Habe ich gemacht: Nix.
Was würdet ihr machen?
Buc-tracker
Moin,
tatsächlich würde ich dafür einfach nicht VBox einsetzen. Die dortige Netzwerk Lösung ist einfach unterirdisch.
Nutz lieber HyperV.
Gruß
Spirit
Und LAN-Client --> PfSense Gegenseite oder Client Gegenseite auch tot. Aber OVPN Interface Gegenseite gut.
Definitiv die Routen, aber warum? Auch das von @aqui vorgeschlagene "Push Route" bringt nix. (Ist das überhaupt nötig?)
Push Route stellt Dir die Route zum Netzwerk hinter dem OVPN-Server bzw. auf ein anderes Netzwerk, mit dem die Server-pfSense verbunden ist her.
Beim OVPN-Server solltest Du, ausser die Routen in den Servereinstellungen aufs remote Netz zu definieren, auch noch die CCD (Client-Config-Directory) einrichten.
Das machst Du unter VPN - OpenVPN - Client Specific Overrides ...
...hier trägst Du auch die remoten Netze ein.
Gruß orcape
Auch das von @aqui vorgeschlagene "Push Route" bringt nix. (Ist das überhaupt nötig?)
Das ist auch auf dem Client Unsinn. "Push Route" schiebt nur das lokale LAN am OVPN Server zum Client. Wenn auch das Client LAN Netz geroutet werden muss dann dann müssen 2 route Kommandos zusätzlich in die Server Conf.Beispiel Lokales LAN Server = 192.168.88.0 /24 und Client LAN = 172.16.1.0 /24:
Server Konfig:
route 172.16.1.0 255.255.255.0 = bringt die Route in die Kernel Routing Tabelle
iroute 172.16.1.0 255.255.255.0 = routet das Client Netz in den Tunnel
Client Konfig:
route 192.168.88.0 255.255.255.0
Dort reicht eine einfache statische Route
Das Banalste dafür ist eine Site 2 Site Konfig mit statischen Passwörtern wenn dir das als Security reicht:
https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configuring-a-sit ...
TEST:
Ich kann leider meine Antwort nicht abschicken. Wenn ich den Text hier einfüge sind die Buttons Vorschau und Senden ausgegraut. Weiss jemand, was das nun wieder ist???
VG
Buc
Edit: O.k. Das ging. Warum geht die inhaltliche Antwort nicht? Wurde da irgendwas am Forum umgestellt? Versuche mal die Antwort zu splitten...
Jetzt hats geklappt...
Ich kann leider meine Antwort nicht abschicken. Wenn ich den Text hier einfüge sind die Buttons Vorschau und Senden ausgegraut. Weiss jemand, was das nun wieder ist???
VG
Buc
Edit: O.k. Das ging. Warum geht die inhaltliche Antwort nicht? Wurde da irgendwas am Forum umgestellt? Versuche mal die Antwort zu splitten...
Jetzt hats geklappt...
So. Kann "Vollzug" melden. Tunnel steht und routet auch. War aber ne schwere Geburt...
Die Dokumentation ist eher verwirrend. Mal heisst es: "Create an Interface for OpenVPN" in der Standardanleitung, dann heisst es wieder, man muss das
nicht machen.
Mal heisst es, die Routen werden über die Angaben der Subnetze automatisch erzeugt (man kann sie ja auch sehen), mal heisst es "push route" und "route"
und "iroute" in der Advanced Configuaration angeben.
OPNSense will die Advanced Configuration demnächst komplett entfernen, da sie unnötig und "dangerous" sei. Dann muss es ja ohne gehen, aber wie route ich
dann in ein 2. Netz?
Problematisch kann es wohl werden, wenn (wie bei mir) weitere IPSec-Tunnel mit dem lokalen Netz der Serverseite existieren und dann ein OpenVPN
hinzukommt.
Warum das so kompliziert war, weiss der Geier. Werde nochmal ein bisschen rumtesten.
Nun aber die nächste herausforderung:
Site A (OVPN-Client) <--------ovpn ------------------> Site B (OVPN-Server) <---IPSec ----> Site C
192.168.22.0/24 <------>10.0.8.0/24 <----------->192.168.1.0/24 <-----------IPSec ----> 192.168.4.0/24
PfSense------------------------------------------------------------pfSense----------------------------------------Fritzbox
Wie route ich nun von Site A nach Site C und zurück?
Gemacht habe ich: Fritzbox das Netz Site 1 mitgegeben .
Auf der pfSense in Site B in der Phase 2 im IPSec-Tunnel als lokales Netzwerk 192.168.0.0/19 definiert. Da sollten beide drin sein.
Auf dem OVPN-Server in Site B gesetzt:
Geht nicht. Dann auf Site B ein Interface OVPN-Test mit dem ovpns (1) Adapter angelegt. Das legt automatisch ein dynamisches Gateway an und der bekommt
die IP 10.0.8.2. Statische Route gesetzt auf Netz 192.168.22.0/24 über Gateway 10.0.8.2. Regel gesetzt auf dem OVPN-Test Interface "any"
Damit sollte die PfSense auch auf dem IPSec wissen, wohin mit den Päckchen für Site A. Ping vom LAN geht. Tracert auf Site C kommt bis zur Fritte. Dann
Timeouts. laut AVM soll das aber gehen. Mindestens die PfSense Site B sollte hier doch aber antworten?
Nun müsste ich wohl auf Site A an der PfSense evtl. ebenfalls das Interface definieren und die Route einrichten, aber da komme ich aus mir unbekannter
Ursache aus Site B gerade nicht drauf. (pingbar ist sie, das Webinterface antwortet aber nicht) anderes Problem...
Was aktuell geht ist Site A <---> Site B. Site C bleibt ausgesperrt. Momentan geht aber auch ein traceroute von der pfsense B nur bis zum OVPN (10.0.8.2)
der Gegenseite. Also hängts da noch...
Jetzt muss ich aber mal mein "Samstagsprogramm" anfangen.
Ideen sind nachwievor willkommen.
Buc
Tunnel steht und routet auch. War aber ne schwere Geburt...Die Dokumentation ist eher verwirrend. Mal heisst es: "Create an Interface for OpenVPN" in der Standardanleitung, dann heisst es wieder, man muss das
nicht machen.
Mal heisst es, die Routen werden über die Angaben der Subnetze automatisch erzeugt (man kann sie ja auch sehen), mal heisst es "push route" und "route"
und "iroute" in der Advanced Configuaration angeben.
OPNSense will die Advanced Configuration demnächst komplett entfernen, da sie unnötig und "dangerous" sei. Dann muss es ja ohne gehen, aber wie route ich
dann in ein 2. Netz?
Problematisch kann es wohl werden, wenn (wie bei mir) weitere IPSec-Tunnel mit dem lokalen Netz der Serverseite existieren und dann ein OpenVPN
hinzukommt.
Warum das so kompliziert war, weiss der Geier. Werde nochmal ein bisschen rumtesten.
Nun aber die nächste herausforderung:
Site A (OVPN-Client) <--------ovpn ------------------> Site B (OVPN-Server) <---IPSec ----> Site C
192.168.22.0/24 <------>10.0.8.0/24 <----------->192.168.1.0/24 <-----------IPSec ----> 192.168.4.0/24
PfSense------------------------------------------------------------pfSense----------------------------------------Fritzbox
Wie route ich nun von Site A nach Site C und zurück?
Gemacht habe ich: Fritzbox das Netz Site 1 mitgegeben .
accesslist =
"permit ip any 192.168.4.0 255.255.255.0",
"permit ip any 192.168.22.0 255.255.255.0"; Auf der pfSense in Site B in der Phase 2 im IPSec-Tunnel als lokales Netzwerk 192.168.0.0/19 definiert. Da sollten beide drin sein.
Auf dem OVPN-Server in Site B gesetzt:
push "route 192.168.1.0 255.255.255.0" "route 192.168.22.0 255.255.255.0" "iroute 192.168.22.0 255.255.255.0" Geht nicht. Dann auf Site B ein Interface OVPN-Test mit dem ovpns (1) Adapter angelegt. Das legt automatisch ein dynamisches Gateway an und der bekommt
die IP 10.0.8.2. Statische Route gesetzt auf Netz 192.168.22.0/24 über Gateway 10.0.8.2. Regel gesetzt auf dem OVPN-Test Interface "any"
Damit sollte die PfSense auch auf dem IPSec wissen, wohin mit den Päckchen für Site A. Ping vom LAN geht. Tracert auf Site C kommt bis zur Fritte. Dann
Timeouts. laut AVM soll das aber gehen. Mindestens die PfSense Site B sollte hier doch aber antworten?
Nun müsste ich wohl auf Site A an der PfSense evtl. ebenfalls das Interface definieren und die Route einrichten, aber da komme ich aus mir unbekannter
Ursache aus Site B gerade nicht drauf. (pingbar ist sie, das Webinterface antwortet aber nicht) anderes Problem...
Was aktuell geht ist Site A <---> Site B. Site C bleibt ausgesperrt. Momentan geht aber auch ein traceroute von der pfsense B nur bis zum OVPN (10.0.8.2)
der Gegenseite. Also hängts da noch...
Jetzt muss ich aber mal mein "Samstagsprogramm" anfangen.
Ideen sind nachwievor willkommen.
Buc
Tunnel steht und routet auch. War aber ne schwere Geburt...
Alles andere hätte uns hier bei dir als FritzBox und Netzwerk Profi auch sehr gewundert ! 
Die Dokumentation ist eher verwirrend.
Dazu geht der Netzwerk Profi ja auch über die Shell und SSH auf die Firewall und sieht sich mit cat /etc/openvpn/meine.config mal die Konfig an was das GUI dann wirklich daraus gemacht hat ! Mit den Kommandos die da stehen ist dann doch alles glasklar !
weitere IPSec-Tunnel mit dem lokalen Netz der Serverseite existieren und dann ein OpenVPN
Kein Problem !Die alle trägst du dann statisch ein, da die ja über ein weiteres Gateway im Netz erreicht werden. Ggf. musst du dann auch zusätzlich über das Routing Menü machen sollten diese Tunnel NICHT über den Internet Router (Default Gateway der pfSense) erreichbar sein. Vermutlich ist das aber eine kaskadierte FritzBox, richtig ?
Tracert auf Site C kommt bis zur Fritte. Dann Timeouts...
Bedeutet das du die Fritte dann falsch komnfiguriert hast. Dort muss natürlich sowohl das internen OVPN Netz als auch das Zielnetz IPsec technisch eingetragen sein so das die remote FB diese Netze routen kann in den Tunnel !https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publicati ...
aber da komme ich aus mir unbekannter Ursache aus Site B gerade nicht drauf.
Zeigt das du einen Fehler gemacht hast. Normal funktioniert das natürlich fehlerlos !Als Ziel gibt man immer die LAN IP der remoten FW an ! Vermutlich hast du also entweder einen Fehler im Routing gemacht oder du hast vergessen die richtige Firewall Regel für das Tunnel Interface einzurichten ! Eins von beiden kanns nur sein.
Hier wieder die Frage: WAS sagt die Routing Tabelle in deinen pfSensen auf beiden Seiten ??? Dort müssen alle erreichbaren Zielnetze zu sehen sein via Tunnel. Wenn nicht hast du einen Fehler gemacht...
Normal ist so ein Setup in 15 Minuten erledigt und online mit beidseitigem Zugriff.
Was aktuell geht ist Site A <---> Site B. Site C bleibt ausgesperrt.
Was ist "Site C" ??? Oben redest du doch nur von einer Kopplung von nur 2 Sites ?Unser Samstagsprogramm wäre dann die Konfig für dich klickfertig zum Abtippen hier zu machen...
Alles andere hätte uns hier bei dir als FritzBox und Netzwerk Profi auch sehr gewundert !
@the-buccaneer Mit solchen Sprüchen musst Du leben, dafür bekommst Du ja auch eine kompetente Beratung. Die Dokumentation ist eher verwirrend. Mal heisst es: "Create an Interface for OpenVPN" in der Standardanleitung...
Wie sonst willst Du denn eine Firewallregel erstellen, wenn nicht einmal ein Interface eingerichtet ist. Du brauchst das nicht zwingend für jede OpenVPN-Instanz zu tun, wenn Du mehrere Server am laufen hast, da würde ich mitgehen.Im übrigen hat hier niemand behauptet das ein VPN-Tunnel, egal welcher, ein triviales Klikibunti ist, was auf Anhieb funktionieren muss.
Aber das Routing von Tunnel zu Tunnel, sollte auf der pfSense Site-B, auch problemlos zwischen OpenVPN und dem IPSec-Tunnel zu Stite-C funktionieren.
Plan B wäre dann, die Fritte freezen und mit OpenVPN den IPSec ersetzen oder notfalls gleich OpenWRT einsetzen. Dann läuft das Routing auch innerhalb der OpenVPN-config.
Ich denke der einfachere Weg wäre aber, ein ordentliches Routing zwischen den Standorten und das es geht, ist Fakt.
Gruß orcape
Zitat von @orcape:
Der aqui darf das. Hat er sich hart erabeitet. Alles andere hätte uns hier bei dir als FritzBox und Netzwerk Profi auch sehr gewundert !
@the-buccaneer Mit solchen Sprüchen musst Du leben, dafür bekommst Du ja auch eine kompetente Beratung. Muss ja auch Spaß machen, anderer Leute Probleme zu lösen. Die Dokumentation ist eher verwirrend. Mal heisst es: "Create an Interface for OpenVPN" in der Standardanleitung...
Wie sonst willst Du denn eine Firewallregel erstellen, wenn nicht einmal ein Interface eingerichtet ist. Du brauchst das nicht zwingend für jede OpenVPN-Instanz zu tun, wenn Du mehrere Server am laufen hast, da würde ich mitgehen.Im übrigen hat hier niemand behauptet das ein VPN-Tunnel, egal welcher, ein triviales Klikibunti ist, was auf Anhieb funktionieren muss.
Einen Client mit der pfSense als Server verbinden ist das. Da lobe ich mir meinen "Shrew". Da lernt man das zwangsläufig. Aber das Routing von Tunnel zu Tunnel, sollte auf der pfSense Site-B, auch problemlos zwischen OpenVPN und dem IPSec-Tunnel zu Stite-C funktionieren.
Ja... Bei "sollte" bleibe ich ja hängen und frage mich und die Welt, was das sein könnte... Ich sage momentan: "Die doofe Fritte macht das Routing trotz Eintrag nicht"Plan B wäre dann, die Fritte freezen und mit OpenVPN den IPSec ersetzen oder notfalls gleich OpenWRT einsetzen. Dann läuft das Routing auch innerhalb der OpenVPN-config.
No-Go. Meine Fritte ist mir heilig. (U.a. wg. Kindersicherung...)Ich denke der einfachere Weg wäre aber, ein ordentliches Routing zwischen den Standorten und das es geht, ist Fakt.
Aber wie??? Ich kann mir ja auf der Fritte die Routen nicht anzeigen lassen und wg. IPSec ist Standort B ja auch kein verbundenes Interface, womit statische Routen wegfallen...Es interessiert mich auch eher "prinzipiell", da ich gerne wissen möchte, ob das so geht, oder nicht. In 2 Wochen ist beim Kunden ne feste externe IP (so Colt will) geschaltet und dann ist das "konkrete Problem" obsolet.
Und solange hier nicht einer sagt: "Ich habe genau dieses Setting i(Routing über ein FB-->Pfsense IPSec über ein dortiges OVPN in ein remotes Netz im Einsatz und es geht", halte ich alles für "theoriegeleitet"
So. Nun habe ich nach einem Reboot der pfSense auf Site B gar keine Verbindung mehr zu Site A.. OVPN-Log sagt:
Jan 19 01:25:46 openvpn 5401 Expected Remote Options hash (VER=V4): '4db61b8b'
Jan 19 01:25:46 openvpn 5401 Local Options hash (VER=V4): 'e0188310' Super. Dass das stabil und zuverlässig ist, halte ich für ein Gerücht. Ich habe NICHTS verändert.
Gute Nacht.
Buc
Super. Dass das stabil und zuverlässig ist, halte ich für ein Gerücht. Ich habe NICHTS verändert.
Nun, dann hast Du wohl noch einen Fehler eingebaut, keine Frage. Um dabei helfen zu können, sollte man aber über die Einstellungen, Routingtabelle, Logs etc. Kenntnis haben, sonst ist das wie die Suche im Heuhaufen.Das die OpenVPN-Tunnel, Hardware bedingt, teils unterschiedliche Einstellungen erfordern, ist mir klar. Auch sind die Pfadangaben auf die einzelnen Systemdateien teils unterschiedlich, abhängig vom verwendeten OS.
Bei mir laufen auf einer meiner pfSensen gleich 5 OpenVPN-Server und das Routing, auch zwischen diesen Tunnel klappt problemlos.
Leider habe ich einen einst funktionierenden IPSec-Tunnel, der zu einer remoten Fritte 3370 ging, nicht mehr in Verwendung, sonst könnte ich Dir wohl gezielt weiter helfen.
Gruß orcape
Jo, danke orcape!
Sieht so aus, als würde der Client einfach keine Verbindungsversuche mehr unternehmen. Auf dem Server kommt nix an.
Mag was völlig anderes sein, wer weiss. Client steht in nem neuen Bürohaus, wo immer noch an diversen Verkabelungen gearbeitet wird etc.
Evtl. haben die nachts irgendeine Wartung gefahren, so dass der nicht mehr raus kommt, wer weiss. Merkwürdig nur, das es beim Neustart der Serverseite auftrat. (Das verändert nicht die öffentliche IP da Einwahl über andere FB)
Solange hat sich die Sache mit den Routen erstmal erledigt...
Schönen Sonntag!
Buc
Sieht so aus, als würde der Client einfach keine Verbindungsversuche mehr unternehmen. Auf dem Server kommt nix an.
Mag was völlig anderes sein, wer weiss. Client steht in nem neuen Bürohaus, wo immer noch an diversen Verkabelungen gearbeitet wird etc.
Evtl. haben die nachts irgendeine Wartung gefahren, so dass der nicht mehr raus kommt, wer weiss. Merkwürdig nur, das es beim Neustart der Serverseite auftrat. (Das verändert nicht die öffentliche IP da Einwahl über andere FB)
Zitat von @orcape:
Um dabei helfen zu können, sollte man aber über die Einstellungen, Routingtabelle, Logs etc. Kenntnis haben, sonst ist das wie die Suche im Heuhaufen.
Ist schon klar. Hier ist das mit dem Log aber einfach: Keine eingehenden Verbindungsversuche auf dem WAN-Port am Server. Punkt. Client nicht zugänglich. Das wars, bis ich vor Ort sein kann oder den dortigen Admin fragen kann, ob die was umgestellt haben.Um dabei helfen zu können, sollte man aber über die Einstellungen, Routingtabelle, Logs etc. Kenntnis haben, sonst ist das wie die Suche im Heuhaufen.
Solange hat sich die Sache mit den Routen erstmal erledigt...
Schönen Sonntag!
Buc
Sieht so aus, als würde der Client einfach keine Verbindungsversuche mehr unternehmen. Auf dem Server kommt nix an.
Na ja, kann durchaus auch einer den Stecker gezogen haben. Das einfachste ist, die Tests vor Ort zu Hause machen.
Ich gehe bei mir mit den Test-Clients eines neuen Tunnels einfach ins LAN der Fritte, wo auch das WAN der pfSense angeschlossen ist. Wenn der Tunnel steht, kommt erst der remote Teil.
Wenn der Server funktioniert, sagt Dir das die pfSense, dann den Client händisch starten...
openvpn <pfad zur Client.conf>...und die Fehlermeldungen auswerten.
Wie gesagt, trivial sieht anders aus aber was lange währt wird gut.
Schönen Sonntag
Gruß orcape
Vielleicht hilft dies dem Kollegen @the-buccaneer seinen Fehler zu finden ?! Das ist ein simples, in 30 Minuten fertiges Setup und funktioniert absolut fehlerlos wie das nachfolgende Kurztutorial zeigt !
Test Design für die Kopplung pfSense OpenVPN mit IPsec VPN
Der Einfachheit halber wurde hier eine OpenVPN Kopplung der 2 pfSense Firewalls mit Shared Keys verwenden und simpler 128Bit AES Verschlüsselung.
Die Routing Kopplung an ein IPsec VPN Netz ist hier durch ein Mikrotik_IPsec_Site_to_Site_Netz realisiert, was wegen der Vielzahl der Standort IP Netze dynamisches Routing verwendet um die Fehleranfälligkeit vieler statischer Routen und ein automatisiertes Link Backup zu ermöglichen.
Das ist nur ein Beispiel und kann durch jedes andere beliebige IPsec VPN Netz mit statischen Routen ersetzt werden. Punkt ist hier nicht das IPsec VPN sonder das korrekte Routing in dieses Netz bzw. Netze.
1.) Konfiguration des pfSense OVPN Servers:
2.) Eintragen der statischen Routen ins IPsec VPN Netz a.d. OVPN Server:
3.) Konfiguration des pfSense OVPN Clients:
Unter /var/etc/openvpn kann man mit PuTTY Shellzugriff die Konfig des OVPN Clients nochmals checken und ggf. finetunen.
Hier sieht man auch deutlich die remoten IP Netze auf der Serverseite !
4.) Check des OVPN Tunnels:
Ist aktiv und online !
5.) Check ob die OVPN Server Routen richtig in der Routing Tabelle des OVPN Clients sind:
Sind sie !
Damit ist der OpenVPN Tunnel soweit OK und einsatzklar !
Weiter geht es mit dem Koppelrouter Mikrotik RB750GL (hEX R3)...
6.) Konfig der statischen Route OVPN Client Netz a.d. IPsec Koppelrouter (750GL):
Die statische Route ins OVPN Client Netz wird per RIPv2 automatisch ins gesamte IPsec VPN der Mikrotiks distribuiert so das jeder Standort dort das OVPN Client Netz "kennt".
7.) Check ob OVPN Client Netz in den IPsec Standorten bekannt ist:
Ist es !
8.) Ping Check OVPN Client auf Mikrotik IPsec Core Router (RB750GL):
Klappt !
9.) Ping Check OVPN Client auf Mikrotik IPsec Standort Router (RB750):
Klappt !
10.) Ping Mikrotik IPsec Standort Router (RB750) auf OVPN Client:
Klappt !
Fertisch... !
Ein Web Zugriff auf das GUI sowohl des pfSense Servers und Clients aus allen IP Netzen funktioniert fehlerlos !
Fazit: Works as designed und auch ein stolzer Freibeuter kann sich jetzt nicht mehr rausreden !!
Test Design für die Kopplung pfSense OpenVPN mit IPsec VPN
Die Routing Kopplung an ein IPsec VPN Netz ist hier durch ein Mikrotik_IPsec_Site_to_Site_Netz realisiert, was wegen der Vielzahl der Standort IP Netze dynamisches Routing verwendet um die Fehleranfälligkeit vieler statischer Routen und ein automatisiertes Link Backup zu ermöglichen.
Das ist nur ein Beispiel und kann durch jedes andere beliebige IPsec VPN Netz mit statischen Routen ersetzt werden. Punkt ist hier nicht das IPsec VPN sonder das korrekte Routing in dieses Netz bzw. Netze.
1.) Konfiguration des pfSense OVPN Servers:
2.) Eintragen der statischen Routen ins IPsec VPN Netz a.d. OVPN Server:
3.) Konfiguration des pfSense OVPN Clients:
[2.3.5-RELEASE][admin@pfsense.intern]/var/etc/openvpn: cat client1.conf
dev ovpnc1
verb 3
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA256
auth-nocache
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local 10.1.1.149
lport 0
management /var/etc/openvpn/client1.sock unix
remote 10.99.1.99 1194
ifconfig 172.222.222.2 172.222.222.1
route 192.168.1.0 255.255.255.0
route 192.168.188.0 255.255.255.0
route 172.16.88.0 255.255.255.0
route 192.168.199.0 255.255.255.0
route 192.168.99.0 255.255.255.0
secret /var/etc/openvpn/client1.secret
comp-lzo no
resolv-retry infinite 4.) Check des OVPN Tunnels:
5.) Check ob die OVPN Server Routen richtig in der Routing Tabelle des OVPN Clients sind:
Damit ist der OpenVPN Tunnel soweit OK und einsatzklar !
Weiter geht es mit dem Koppelrouter Mikrotik RB750GL (hEX R3)...
6.) Konfig der statischen Route OVPN Client Netz a.d. IPsec Koppelrouter (750GL):
7.) Check ob OVPN Client Netz in den IPsec Standorten bekannt ist:
8.) Ping Check OVPN Client auf Mikrotik IPsec Core Router (RB750GL):
9.) Ping Check OVPN Client auf Mikrotik IPsec Standort Router (RB750):
10.) Ping Mikrotik IPsec Standort Router (RB750) auf OVPN Client:
Fertisch... !
Ein Web Zugriff auf das GUI sowohl des pfSense Servers und Clients aus allen IP Netzen funktioniert fehlerlos !
Fazit: Works as designed und auch ein stolzer Freibeuter kann sich jetzt nicht mehr rausreden !!
@aqui: Du bist ein Held!
Ein kleiner Fehler hat sich eingeschlichen: In der OVPN Client Config muss es heissen WAN-IP OVPN Server.
Das wird sicher wieder viel gelesen und sorgt sonst für Verwirrung...
Trotzdem habe ich noch 1-2 Verständnisfragen...
In der OVPN Server Config tauchen folgende Routen auf:
Wo hast du die definiert? Der Schritt fehlt. (Ich gehe davon aus, in der "Advanced Configuration" mit "route " und push "route" ?)
Wie genau? Das ist hier wichtig.
Als Gateway hast du bei den Static Routes die LAN-IP des OVPN-Servers für alle (IPSec-) verbundenen Netze angegeben.
Hier unterscheidet sich dein Setup aber von dem meinen, da du noch einen Mikrotik fürs IPSec dazwischen schaltest und das nicht die PfSense selber macht...
Ich ging erst davon aus, dass die PfSense den Traffic aus den IPSec Remote-Netzen schon routen kann, denn die Netze kommunizieren ja, und sie weiss offenbar, dass sie die Pakete fürs IPSec VPN-Netz auch dorthin routen muss.
Langsam versteh ich's aber... Das LAN-interface der pfSense kennt die remoten Netze automatisch wg. IPSec. Keine Routen nötig. Das OpenVPN-Interface weiss ja aber nix davon. Was soll es tun? Es schickt die Pakete zum Standardgateway. Dahinter ist aber meist das Internet und der Providerrouter denkt sich: "Wo soll ich hin mit dem Zeug? Kenn wa nich, ham wa nich, ab in die Tonne."
Das ist halt so ne IPSec-Sache mit dem Routing ohne explizite Routen die auch anderen Interfaces zur Verfügung stünden, wie man das sonst gewohnt ist...
Lange Rede, kurzer Sinn: Wie ich es nun verstehe, lege ich in der pfSense einen Gateway "IPSec-VPN" an, der auf das LAN Interface des IPSec-Tunnels verweist. Dann setze ich eine statische Route für alle per IPSec verbundenen Netze, die ich anderen Interfaces (z.B. OpenVPN) zur Verfügung stellen möchte. Klingt logisch und einfach. Funktioniert aber wieder nicht.
Sollte die Schwierigkeit darin liegen, dass sowohl IPSec als auch OpenVPN auf der pfSense liegen, hast du das elegant umschifft, indem du den Mikrotik das IPSec machen lässt.
Ich bekomme es nachwievor nicht hin. Gateway angelegt LAN 1. Route gesetzt VPN-Netz hinter FB --> Gateway LAN1. In der Phase 2 des IPSec das OpenVPN Tunnelnetz hinterlegt, das Netz hinter dem OVPN ebenfalls. etc.pp. Die pfSense routet keinen Traffic aus dem OVPN-netz.
Testweise ein weiteres Netz angelegt: pfsense-interface2 192.168.10.0/24. PHYSIKALISCHER Adapter auf der pfSense. Route mitgegeben auf der FB und in der Phase 2 der pfSense. Klappt wie gewünscht.
Also definitiv irgendwas mit dem Routing aus dem OVPN-Interface (sowohl das automatisch erstellte "OVPN-Server", als auch das manuelle "OVPN".) ins IPSec.
Herzallerliebster aqui!
Solltest du die Zeit finden und die Herausforderung annehmen:
Versuche doch mal, das mit OVPN und IPSec auf derselben pfSense abzubilden.Wozu Mikrotik dazwischen? Die Lösung wäre Gold wert, und mir definitiv einen Kasten gutes ayrisches Bier, wenn du mir die Post-IP für's "Real-World-Routing" zukommen lässt...
Buc
Ein kleiner Fehler hat sich eingeschlichen: In der OVPN Client Config muss es heissen WAN-IP OVPN Server.
Das wird sicher wieder viel gelesen und sorgt sonst für Verwirrung...
Trotzdem habe ich noch 1-2 Verständnisfragen...
In der OVPN Server Config tauchen folgende Routen auf:
route 192.168.1.0 255.255.255.0
route 192.168.188.0 255.255.255.0
route 172.16.88.0 255.255.255.0
route 192.168.199.0 255.255.255.0
route 192.168.99.0 255.255.255.0Wo hast du die definiert? Der Schritt fehlt. (Ich gehe davon aus, in der "Advanced Configuration" mit "route " und push "route" ?)
Wie genau? Das ist hier wichtig.
Als Gateway hast du bei den Static Routes die LAN-IP des OVPN-Servers für alle (IPSec-) verbundenen Netze angegeben.
Hier unterscheidet sich dein Setup aber von dem meinen, da du noch einen Mikrotik fürs IPSec dazwischen schaltest und das nicht die PfSense selber macht...
Ich ging erst davon aus, dass die PfSense den Traffic aus den IPSec Remote-Netzen schon routen kann, denn die Netze kommunizieren ja, und sie weiss offenbar, dass sie die Pakete fürs IPSec VPN-Netz auch dorthin routen muss.
Langsam versteh ich's aber... Das LAN-interface der pfSense kennt die remoten Netze automatisch wg. IPSec. Keine Routen nötig. Das OpenVPN-Interface weiss ja aber nix davon. Was soll es tun? Es schickt die Pakete zum Standardgateway. Dahinter ist aber meist das Internet und der Providerrouter denkt sich: "Wo soll ich hin mit dem Zeug? Kenn wa nich, ham wa nich, ab in die Tonne."
Das ist halt so ne IPSec-Sache mit dem Routing ohne explizite Routen die auch anderen Interfaces zur Verfügung stünden, wie man das sonst gewohnt ist...
Lange Rede, kurzer Sinn: Wie ich es nun verstehe, lege ich in der pfSense einen Gateway "IPSec-VPN" an, der auf das LAN Interface des IPSec-Tunnels verweist. Dann setze ich eine statische Route für alle per IPSec verbundenen Netze, die ich anderen Interfaces (z.B. OpenVPN) zur Verfügung stellen möchte. Klingt logisch und einfach. Funktioniert aber wieder nicht.
Sollte die Schwierigkeit darin liegen, dass sowohl IPSec als auch OpenVPN auf der pfSense liegen, hast du das elegant umschifft, indem du den Mikrotik das IPSec machen lässt.
Ich bekomme es nachwievor nicht hin. Gateway angelegt LAN 1. Route gesetzt VPN-Netz hinter FB --> Gateway LAN1. In der Phase 2 des IPSec das OpenVPN Tunnelnetz hinterlegt, das Netz hinter dem OVPN ebenfalls. etc.pp. Die pfSense routet keinen Traffic aus dem OVPN-netz.
Testweise ein weiteres Netz angelegt: pfsense-interface2 192.168.10.0/24. PHYSIKALISCHER Adapter auf der pfSense. Route mitgegeben auf der FB und in der Phase 2 der pfSense. Klappt wie gewünscht.
Also definitiv irgendwas mit dem Routing aus dem OVPN-Interface (sowohl das automatisch erstellte "OVPN-Server", als auch das manuelle "OVPN".) ins IPSec.
Herzallerliebster aqui!
Solltest du die Zeit finden und die Herausforderung annehmen:
Versuche doch mal, das mit OVPN und IPSec auf derselben pfSense abzubilden.Wozu Mikrotik dazwischen? Die Lösung wäre Gold wert, und mir definitiv einen Kasten gutes ayrisches Bier, wenn du mir die Post-IP für's "Real-World-Routing" zukommen lässt...
Buc
Ein kleiner Fehler hat sich eingeschlichen: In der OVPN Client Config muss es heissen WAN-IP OVPN Server.
Du hast Recht ! Ist korrigiert....Zu deinen Fragen:
Wo hast du die definiert? Der Schritt fehlt.
Nein er fehlt nicht. Augen auf... Punkt 3, Drittes Bild Dort ist sogar noch ganz fett in rot markiert: Remote IP Netze auf der Server Seite (Mikrotik IP Netze) Wer lesen kann !!
Als Gateway hast du bei den Static Routes die LAN-IP des OVPN-Servers für alle (IPSec-) verbundenen Netze angegeben.
Nein !Auch hier hast du wohl wieder Tomaten auf den Augen gehabt !
Die pfSense IP (OVPN Server) des LAN ist 192.168.188.149 ! Die statischen Routen verweisen, wie es richtig ist, auf die IP Adresse des Mikrotik RB750GL Routers in diesem Netz 192.168.188.1 denn das ist ja das Next Hop Gateway !
da du noch einen Mikrotik fürs IPSec dazwischen schaltest und das nicht die PfSense selber macht...
Das hattest du oben nicht gesagt. Deinen Ausführungen war zu vermuten das das IPsec Netz separat mit FritzBox usw. gemacht wird. Aber egal...das Design können wir auch noch umstellen das die auch auf der pfSense abgefrühstückt werden.Das macht das ganze Setup dann noch viel einfacher.
Ich ging erst davon aus, dass die PfSense den Traffic aus den IPSec Remote-Netzen schon routen kann
Das kann sie auch ! Aber rein nur für IPsec. OpenVPN muss man diese Netze beibringen das die in den OVPN Tunnel geroutet werden. Zudem musst du dann auch in der IPsec Konfig das remote OVPN Netz bekannt machen.Das LAN-interface der pfSense kennt die remoten Netze automatisch wg. IPSec. Keine Routen nötig.
Richtig !Das OpenVPN-Interface weiss ja aber nix davon. Was soll es tun? Es schickt die Pakete zum Standardgateway.
Richtig !Beides sind 2 unterschiedliche Prozesse. Du musst die OVPN IP Netze dem IPsec bekannt machen und vice versa, damit diese IP Netze ALLE in der Routing Tabelle der pfSense global vorhanden sind.
Das ist halt so ne IPSec-Sache mit dem Routing ohne explizite Routen die auch anderen Interfaces zur Verfügung stünden,
Mmmhhh..das ist bei allen VPN Protokollen so. Bei IPsec machst du die Routen in der Phase 2 SA bekannt und bei OVPN über die Server bzw. Client Konfig. Im Endeffekt müssen sie immer irgendwo angegeben werden !Genau DAS war der Grund das nicht immer statisch zu machen sondern im oben zitierten Tutorial mit einem dynamischen Routing Protokoll was alle diese Routen dann automatisch und ohne manuelle Frickelei an die Standort Clients distribuiert. Ob man da dann RIPv2 oder OSPF nimmt ist dann eher eine kosmetische Frage.
Wie ich es nun verstehe, lege ich in der pfSense einen Gateway "IPSec-VPN" an, der auf das LAN Interface des IPSec-Tunnels verweist.
Nein ! Das ist falsch. Liegt wohl daran das du die Antwort oben missverstanden hast.hast du das elegant umschifft, indem du den Mikrotik das IPSec machen lässt.
Nöö, das war Faulheit, weil das MT IPsec Netz hier schon fix und fertig lief. Nur um das "Samstagprogramm" nicht so ausufern zu lassen das mit OVPN und IPSec auf derselben pfSense abzubilden.
Auch noch ein "Montagsprogramm" ?! Das kostet aber. Da muss der Freibeuter dann aber seine Sonntags Rum Buddel für öffnen. Unter Ron Zapaca oder A.H.Rise ist das nicht zu machen... Und...du musst ein Tutorial davon schreiben.
Und überhaupt... was ist denn "ayrisches Bier" ? Klingt gruselig.
@the-buccaneer
Denn was dort steht, ist nicht die Server, sondern die Client.config der Site A-pfSense und dessen remote Netzeinträge.
Wie das aqui schon richtig definiert hat.
Du solltest übrigens nicht nur darauf bestehen das er "ayrisches Bier" ausgibt, das "B"sollte noch drin sein.
Trotzdem habe ich noch 1-2 Verständnisfragen...
...und mit dem nächsten Satz, hast Du auch mein Verständnis in Frage gestellt. In der OVPN Server Config tauchen folgende Routen auf:
route 192.168.1.0 255.255.255.0
route 192.168.188.0 255.255.255.0
route 172.16.88.0 255.255.255.0
route 192.168.199.0 255.255.255.0
route 192.168.99.0 255.255.255.0Wo hast du die definiert? Der Schritt fehlt. (Ich gehe davon aus, in der "Advanced Configuration" mit "route " und push "route" ?)
Wie genau? Das ist hier wichtig.
Wie genau? Das ist hier wichtig.
Denn was dort steht, ist nicht die Server, sondern die Client.config der Site A-pfSense und dessen remote Netzeinträge.
Wie das aqui schon richtig definiert hat.
Unter /var/etc/openvpn kann man mit PuTTY Shellzugriff die Konfig des OVPN Clients nochmals checken und ggf. finetunen.
Punkt 3, Drittes Bild Dort ist sogar noch ganz fett in rot markiert: Remote IP Netze auf der Server Seite (Mikrotik IP Netze)
@aquiPunkt 3, Drittes Bild Dort ist sogar noch ganz fett in rot markiert: Remote IP Netze auf der Server Seite (Mikrotik IP Netze)
Du solltest übrigens nicht nur darauf bestehen das er "ayrisches Bier" ausgibt, das "B"sollte noch drin sein.
@orcape
Wie unter Freibeutern üblich sollte es besser ein Rum sein oder ein Cuba libre !
So auf besonderen Wunsch eines besonderen Freibeuters ! Das "Montagsprogramm"...
Test Design wie vom Buccaneer vorgegeben:
Als Beispiel nur eine IPsec Tunnel Verbindung, die mit einem Mikrotik Router als Gegenpart rennt. IKEv1 wurde bewusst gewählt weil die FritzBox nur IPKEv1 kann und Kollege @the-buccaneer ja FritzBox Fan ist. Die IPsec Konfig rennt aber genau so auch unter IKEv2.
1.) OpenVPN Client Konfig anpassen:
Die komplette OVPN Server Konfig und auch die Grundkonfig des OVPN Client bleibt so wie oben nur die remoten IP Netze müssen im Client angepasst werden !
2.) Einrichten der pfSense IPsec Verbindung (Phase 1):
3.) Einrichten der Phase 2 zum o.a. IPsec Tunnel:
Die Phase 2 bestimmt immer WELCHER IP Traffic in den VPN Tunnel geschickt wird. Es sollte klar sein, das dazu natürlich auch der Traffic des OpenVPN Client LANs in das IPsec LAN gehört das über die pfSense gesendet wird !
Zweiter ! Phase 2 Eintrag für OpenVPN LAN und remotes LAN:
Die fertige IPsec Tunnel Konfig auf dem Server sieht dann so aus:
Fertig....
Weiter geht es mit dem Mikrotik IPsec Router am remoten Standort:
4.) Konfiguration IPsec Tunnel Mikrotik (Phase 1):
Peer IPs, Phase 1 Krypto Parameter, Passwort.
5.) Konfiguration IPsec Tunnel Mikrotik (Phase 2):
Hier werden genau wie im pfSense Server die zwei Phase 2 Netze eingetragen und die P2 Krypto Parameter.
6.) Wir wollen KEIN NAT auf den internen VPN IP Netzen !!! (nur Mikrotik):
Wichtig bei Mikrotik !!:
Der VPN Tunnel Traffic auf dem Mikrotik muss zwingend vom NAT ausgenommen werden in der Firewall, ansonsten kann man nicht beidseitig routen im VPN. (Die pfSense macht glücklicherweise generell KEIN NAT im VPN Tunnel !)
7.) Check des IPsec Session Status auf der pfSense:
Im obigen Bild konnte man auf dem Mikrotik schon sehen das die beiden SA erfolgreich established wurden was wir jetzt auch auf der pfSense erwarten:
Dem ist so !
Entsprechend zeigt uns das Dashboard der pfSense das beide VPN Tunnel OpenVPN und auch IPsec sauber aufgebaut sind und funktionieren:
8.) Finaler Ping Check zwichen lokalem LAN Mikrotik und lokalem LAN OpenVPN Client:
pfSense OpenVPN Client (LAN3 ist aktives Interface !)
Klappt !!!
Mikrotik:
Klappt !!!
Fazit:
Works as designed !
So, und nun muss der Freibeuter aber den Rum rausrücken !!
Wie unter Freibeutern üblich sollte es besser ein Rum sein oder ein Cuba libre !
So auf besonderen Wunsch eines besonderen Freibeuters ! Das "Montagsprogramm"...
Test Design wie vom Buccaneer vorgegeben:
Als Beispiel nur eine IPsec Tunnel Verbindung, die mit einem Mikrotik Router als Gegenpart rennt. IKEv1 wurde bewusst gewählt weil die FritzBox nur IPKEv1 kann und Kollege @the-buccaneer ja FritzBox Fan ist. Die IPsec Konfig rennt aber genau so auch unter IKEv2.
1.) OpenVPN Client Konfig anpassen:
Die komplette OVPN Server Konfig und auch die Grundkonfig des OVPN Client bleibt so wie oben nur die remoten IP Netze müssen im Client angepasst werden !
2.) Einrichten der pfSense IPsec Verbindung (Phase 1):
3.) Einrichten der Phase 2 zum o.a. IPsec Tunnel:
Die Phase 2 bestimmt immer WELCHER IP Traffic in den VPN Tunnel geschickt wird. Es sollte klar sein, das dazu natürlich auch der Traffic des OpenVPN Client LANs in das IPsec LAN gehört das über die pfSense gesendet wird !
- 1. Phase 2: Traffic LAN zu Mikrotik LAN = 192.168.1.0 /24 <-> 192.168.88.0 /24
- 2. Phase 2: Traffic OVPN LAN zu Mikrotik LAN = 172.17.1.0 /24 <-> 192.168.88.0 /24
Weiter geht es mit dem Mikrotik IPsec Router am remoten Standort:
4.) Konfiguration IPsec Tunnel Mikrotik (Phase 1):
Peer IPs, Phase 1 Krypto Parameter, Passwort.
5.) Konfiguration IPsec Tunnel Mikrotik (Phase 2):
Hier werden genau wie im pfSense Server die zwei Phase 2 Netze eingetragen und die P2 Krypto Parameter.
6.) Wir wollen KEIN NAT auf den internen VPN IP Netzen !!! (nur Mikrotik):
Wichtig bei Mikrotik !!:
Der VPN Tunnel Traffic auf dem Mikrotik muss zwingend vom NAT ausgenommen werden in der Firewall, ansonsten kann man nicht beidseitig routen im VPN. (Die pfSense macht glücklicherweise generell KEIN NAT im VPN Tunnel !)
7.) Check des IPsec Session Status auf der pfSense:
Im obigen Bild konnte man auf dem Mikrotik schon sehen das die beiden SA erfolgreich established wurden was wir jetzt auch auf der pfSense erwarten:
Entsprechend zeigt uns das Dashboard der pfSense das beide VPN Tunnel OpenVPN und auch IPsec sauber aufgebaut sind und funktionieren:
8.) Finaler Ping Check zwichen lokalem LAN Mikrotik und lokalem LAN OpenVPN Client:
pfSense OpenVPN Client (LAN3 ist aktives Interface !)
Mikrotik:
Fazit:
Works as designed !
So, und nun muss der Freibeuter aber den Rum rausrücken !!
Wie unter Freibeutern üblich sollte es besser ein Rum sein oder ein Cuba libre !
Den Cuba aber selber mischen und je nach Art des Rums. Denn bedenke, wenn er Dir 75% igen Rum liefert kann das "tödlich" enden.
Nee, nee da hast du recht. 75% ist gruselig stark und gehört da nicht rein. Das Zeug ist für die Mannschaft aber nicht für den Captain !
Vorneweg: nachdem ich nun gar nicht mehr auf die neue pfSense kam und feststellen musste, dass sie gruselige Fehler bzgl. Swapspace produzierte, habe ich sie nochmal aufgesetzt und damit auch den Tunnel nochmal eingerichtet. Läuft natürlich. War ja auch vorher eigentlich schon soweit...
WARNUNG: Es ist keine gute Idee, einen Snort zu installieren und gleichzeitig die Kiste auf RAMdisk umzustellen. Der Snort (den habe ich im Verdacht) frisst bei manchen Aktionen (Updates?) ordentlich Speicher, auch wenn er sonst im Betrieb recht genügsam ist.
Auch hier hast du wohl wieder Tomaten auf den Augen gehabt !
Doch! Oder ich verstehe deine Netzwerkgrafik nicht. Da hat doch die pfSense die IP 192.168.188.1 und der Mikrotik die .149 ????
Sonst wär ich ja nicht auf die Idee verfallen, der PfSense ihr IPSec-Netz nochmal auf der eigenen LAN-IP zu verklickern...
Das macht das ganze Setup dann noch viel einfacher.
Bäääh.
Beides sind 2 unterschiedliche Prozesse. Du musst die OVPN IP Netze dem IPsec bekannt machen und vice versa, damit diese IP Netze ALLE in der Routing Tabelle der pfSense global vorhanden sind.
Nu hab ich's ja gerafft... Essentiell ist hier das händische Anlegen eines OVPN-Interfaces auf Server-Seite und das Setzen einer statischen Route für das hinter dem OVPN liegenden Netz.
Genau DAS war der Grund das nicht immer statisch zu machen sondern im oben zitierten Tutorial mit einem dynamischen Routing Protokoll was alle diese Routen dann automatisch und ohne manuelle Frickelei an die Standort Clients distribuiert. Ob man da dann RIPv2 oder OSPF nimmt ist dann eher eine kosmetische Frage.
Klar. trotz allem frage ich mich noch, wie es sein konnte, dass trotz vorhandener Routen immer nix ankam. (LAN-IP-Server --> OVPN-IP-Client)
Och, ist doch eh Schmuddelwetter draussen...
Sach an wohin.
Dann schmeckt das wieder exzellent.
@aqui: Du hast was gut bei mir!
@orcape: Wo du Recht hast...
WARNUNG: Es ist keine gute Idee, einen Snort zu installieren und gleichzeitig die Kiste auf RAMdisk umzustellen.
Der Snort (den habe ich im Verdacht) frisst bei manchen Aktionen (Updates?) ordentlich Speicher, auch wenn er sonst im Betrieb recht genügsam ist. Zu deinen Fragen:
Punkt 3, Drittes Bild Dort ist sogar noch ganz fett in rot markiert: Remote IP Netze auf der Server Seite (Mikrotik IP Netze)
Wer lesen kann !!
O.k. Eingesehen. "Client....Server.... ist eh alles Hähnchen" sagt das Känguruh. Wo hast du die definiert? Der Schritt fehlt.
Nein er fehlt nicht. Augen auf... Punkt 3, Drittes Bild Dort ist sogar noch ganz fett in rot markiert: Remote IP Netze auf der Server Seite (Mikrotik IP Netze) Wer lesen kann !!
Als Gateway hast du bei den Static Routes die LAN-IP des OVPN-Servers für alle (IPSec-) verbundenen Netze angegeben.
Nein !Auch hier hast du wohl wieder Tomaten auf den Augen gehabt !
Die pfSense IP (OVPN Server) des LAN ist 192.168.188.149 ! Die statischen Routen verweisen, wie es richtig ist, auf die IP Adresse des Mikrotik RB750GL Routers in diesem Netz 192.168.188.1 denn das ist ja das Next Hop Gateway !
Dann verstehe sogar ich das, aber auf dem 1. Bild... Sonst wär ich ja nicht auf die Idee verfallen, der PfSense ihr IPSec-Netz nochmal auf der eigenen LAN-IP zu verklickern...da du noch einen Mikrotik fürs IPSec dazwischen schaltest und das nicht die PfSense selber macht...
Das hattest du oben nicht gesagt. Deinen Ausführungen war zu vermuten das das IPsec Netz separat mit FritzBox usw. gemacht wird. Aber egal...das Design können wir auch noch umstellen das die auch auf der pfSense abgefrühstückt werden.Das macht das ganze Setup dann noch viel einfacher.
Ich ging erst davon aus, dass die PfSense den Traffic aus den IPSec Remote-Netzen schon routen kann
Das kann sie auch ! Aber rein nur für IPsec. OpenVPN muss man diese Netze beibringen das die in den OVPN Tunnel geroutet werden. Zudem musst du dann auch in der IPsec Konfig das remote OVPN Netz bekannt machen.Das LAN-interface der pfSense kennt die remoten Netze automatisch wg. IPSec. Keine Routen nötig.
Richtig !Das OpenVPN-Interface weiss ja aber nix davon. Was soll es tun? Es schickt die Pakete zum Standardgateway.
Richtig !Beides sind 2 unterschiedliche Prozesse. Du musst die OVPN IP Netze dem IPsec bekannt machen und vice versa, damit diese IP Netze ALLE in der Routing Tabelle der pfSense global vorhanden sind.
Das ist halt so ne IPSec-Sache mit dem Routing ohne explizite Routen die auch anderen Interfaces zur Verfügung stünden,
Mmmhhh..das ist bei allen VPN Protokollen so. Bei IPsec machst du die Routen in der Phase 2 SA bekannt und bei OVPN über die Server bzw. Client Konfig. Im Endeffekt müssen sie immer irgendwo angegeben werden !Genau DAS war der Grund das nicht immer statisch zu machen sondern im oben zitierten Tutorial mit einem dynamischen Routing Protokoll was alle diese Routen dann automatisch und ohne manuelle Frickelei an die Standort Clients distribuiert. Ob man da dann RIPv2 oder OSPF nimmt ist dann eher eine kosmetische Frage.
Wie ich es nun verstehe, lege ich in der pfSense einen Gateway "IPSec-VPN" an, der auf das LAN Interface des IPSec-Tunnels verweist.
Nein ! Das ist falsch. Liegt wohl daran das du die Antwort oben missverstanden hast.hast du das elegant umschifft, indem du den Mikrotik das IPSec machen lässt.
Nöö, das war Faulheit, weil das MT IPsec Netz hier schon fix und fertig lief. Nur um das "Samstagprogramm" nicht so ausufern zu lassen das mit OVPN und IPSec auf derselben pfSense abzubilden.
Auch noch ein "Montagsprogramm" ?! Das kostet aber. Da muss der Freibeuter dann aber seine Sonntags Rum Buddel für öffnen. Unter Ron Zapaca oder A.H.Rise ist das nicht zu machen... Und...du musst ein Tutorial davon schreiben.
Eher nen Erfahrungsbericht: "Wie ich es mit aqui's umfassender Expertise und seinem unendlichen Langmut geschafft habe, ein OVPN in ein IPSec zu tunneln." Und überhaupt... was ist denn "ayrisches Bier" ? Klingt gruselig.
Darfst noch ein "B" kaufen... Dann schmeckt das wieder exzellent. @aqui: Du hast was gut bei mir!
@orcape: Wo du Recht hast...
Zitat von @aqui:
So auf besonderen Wunsch eines besonderen Freibeuters ! Das "Montagsprogramm"...
Test Design wie vom Buccaneer vorgegeben:
Als Beispiel nur eine IPsec Tunnel Verbindung, die mit einem Mikrotik Router als Gegenpart rennt. IKEv1 wurde bewusst gewählt weil die FritzBox nur IPKEv1 kann und Kollege @the-buccaneer ja FritzBox Fan ist. Die IPsec Konfig rennt aber genau so auch unter IKEv2.
So auf besonderen Wunsch eines besonderen Freibeuters ! Das "Montagsprogramm"...
Test Design wie vom Buccaneer vorgegeben:
Als Beispiel nur eine IPsec Tunnel Verbindung, die mit einem Mikrotik Router als Gegenpart rennt. IKEv1 wurde bewusst gewählt weil die FritzBox nur IPKEv1 kann und Kollege @the-buccaneer ja FritzBox Fan ist. Die IPsec Konfig rennt aber genau so auch unter IKEv2.
Sprachlos... Mir bleibt die Spucke weg...
Zu meiner Ehrenrettung möchte ich aber erwähnen, dass ich den Tunnel (MIT Routing) in völliger Unkenntnis dieses "Spezialbeitrags" gestern Abend zeitgleich bereits eingerichtet hatte.
Möge es noch vielen Anderen von Nutzen sein, die auf hoher See zwischen den Kontinenten der Protokolle und Ranges dahinschippern und statt in Indien in Mittelamerika landen...
So, und nun muss der Freibeuter aber den Rum rausrücken !!
Ich trink schon mal einen auf dich!
@orcape: Keine Angst, für den "Herrn der Netze" nur das Beste in verträglicher Mischung. Der wird noch gebraucht. Sollte man nix riskieren.
Hochachtungsvoll!
Buc
Oder ich verstehe deine Netzwerkgrafik nicht.
Du hast Recht ! Sorry, Cut and Paste Fehler. Das muss natürlich die .149 sein ! Ist oben korrigiert !Essentiell ist hier das händische Anlegen eines OVPN-Interfaces auf Server-Seite
händisches Anlegen ??? Nein ! Was soll das sein ?Sowie du den OVPN Server konfiguriert hast wird das OVPN Interface doch automatisch hinzugefügt. Oder was meintest du da genau ?? Das ist übrigens auch beim Client so auf der pfSense.
Keine Ahnung was du da machst oder damit meinst. Sowas muss man jedenfalls nicht machen.
Das setzen der statischen Route muss man natürlich einzig nur im ersten Design machen wo IPsec auf einem getrennten Router gemacht wird. Natürlich NICHT auf deinem 2ten Design wo OVPN und IPsec auf der pfSense koexistieren !
Eher nen Erfahrungsbericht: "Wie ich es..."
👍Ich hoffe dein "Doppel VPN" rennt nun fehlerfrei so wie du es geplant hast ??
Wenn ja, können wir den Case ja dann schliessen.
Super das es läuft.
Ich habe mir da vor ein paar Tagen eine Aufgabe gestellt, bei der ich nun wieder einmal an meiner Grenzen stosse.
Vielleicht kann mir ja der Netzwerk-Profi oder der "Frittenspezialist" mal unter die berüchtigten Arme greifen.
Ich mach mal einen neuen Thread auf..."Fritz!Box3370 mit OpenWRT Interface-Zuordnung".
Gruß orcape
Ich habe mir da vor ein paar Tagen eine Aufgabe gestellt, bei der ich nun wieder einmal an meiner Grenzen stosse.
Vielleicht kann mir ja der Netzwerk-Profi oder der "Frittenspezialist" mal unter die berüchtigten Arme greifen.
Ich mach mal einen neuen Thread auf..."Fritz!Box3370 mit OpenWRT Interface-Zuordnung".
Gruß orcape
