Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?
-
Ah ok. Dann ist das defintiv die bessere Lösung.
Der OpenVPN Server auf dem pfSense kann aber aktiv bleiben?
Weil ich mich mit dem direkt verbinden könnte, an Orten wo ich IPv6 zur Verfügung hätte.
Den "Proxy" brauch ich ja nur an Orten wo ich nur IPv4 habe.
Ich richte gerade ein vserver u. OpenVPN ein.
Und danach einfach pfSense als Client + anderer Client verbinden (und die inter-client-communication aktivieren) und es läuft? Das wäre ja sehr einfach :-)
-
OK ich verstehe den Titel schon nicht, die Beschreibung wird bei mir nicht besser.
Du willst einen vServer mieten und mit diesem eine v4 (und möglichst auch ne v6!). Und was dann? Was willst du wie erreichen und wohin? Das ist mir hierbei noch nicht wirklich klar?
-
Da mein Anschluß zu Hause nur IPv6 anbietet, können Clienten außerhalb sich nur mit dem VPN verbinden, wenn die ebenfalls IPv6 sprechen können.
Das ist soweit auch nicht schlimm, da 99% ich mich nur an Orte befinde, wo IPv6 existiert.
Jedoch kann es natürlich zu der Situation kommen, wo man an einem Anschluß sitzt, der nur IPv4 beherrscht (oder so konfiguriert wurde).
Und schon kann ich mich dann nicht mehr mit mein VPN verbinden.
Daher brauche ich einen "Proxy" bzw "Zwischenstation" der beides sprechen kann. IPv4 u. IPv6.
Und dafür gibt es Anbieter wie feste-ip.net. Die einem ein angepasstes raspberry-pi (bzw die Software darauf) anbieten. Oder andere Lösungen.
-
@Krautsalatmission ,
ja, im Grunde ist es so einfach! Wenn es nicht auf anhieb funktioniert, dann fällt das wohl unter Feintuning. Firewallports richtig setzen, ggf. MTUs anpassen und natürlich die für dieses Szenario richtige VPN-Server Konfiguration. Eine Google-Recherche zu site-to-site OpenVPN bringt da sicher ein paar nützliche Tips, da du ja zum Beispiel keine default Route pushen willst sondern nur bestimmte Netzbereiche.
Und es können auch mehrere OpenVPN-Instanzen auf dem selben Gerät parallel betrieben werden. Bei Server-Instanzen muss man nur jeder Instanz einen eigenen Port zuweisen. Clients suchen sich in der Regel automatisch einen freien Port. Die Anzahl der Instanzen wird effektiv wohl nur durch die Hardware limitiert, da für jede Instanz durchaus etwas Rechenpower nötig ist.Ich habe meinen vServer so konfiguriert, dass er den Tunnel mit der pfSense aufbaut und seine zweite öffentliche IPv4 über den Tunnel an die pfSense weiterleitet. So habe ich eine feste öffentliche IPv4 auf meiner pfSense, die über den Tunnel mit dem Internet verbunden ist. Meine Clients nutzen dann diese IP, um sich direkt auf den VPN-Server auf der pfSense zu verbinden. (Als Hinweis, was sonst noch machbar wäre.)
-
@Krautsalatmission said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:
Da mein Anschluß zu Hause nur IPv6 anbietet, können Clienten außerhalb sich nur mit dem VPN verbinden, wenn die ebenfalls IPv6 sprechen können.
Aye.
Das ist soweit auch nicht schlimm, da 99% ich mich nur an Orte befinde, wo IPv6 existiert.
Du Glücklicher ;)
Jedoch kann es natürlich zu der Situation kommen, wo man an einem Anschluß sitzt, der nur IPv4 beherrscht (oder so konfiguriert wurde).
Und schon kann ich mich dann nicht mehr mit mein VPN verbinden.
Daher brauche ich einen "Proxy" bzw "Zwischenstation" der beides sprechen kann. IPv4 u. IPv6.Jep, verstanden. Ja ist problemlos machbar. Einfachste Variante:
- Lass deinen vorhandenen udp6 OVPN Einwahlserver in Ruhe, der läuft ja gut.
- Miete irgendwo eine günstige VM mit v4 und v6 und installiere OVPN
- Konfiguriere dort einen OVPN Service mit OVPN Tunnel Site2Site Server auf IPv6.
- Konfiguriere auf deiner pfSense eine OVPN Tunnel Site2Site Client mit IPv6. Da du nicht Server spielst, ist der Port hier egal.
- Tunnel so konfigurieren, dass die Route für dein internes v4 Netz auf der VM erreichbar wird
- Konfiguriere einen IPv4 Einwahlserver auf der VM und pushe hier dein internes v4 Netz zum einwählenden Client
Das wären jetzt so die Steps die mir dazu einfallen. Alternativ könnte man auch überlegen, ob man via stunnel oder ähnliches nicht direkt bei Verbindungsaufbau zur VM via IPv4 z.B. tcp/443 nicht direkt über den Site2Site IP6 Tunnel zu deiner pfSense durchroutet und dort direkt zum OVPN Server durchtunneln aber egal wie, machbar ist es auf jeden Fall.
@Libratix said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:
Die Anzahl der Instanzen wird effektiv wohl nur durch die Hardware limitiert, da für jede Instanz durchaus etwas Rechenpower nötig ist.
Rein technisch? Nein. Die Anzahl der Instanzen ist völlig nebensächlich, das wird leider immer wieder mit dem tatsächlich verschlüsselten Traffic verwechselt. Dieser - und nur dieser - ist tatsächlich CPU Last erzeugend. Ob da ein OVPN Service oder 50 davon auf Verbindungen warten - oder Leerlauf Verbindungen halten - ist völlig nebensächlich, das ist dann mehr IRQ, Netzwerk und RAM Frage wo das aufschlägt. Aber der tatsächlich laufende Traffic der verschlüsselt und entschlüsselt wird, das ist der springende Punkt. Da kann ein OVPN Server der mit 250mbps Daten hin und her schaufelt die Kiste genauso lahmlegen, wie ein OVPN Roadwarrior Server mit 100 Verbindungen, bei denen jeder für 1-2Mbps Daten überträgt. :)
-
Hallo Zusammen,
ich wollte ein kleinen Zwischenstand abgeben.
Momentan komme ich nicht weiter, weil ich noch auf die Antwort warte von Strato Support.
Weil auf meinen bei denen angemieteter Vserver anscheinend nicht möglich ist OpenVPN unteranderem zu betreiben, weil iptables gänzlich fehlt und somit keine Routen und Regeln anlegen kann.
Da Docker ebenfalls nicht nutzen kann, denke ich mal das dies ein schlecht konfigurierter Container ist.
-
Puh, Strato hatte ich schon lange nicht mehr, weil mich Preis/Leistung für Privatzwecke nicht überzeugt hat.
Mir fallen da spontan 2 Möglichkeiten:
- der vServer nutzt ein Linux-System, das gar kein iptables mehr zur Verfügung stellt sondern auf Alternativen setzt.
- in der Konfiguration der Repositorys stehen derzeit (abgespeckte) Strato-Repos, die sich durch die offiziellen Repos austauschen lassen um so iptables nach zu installieren.
-
Das ist immer das erste was ich mit so einem Server mache :-)
In dem Fall ist das anders, weil ich keine eigene Module laden kann usw. Daher wahrscheinlich eine OpenVZ/Container Lösung.
Welchen Anbieter würdest du denn empfehlen? Vor über 10 Jahren war ich mal Kunde bei Netcup. Domain + Vserver.
Sehe gerade, kosten die hälfte und dort steht sogar explizit das per KVM virtualisiert wird.
https://www.netcup.eu/vserver/vps.php#v-server-details
Habe gerade einen von Strato, für 5€ im Monat. Habe auch nur dort einen gemietet, weil ich dort bereits einige Domains habe.
-
Netcup wäre für private Zwecke auch meine Empfehlung gewesen. Die KVM-Virtualisierung macht richtig Spaß und die Ausfallzeiten sind sehr gering. Insbesondere für den Preis.
-
1 Kern reicht denke ich mal für ein bzw zwei Clienten? Also wegen OpenVPN und der stattfindenen Verschlüsselung während der Datenverkehr fließt.
-
Ich würde das mit der neuen vCloud von Hetzner mal probieren. Meine paar Instanzen dort sind zum einen super günstig und nach einem doofen Start mit einer davon auch voll Dual Stack ausstaffiert.
Könnte da notfalls mal testhalber OVPN draufladen, aber soweit ich das sehe (ich habe da Ubuntu 18.04 LTS Instanzen laufen), sehen die ein sauberes eth0 mit IP4/IP6. Mein Fail2Ban mit IPtables/NFtables und Fail2ban läuft da auch fein drauf. Vermutlich Kubernete oder KVM sauber virtualisiert - hatte noch keine Schwierigkeiten damit. Diese Pseudo-Containerisierung von manchen "vServern" ist echt gruselig... und die knapp 3€/mtl. sind kein Problem für nen Test (weniger wenn man mit der Kiste nur nen Tag spielt).
-
@JeGr said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:
Könnte da notfalls mal testhalber OVPN draufladen, aber soweit ich das sehe (ich habe da Ubuntu 18.04 LTS Instanzen laufen), sehen die ein sauberes eth0 mit IP4/IP6. Mein Fail2Ban mit IPtables/NFtables und Fail2ban läuft da auch fein drauf. Vermutlich Kubernete oder KVM sauber virtualisiert - hatte noch keine Schwierigkeiten damit. Diese Pseudo-Containerisierung von manchen "vServern" ist echt gruselig... und die knapp 3€/mtl. sind kein Problem für nen Test (weniger wenn man mit der Kiste nur nen Tag spielt).
Danke für den Tipp!
Bin nun bei Netcup. Und soweit läuft nun alles so wie ich es will. OpenVPN installiert und eingerichtet usw. Kann mich mit nem Smartphone oder Notebook zb aus dem Mobilnetz mit dem Server verbinden.
Gerade kämpfe ich mich bei der Konfiguration von pfSense durch. Das will noch nicht wie ich will.
Bin mal so faul, und kopiere ein Teil der Konversation die ich mit Libratix geführt habe bzw dem geschrieben habe:
Alles ist erledigt. Also Domain ist umgezogen und funktioniert. Server mit OpenVPN mit client-to-client eingerichtet, und Verbindung zum OpenVPN Server funktioniert auch. Jetzt muss ich nur noch den PFsense Router zuhause so konfigurieren, das er sich mit dem OpenVPN Server verbindet, aber jeglichen Traffic weiterhin "durch meine Internetleitung feuert" und nicht durch den VPN. Außer natürlich das, was durch den VPN angefragt wird. Kannst du mich darin unterstützen? Gehe übrigens hier nach: https://gist.github.com/InQuize/59e7c458c510ae779743 Und für die Konfiguration habe ich die exportierte ovpn Datei als Vorlage genommen: client dev tun proto udp remote 1.1.1.1 1111 resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server auth SHA512 cipher AES-256-CBC ignore-unknown-option block-outside-dns block-outside-dns verb 3 <ca> -----BEGIN CERTIFICATE----- ganz geheim 1 -----END CERTIFICATE----- </ca> <cert> -----BEGIN CERTIFICATE----- ganz geheim 2 -----END CERTIFICATE----- </cert> <key> -----BEGIN PRIVATE KEY----- ganz geheim 3 -----END PRIVATE KEY----- </key> <tls-crypt> -----BEGIN OpenVPN Static key V1----- ganz geheim 4 -----END OpenVPN Static key V1----- </tls-crypt> Leider verbindet sich die pfsense nicht. Verbose habe ich auf 4 stehen, und sehe kein Grund weswegen: https://pastebin.com/mkFRzYCFEdit: Sehe gerade das der pastebin aus irgendeinem Grund entfernt worden ist. Poste ich einfach mal direkt hier:
Restart pause, 10 second(s) NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Re-using SSL/TLS context Control Channel MTU parms [ L:1622 D:1140 EF:110 EB:0 ET:0 EL:3 ] Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client' Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server' TCP/UDP: Preserving recently used remote address: [AF_INET]1.1.1.1:1111 Socket Buffers: R=[42080->42080] S=[57344->57344] UDPv4 link local (bound): [AF_INET]2.2.2.2:0 UDPv4 link remote: [AF_INET]1.1.1.1:1111 MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock MANAGEMENT: CMD 'status 2' MANAGEMENT: CMD 'quit' MANAGEMENT: Client disconnected [UNDEF] Inactivity timeout (--ping-restart), restarting TCP/UDP: Closing socket SIGUSR1[soft,ping-restart] received, process restarting Restart pause, 20 second(s) -
In Kürze:
- Shared Key Tunnel einrichten zwischen dem Server und der pfSense
- bei pfSense als Client einrichten
- In der Konfiguration kein Remote Netz bei Tunnelkonfiguration auf pfSense definieren -> damit dann kein default-route oder route push
- auf pfSense sollte in Routing Table dann nur das Transfernetz auftauchen
- auf OVPN Server Seite mit IPTables (oder Filter der Wahl) NAT aufsetzen so dass alles was über den Tunnel zur pfSense kommt mit der IP des OVPN Server maskiert wird -> somit finden die Pakete auch problemlos ihren Rückweg wieder
- eingehend Firewall Regeln auf pfSense auf OpenVPN Interface nicht vergessen
-
Dem Log entnehme ich, dass er sich eigentlich verbindet, aber wegen Inactivity timeout die Verbindung wieder schließt, sprich: keine Pakete durch den Tunnel gehen.
Auf anhieb kommen mir die Werte für link-mtu und tun-mtu recht hoch vor. Für gewöhnlich bewegen sich die Werte zwischen 1300 und 1400.
Bei meinem pfSense Client habe ich "Peer to Peer (SSL/TLS)" Vorlage aus der Gui gewählt und im Grunde nur IP, Port, Zertifikate und Algorithmen passend zum Server eingetragen.
In den custom options stehen dann noch:
tun-mtu 1372
mssfix 1332
remote-cert-tls serverDie Werte für MTU und MSS habe ich anhand der Ping-Methode "errechnet". Als Start kann man es mit mssfix 1300 mal ausprobieren, wenn die Verbindung dann klappt, hat man den Fehler schon gefunden und kann dann einen größeren Wert austeste.
-
@Libratix said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:
Bei meinem pfSense Client habe ich "Peer to Peer (SSL/TLS)" Vorlage aus der Gui gewählt und im Grunde nur IP, Port, Zertifikate und Algorithmen passend zum Server eingetragen.
Nope. Einfach wie oben beschrieben einen Shared Key Tunnel nutzen. Einfachste Vorgehensweise. P2P TLS kann problematisch sein, weil es hier kein definierter Partner besteht, sondern es ggf. mehrere eingewählte Tunnelendpunkte geben kann. Daher ist bspw. auch bei Protokollen wie OSPF der P2P TLS Mode nicht möglich, sondern NUR der SharedKey Mode.
An irgendwelchen MTUs einfach rumzudrehen ohne Not würde ich ebenfalls nicht. Wenn es nicht läuft, OK, andernfalls unnötig wenn alle Peers ordentlich routen. Kein Grund das auf irgendwelche 1300er Werte runterzudrücken wenn es nicht sein muss.
Dem Log entnehme ich, dass er sich eigentlich verbindet, aber wegen Inactivity timeout die Verbindung wieder schließt, sprich: keine Pakete durch den Tunnel gehen.
Keine Pakete durch den Tunnel sind kein Argument. OVPN im P2P Mode baut nicht einfach den Tunnel ab weil grade nichts durch läuft. Inactivity Timeout auf Client Seite wird getriggert, wenn die Gegenseite nicht (mehr) antwortet und damit angenommen wird, dass die Verbindung abgerissen ist.
-
Oh, sag das mal meinem OSPF, dass er mit P2P TLS nicht möglich ist. Der weiß das offenbar noch nicht.
Und bei mir konnte ich die Inactivity Timeouts eben durch Anpassung der MTU an die realen Umstände beheben.
-
Ehm, ich entnehme eurer Konversation also jetzt das ich alles richtig gemacht habe und es richtig ist das es nicht läuft?
-
@Libratix said in Client --[openvpn_ipv4]--> vserver --[openvpn_ipv6]--> Zuhause und zurück möglich?:
Oh, sag das mal meinem OSPF, dass er mit P2P TLS nicht möglich ist. Der weiß das offenbar noch nicht.
Klar. Keine Ahnung was du noch eingestellt hast, dass es vielleicht geht, aber sobald man mehrere S2S Verbindungen bei P2PTLS hat, sieht der OSPF seine Gegenstellen nicht mehr. Mehrfach nachgestellt und mit Core Switchen und Routern als Gegenstellen schon gehabt. Gerade erst vor einem Monat. Ist BTW auch genau so in der Doku und im Troubleshooting Guide explizit erwähnt. Sollte es durch das neue FRR zufällig jetzt gehen würde ich mich trotzdem nicht drauf verlassen.
Ehm, ich entnehme eurer Konversation also jetzt das ich alles richtig gemacht habe und es richtig ist das es nicht läuft?
Nein, inactivity timeout heißt eben dass er keine Kommunikation mehr bekommt. Hat aber nichts mit "da geht kein Paket mehr drüber" -> kein Traffic - zu tun, sondern dass nichts ankommt, was ankommen SOLL. Zudem hatte ich nicht gesagt, dass es nicht an der MTU liegt, sondern, dass man daran nicht rumfingert wenns keinen Grund gibt. Und normalerweise gibts gerade zu irgendwelchen Datacentern eher keinen Grund - weil da niemand hinter irgendwelchen Modems oder sonstigen Gerätekopplern sitzt, die die MTU verhunzen. Es kann auch an anderen Settings liegen. Muss man eben mal das Logging auf 3 oder 4 hochdrehen und genau mitlesen.
Zudem sollte nach Verbindungsaufbau ja das VPN Gateway (die Gegenstelle) in pfSense auftauchen und somit angepingt werden. Es gibt also normalerweise gar nicht die Situation, dass kein Traffic läuft.
-
Das ist bereits Logging auf 4.
Mehr kommt leider nicht.
Sobald zu Hause bin, werde ich es noch höher einstellen. Vielleicht kommt dann mehr Infos.
-
Nah, 4 ist eigentlich schon genug. Wäre aber sinnvoll ggf. Server und Client Logs aus dem gleichen Zeitraum ggü stellen zu können.
