Public IPv4/IPv6 via VPN Tunnel
-
https://forum.netgate.com/topic/159426/pfsense-und-ipv6-openvpn-rules-routes-usw
So wie im Beitrag angedeutet hab ich das mal ausprobiert:
- pfSense auf VPS bei Hetzner geworfen (Cloud VPS)
- Hat eine IPv4 und IPv6 /64er Subnetz
- OpenVPN Tunnel dahin gebaut mit IP4/IP6
3b) gleich noch nen Bugreport geschrieben weil Shared Key Generation in den Snapshots grad halb-kaputt ist
- Tunnel geprüft und getestet
Dann getestet:
IP4 einzelne Port weiterleiten- IP6 aus /64er Bereich auf lokales System mit fdXY::/64 Adresse gemappt
Theoretisch sollte auch 1:1 NAT auf die IP4 möglich sein, hatte ich jetzt gerade keine größere Zeit mehr aber sehe nicht warum es nicht gehen sollte. Außerdem hätte ich dann einen Client in einem Extra Netz gebraucht den ich gerade so verbiegen kann, dass er dann outbound auch via VPN rausgeht und die IP4 nutzt.
Theoretisch könnte man sich für nen Euro ne Floating IP mieten und die dann auf den VPS draufhängen und hätte dann eine ganze IP zum weiterleiten und Spielen zur Verfügung. Ist natürlich wegen Tunnel immer noch etwas weniger performant als nativ, aber hey kommt immer auf den Einsatzbereich an. Und wer mehr Performance mag, kann dann ja auch mit IPsec testen oder potentiell auf Wireguard-in-Kernel Implementation warten. Dann geht da ggf. noch etwas mehr :)
-
@jegr Meintest Du nicht seinerzeit, dass es dafür zwei /64er bedarf oder bringe ich da was durcheinander?
-
Kannst du mal beizeiten die konfig beider Seiten zeigen ohne Zertifikate?
Den VPS als OVPN Server und die Sense als Client, da prasseln laufend Standardfehlermeldungen in die Syslog.Anders herum ist der Verbindungsaufbau soweit in Ordnung.
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Kannst du mal beizeiten die konfig beider Seiten zeigen ohne Zertifikate?
Den VPS als OVPN Server und die Sense als Client, da prasseln laufend Standardfehlermeldungen in die Syslog.Anders herum ist der Verbindungsaufbau soweit in Ordnung.
Läuft nicht mit Zertifikaten momentan, reines Shared Key Setup, dafür kein GCM, ja. War faul.
@bob-dig said in Public IPv4/IPv6 via VPN Tunnel:
@jegr Meintest Du nicht seinerzeit, dass es dafür zwei /64er bedarf oder bringe ich da was durcheinander?
Hab ich oben auch beschrieben: Entweder man kann per NPt einzelne IP6 durchreichen oder man bräuchte ggf. geroutet ein zweites IPv6 Prefix und kanns dann weiterrouten.
-
@jegr Got it! Aber wer will einen (zweiten) VPS anmieten, nur um eine weitere pfSense laufen zu lassen, das bleibt halt die Crux für Sparfüchse.
-
Eine pfsense Instanz ist auf dem VPS echt nicht nötig. Wenn OpenVPN schon looft auf der Sense, den clienten exportieren und die ovpn datei auf den VPS kopieren. Mit "openvpn /pfad/zur/conf_datei" als Client starten, fettisch, quick ’n dirty :)
Mit den Iptables und den routes, das kriegen wir schon hin. :)
-
@bob-dig said in Public IPv4/IPv6 via VPN Tunnel:
@jegr Got it! Aber wer will einen (zweiten) VPS anmieten, nur um eine weitere pfSense laufen zu lassen, das bleibt halt die Crux für Sparfüchse.
Warum ne zweite? Ich hab ne zweite Laufen weil ich eh nen externen Server habe. Aber wer das alles bei sich zu Hause laufen lassen will und nur ne externe IP4/IP6 sucht, die statisch ist, find ich das keinen Overhead. Wenn ich eh "nur" VPN laufen lassen will - ist es mir doch egal was auf der Tüte läuft. Ob das "nötig" ist oder nicht, ist doch dann sekundär. Es lüppt was lüppt. Und was für mich einfacher und weniger Streß erzeugt ist mir garantiert mehr wert als Rumbasteln in einer Linux VPS Instanz um rumsuchen, was für IP Forwarding Optionen, Sysctl Calls und Firewall Settings ich da brauche wenn ich in ner halben Stunde die Sense Installation durchgetippt hab
-
@jegr said in Public IPv4/IPv6 via VPN Tunnel:
@jegr
Kannst du mal beizeiten die konfig beider Seiten zeigen ohne Zertifikate?
Den VPS als OVPN Server und die Sense als Client, da prasseln laufend Standardfehlermeldungen in die Syslog.
Anders herum ist der Verbindungsaufbau soweit in Ordnung.Läuft nicht mit Zertifikaten momentan, reines Shared Key Setup, dafür kein GCM, ja. War faul.
Oke.
VPN Server: VPS, client: Sense, folgende Fehlermeldung im Sekundentakt:
Jan 20 09:37:41 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:41 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:44 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:45 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:45 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:46 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:46 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:46 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:46 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:47 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:47 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:48 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:48 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seen Jan 20 09:37:48 localhost openvpn[2465]: pfsense/87.168.50.xxx:11580 IP packet with unknown IP version=15 seenTante Google spuckt Unterschiede bei der Komprimierungeinstellung zwischen Server und Client raus. Egal was in der Konfig steht, laufend diese Fehlermeldung. Deswegen die Frage nach deiner *.conf für Server und Client.
Hast ja auf beide Seiten pfSense laufen, die Meldungen wirst Du nicht haben, oder?
edit:
Server/Client Konfig ist Blödsinn, Peer to Peer ist der richtige Weg oder? :)
-
Vielleicht hilft dir das;
https://www.toofishes.net/blog/openvpn-and-aoe-interaction/ -
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Server/Client Konfig ist Blödsinn, Peer to Peer ist der richtige Weg oder? :)
Poste doch mal deine Konfigs auf beiden Seiten. Ich such gern meine raus, aber für nen Tunnel bei dem Geschwindigkeit jetzt nicht der primäre Aspekt ist (wegen CBC vs GCM was bei SharedKey nicht geht), ist Shared Key eben so viel einfacher.
Lasse gerade den VPS nochmal updaten.
-
@jegr said in Public IPv4/IPv6 via VPN Tunnel:
Poste doch mal deine Konfigs auf beiden Seiten.
Hier sie Sense als Server:
dev ovpns2 verb 1 dev-type tun dev-node /dev/tun2 writepid /var/run/openvpn_server2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-128-CBC auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 87.168.50.208 ifconfig 10.1.2.1 10.1.2.2 lport 1195 management /var/etc/openvpn/server2.sock unix secret /var/etc/openvpn/server2.secret compressDer VPS als Client, quasi der Shared Key Export:
dev tun persist-tun persist-key cipher AES-128-CBC auth SHA256 #pull resolv-retry infinite proto udp remote home.example.com 1195 udp4 ifconfig 10.1.2.2 10.1.2.1 keepalive 10 60 ping-timer-rem compress <secret> # # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- x x -----END OpenVPN Static key V1----- </secret>Verbindung wird aufgebaut. ein Teil von "ip a"
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 10.1.2.2 peer 10.1.2.1/32 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::49ea:1dc6:176:6f28/64 scope link stable-privacy valid_lft forever preferred_lft forever -
Danke für den Link. Leider nicht. :)
-
@mike69 Ich würde mal beide Seiten auf "verb 3" setzen und schauen was das Log spricht beim Verbindungsaufbau :)
-
@jegr said in Public IPv4/IPv6 via VPN Tunnel:
@mike69 Ich würde mal beide Seiten auf "verb 3" setzen und schauen was das Log spricht beim Verbindungsaufbau :)
Kann ich gerne uppen, dies ist aber die Konfig die looft. :)
Anders herum, VPS als OVPN Server und pfSense als Client, da hakt es ungemein.Wenn ich es schaffe, werde ich das morgen Abend umbauen und die Konfigs, bzw. Logs rein stellen.
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Wenn ich es schaffe, werde ich das morgen Abend umbauen und die Konfigs, bzw. Logs rein stellen.
Okay, oder je nach Teilnahme morgen beim Usergroup Meet können wirs ggf. auch einfach mal durchspielen.
-
@jegr said in Public IPv4/IPv6 via VPN Tunnel:
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Wenn ich es schaffe, werde ich das morgen Abend umbauen und die Konfigs, bzw. Logs rein stellen.
Okay, oder je nach Teilnahme morgen beim Usergroup Meet können wirs ggf. auch einfach mal durchspielen.
Ja, hört sich gut an.
Anderes Scenario, VPS als OVPN Server, pfSense als Client looft jetzt. Habe die konfiguration neu erstellt und die Cipher von AES-256-GCM auf AES-256-CBC geändert.
Server Config:
local 212.227.xxx.yyy port 1195 proto udp dev tun ca ca.crt cert server.crt key server.key dh dh.pem auth SHA512 tls-crypt tc.key topology subnet server 10.8.0.0 255.255.255.0 server-ipv6 fddd:1194:1194:1194::/64 push "redirect-gateway def1 ipv6 bypass-dhcp" ifconfig-pool-persist ipp.txt push "dhcp-option DNS 9.9.9.9" push "dhcp-option DNS 149.112.112.112" keepalive 10 120 cipher AES-256-CBC user nobody group nogroup persist-key persist-tun status openvpn-status.log verb 5 crl-verify crl.pem explicit-exit-notify compress.
pfsense als Client:dev ovpnc4 verb 3 dev-type tun dev-node /dev/tun4 writepid /var/run/openvpn_client4.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-256-CBC auth SHA512 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 87.168.xxx.yyy tls-client client lport 0 management /var/etc/openvpn/client4.sock unix remote 212.227.xxx.yyy 1195 udp4 ca /var/etc/openvpn/client4.ca cert /var/etc/openvpn/client4.cert key /var/etc/openvpn/client4.key tls-crypt /var/etc/openvpn/client4.tls-crypt ncp-disable compress resolv-retry infiniteLogs zu dieser Verbindung kann bei Bedarf nachgereicht werden.
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Anderes Scenario, VPS als OVPN Server, pfSense als Client looft jetzt. Habe die konfiguration neu erstellt und die Cipher von AES-256-GCM auf AES-256-CBC geändert.
Und das ist alles gewesen? Seltsam. Da du CA-based machst, müsste GCM problemlos laufen. Naja vielleicht ham wir heut Abend ja ne ruhige Kugel und können das mal testweise nachbauen :)
-
Jetzt, wo Du es erwähnst. :)
Funzt auch mit AES-256-GCM, wer weiss, wo es damals geklemmt hat.Ok, Tunnel steht, jetzt den v4 Traffic durchleiten... :)
Bei den ganzen HowTos der VPN Anbieter wird einen VPN Interface erstellt, wird das hier auch benötigt? Gehe mal von einem "Ja" aus, brauchtst ja ein Gateway, oder?
Werde auf alle Fälle ein Testnetz erstellen, welches komplett durch das VPN geleitet werden soll.
Boah, das ganze Routingkram ist für mich Hexenwerk. :) Da sitze ich wie ein Schwein vorm Uhrwerk.
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Bei den ganzen HowTos der VPN Anbieter wird einen VPN Interface erstellt, wird das hier auch benötigt? Gehe mal von einem "Ja" aus, brauchtst ja ein Gateway, oder?
Jap genau deshalb :) Und weil @viragomann es eigentlich schön zusammengefasst hat "man brauchts eigentlich nicht immer, es schadet aber nicht, darum mach ich es einfach jedes Mal". :) Denn dann muss man in der laufenden Konfig nicht mehr rumschrauben und Tunnel neu starten etc. (Nach der Zuweisung des ovpnX IFs muss man den Tunnel neu starten, damit das IF sauber läuft).
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Boah, das ganze Routingkram ist für mich Hexenwerk. :) Da sitze ich wie ein Schwein vorm Uhrwerk.
Ganz ehrlich? So sitz ich grad vor dem WireGuard Kram. Super einfach und so... Mhmm...
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Bei den ganzen HowTos der VPN Anbieter wird einen VPN Interface erstellt, wird das hier auch benötigt? Gehe mal von einem "Ja" aus, brauchtst ja ein Gateway, oder?
Werde auf alle Fälle ein Testnetz erstellen, welches komplett durch das VPN geleitet werden soll.Das heißt, du musst mit Policy Routing Regeln arbeiten. Ja, in diesem Fall ist das Interface Voraussetzung, ansonsten hättest du kein Gateway zum Routen.
Eine Falle, in die viele bei erstmaligem Einrichten hineintappen, ist dabei, dass die Leute einfach eine Regel ganz oben am Interface setzen, die allen Trafft auf das VPN -Gateway routet. Damit haben die Geräte allerdings keinen Zugriff mehr auf interne Resourcen, auch nicht auf die pfSnese selbst, falls diese bspw. zur DNS-Auflösung verwendet wird. Das hat dann zur Folge, dass gar nichts mehr geht, intern wie extern.
-
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Jo, soweit im Schädel angekommen. :)
Reicht aber aus, dem Testsubnet nur das VPN Gateway einzustellen? Oder brauch ich noch ne Rule unter"NAT/Outbound"?Was jetzt schon zu tätigen ist, die WAN Gateways in den Rules einzutragen, damit nicht alles über VPN läuft. Kann man das anders lösen irgendwie?
-
@mike69
Die Outbound NAT Regel am OpenVPN Interface wird immer benötigt, wenn da ein Traffic ins Internet soll. Dann ist es ja quasi ein WAN-Gateway. Ohne NAT kämen die Pakete nicht zurück.Es sollte reichen, den Traffic fürs VPN zu routen, WAN sollte das Default Gateway bleiben, dann musst du es nicht in den Regeln angeben.
Damit das so ist, muss im Client "Don't pull routes" angehakt sein, denn die Provider pushen üb(lich)erweise die Default-Route.Solltes du das WAN-GW in den Regel angeben, gilt wieder oben gesagtes: Die Regel erlaubt dann nur noch Traffic über das WAN-GW und damit keinen internen.
-
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Solltes du das WAN-GW in den Regel angeben, gilt wieder oben gesagtes: Die Regel erlaubt dann nur noch Traffic über das WAN-GW und damit keinen internen.
Ja, stimmt.
Der "Provider" ist eigentlich ein gemieteter VPS, OVPN ist somit komplett konfigurierbar.
Oke, "Don't pull routes" gesetzt, das Testsubnet den VPN Gateway vorgesetzt und die Rule unter Outbound erstellt so wie hier:
Soweit in Ordnung?
-
@mike69
Ja, für eine Test-Interface in Ordnung. Ansonsten möchtest du vielleicht nicht any als Quelle haben.Okay, wenn du den Server selbst kontrollierst, musst du ja keine Routen oder Redirect Gateway pushen.
-
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Ansonsten möchtest du vielleicht nicht any als Quelle haben.
Neee. :)
Eine Handvoll Hosts und Spielkonsolen, die eine öffentliche IPv4 brauchen. Wenn Glasfaser Deutschland hier fertig ist, bleibt nur eine public IPv6 über.
Das ist der/mein Hintergrund für diese Aktionen.Ok, Geräte im Testnetz gehen jetzt über den VPS ins INet. Es geht voran, jetzt müssen nur noch die Hosts von aussen mit der IP vom VPS erreichbar sein. Ganz einfach... :)
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
jetzt müssen nur noch die Hosts von aussen mit der IP vom VPS erreichbar sein.
Auch dafür ist das VPN-Interface nötig.
Und das birgt eine weitere Falle:
Achte darauf, dass nur Regeln auf dem speziell hinzugefügten VPN-Interface auf die eingehenden Verbindungen zutreffen, also keine auf dem OpenVPN Tab und keine Floating! -
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Achte darauf, dass nur Regeln auf dem speziell hinzugefügten VPN-Interface auf die eingehenden Verbindungen zutreffen, also keine auf dem OpenVPN Tab und keine Floating!
Da sagt er was Wichtiges, daher aufgepasst! :) Hatte schon einige Kunden die sich über Blinkerverhalten beim OVPN Tunnel gewundert haben - geht - geht nicht - bis dann rauskam: zweites VPN konfiguriert und beide ohne Interfaces. Also flappte das Gateway ständig zwischen ovpns1 und ovpns2 ;)
-
@jegr
Eingehende Verbindungen funktionieren auch mit einer einzigen VPN-Instanz nicht, wenn eine Regel am VPN-Tab sie zulässt. -
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Eingehende Verbindungen funktionieren auch mit einer einzigen VPN-Instanz nicht, wenn eine Regel am VPN-Tab sie zulässt.
Wenns nur Tunnelverbindungen sind - doch. Hab einen Kunden mit Tunnel only (alles Außenstellen mit S2S Shared Key config). Keine Interfaces definiert, alles nur über den OVPN Regeltab. Aber da die Routen via Konfiguration der einzelnen Tunnel klar sind, ist da auch nichts PolicyBased notwendig und alles läuft brav über das normale Systemrouting. Egal in welche Richtung.
-
@jegr
Ja, da ist aber die VPN-Gegenstelle das Default Gateway. Denn genau da schickt die pfSense die Response-Pakete hin, wenn die Requests auf eine OpenVPN-Tab Regel erlaubt werden. -
Moinsen.
Nach paar Wochen Unlust wieder am Start zu diesem Thema.
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
@jegr
Ja, da ist aber die VPN-Gegenstelle das Default Gateway. Denn genau da schickt die pfSense die Response-Pakete hin, wenn die Requests auf eine OpenVPN-Tab Regel erlaubt werden.Paar mal durchgelesen, nichts verstanden :)
Das Prinzip schon, nur weiss nicht, welche push oder pull rules im vserver oder in der Sense eingetragen werden soll.Habe das jetzt mit iptables hinbekommen, sagt bitte, ob das so weit sauber ist.
Outbound Mapping erstellt:
Portforwarding Rule erstellt:
hier die FW Rule:
Und hier die iptables rules auf dem vserver:
# sense -> vserver iptables -t nat -I POSTROUTING 1 -s 10.8.0.0/24 -o ens192 -j MASQUERADE iptables -I INPUT 1 -i tun0 -j ACCEPT iptables -I FORWARD 1 -i ens192 -o tun0 -j ACCEPT iptables -I FORWARD 1 -i tun0 -o ens192 -j ACCEPT iptables -I INPUT 1 -i ens192 -p udp --dport 1195 -j ACCEPT #vserver -> sense iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.8.0.2:80Damit kann ich mit der IPv4 des vservers die HTTP Seite vom Testserver @Home aufrufen. Der Rest wie ssh, sftp, Portrange für Konsolen, etc... geht auch, musst nur mit den Ports spielen, nicht, das z. B. der ssh Zugriff auf dem vserver umgeleitet wird. :)
Wenn ne Domain vorhanden ist, eine Subdomain auf die externe IP des vservers umleiten, voilà.
Wenn das schicker geht, sagt was.
-
@mike69
Ein großer Freund von Routing bist du offenbar nicht, denke ich, nachdem du eine NAT-Kaskade gebaut hast. Du nattest den Traffic in beide Richtungen zweimal.
Aber okay, das mag Geschmackssache sein, ich würde die Pakete halt routen und nur einmal je Richtung NAT machen.@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Paar mal durchgelesen, nichts verstanden :)
Ist für deinen Zweck auch gar nicht nötig. Die VPN ist ohnehin das Default Gateway und das WAN GW verwendest du nicht.
-
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Ein großer Freund von Routing bist du offenbar nicht, denke ich, nachdem du eine NAT-Kaskade gebaut hast.
Zu einer Freundschaft bedarf es erst mal das gegenseitige kennen- und schätzen lernen. Hatte noch keine grossen Berührungspunkte zum Thema Routing.
Dies ist ein Hobby, meine Brötchen verdiene ich anders, sonst würde ich meine Fragen im perfektem Business Englisch im internationalen Forenbereich stellen.
Ehrlich gesagt, @viragomann , diese Antwort irritiert etwas, hätte ich von dir so nicht erwartet. Aber was solls, liegt wahrscheinlich an der aktuellen Situation.
Gehe mal nicht von aus, dass Du oder jemand anders gewillt ist, uns/mir den richtigen Weg zu zeigen, oder?
Dieser und dieser Thread sind schon paar Wochen alt, bis jetzt hat keiner gezeigt, dass es so irgendwie geht. Entweder weiß es keiner oder die, die es wissen wollen das selbige nicht preisgeben, what ever....
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Gehe mal nicht von aus, dass Du oder jemand anders gewillt ist, uns/mir den richtigen Weg zu zeigen, oder?
Der Weg, der zum Ziel führt, ist der richtige.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Dieser und dieser Thread sind schon paar Wochen alt, bis jetzt hat keiner gezeigt, dass es so irgendwie geht. Entweder weiß es keiner oder die, die es wissen wollen das selbige nicht preisgeben, what ever....
Na, hoffentlich werde ich jetzt nicht geprügelt, weil ich nicht in jedem elendslangen Thread hier einsteige. Und wenn das denn soll, schreibe nicht so abschreckende Dinge wie "IPv6" in das Thema!.
Ich habe auch nicht Thread nicht von Anbeginn verfolgt, weiß daher vielleicht nicht, worum es genau geht. Nachdem ich genannt wurde, hatte ich diesen und den Post davor gelesen und der Sache was hinzugefügt, wovon ich gedacht hatte, das es hilfreich sein könnte. War wohl ein Fehler.
Aber wie oben geschrieben, wenn es funktioniert, lass es doch gut sein. Ich habe nichts grundlegend Falsches an den Einstellungen gefunden.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Ehrlich gesagt, @viragomann , diese Antwort irritiert etwas, hätte ich von dir so nicht erwartet.
Meine Antwort war doch sachlich. Ich habe geschrieben, was mir ins Auge fällt. Du setzt ein Forwarding jeweils zum nächsten Knoten.
Ich hätte eben am Server die ankommenden HTTP-Paket direkt auf 10.0.99.222 weitergeleitet.
Ebenso hätte ich die Outbound NAT Regel am Client eingespart. Aber dann musst du das Masquerading auf der Serverseite eben so anpassen, dass es für das Client LAN auch angewendet wird bzw. eine zusätzliche Regel setzen.Und das braucht dann am Server auch eine Route fürs Client LAN in der OpenVPN Konfig, damit es klappt.
-
Moin.
@viragomann
Grossenteils schätze ich deine sachliche Antworten. Kann sein, dass ich durch ewiges try and error zu diesem Thema etwas dünnhäutig werde, sorry, falls sich jemand auf die Füsse getreten fühlt.
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Ich habe auch nicht Thread nicht von Anbeginn verfolgt, weiß daher vielleicht nicht, aworum es genau geht
Hier die Kurzform:
Durch baldigen Providerwechsel fällt die public IPv4 weg, und einige Hosts im LAN sollen weiter mit einer public IPv4 erreichbar sein.Also, einen Virtual Private Server (VPS) gemietet, und darauf einen OpenVPN Server installiert. (Ja, es geht auch anders.
)pfsense ist der VPN Client, ein paar Hosts hinter der Sense sollen ihr komplettes Traffic durch den VPS schieben, rein und raus. Mir würde ein Routing zur pfSense reichen, oder ist es möglich, mehrere Hosts direkt zu routen?
Also VPS IP 212.224.xxx.yyy <---> 10.0.99.222 und 10.0.20.223?Würde die VPS IPv4 dafür opfern, komme ja noch per ssh und IPv6 auf den VPS.
@JeGr
Falls mein Beitrag besser zu diesem Thread passt, bitte verschieben. -
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
oder ist es möglich, mehrere Hosts direkt zu routen?
Also VPS IP 212.224.xxx.yyy <---> 10.0.99.222 und 10.0.20.223?Ja, klar ist es möglich, ich habe ja geschrieben, ich würde die Weiterleitung direkt am VPS machen.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Würde die VPS IPv4 dafür opfern, komme ja noch per ssh und IPv6 auf den VPS.
Muss wohl sein. Ist ja die einzige statische IPv4, die du dann hast.
Die VPN-Verbindung wäre dann nur noch ein Transitnetz für den Traffic von außen zum Home-LAN. Aber klar kannst du sie dennoch nutzen, um auf den VPS zuzugreifen.
Aktuell ist der VPN-Server dein Standardgateway. Das heißt, dass auch alle ausgehenden, vom Home-LAN initiierten, Verbindungen, die nicht explizit anders geroutet werden, über die VPN laufen und damit öffentliche Quell-IP des VPS bekommen. Mir ist noch nicht klar, ob das so gewünscht ist. Ich habe das ich schon mehrmals angesprochen, du bist aber darauf nicht eingegangen. Auch das ist Geschmackssache, ich sehe keine Notwendigkeit dafür, kenne aber die Hintergründe nicht.
Die Frage sollte aber beantwortet werden, weil sie für die Konfiguration entscheidend ist. Aus diesem Grund hatte ich es fast in jedem Post hier erwähnt...@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Mir würde ein Routing zur pfSense reichen, oder ist es möglich, mehrere Hosts direkt zu routen?
Eine alternative Herangehensweise, allerdings wieder mit Double-NAT, für Leute, die sich nicht allzu viel mit iptables herumschlagen möchten, wäre, sämtlichen eingehenden Traffic am VPS mit einer einzigen Regel (mit Port-Ausnahmen für SSH etc.) weiterzuleiten und dann die Regeln für die einzelnen internen Ziele auf der pfSense setzen.
Wieder: Geschmackssache. Du musst mal sagen, was du genau umsetzen möchtest.
Meine Meinung habe ich schon kundgetan. Ich würde alle Weiterleitungen direkt am VPS setzen und die VPN als Transitnetz für eingehende Verbindungen ins Home nutzen. Bin allerdings auch nicht sehr vertraut mit iptables. -
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Aktuell ist der VPN-Server dein Standardgateway. Das heißt, dass auch alle ausgehenden, vom Home-LAN initiierten, Verbindungen, die nicht explizit anders geroutet werden, über die VPN laufen und damit öffentliche Quell-IP des VPS bekommen. Mir ist noch nicht klar, ob das so gewünscht ist.
Stimmt, hab Dir damals kein Feedback gegeben, Asche auf mein Haupt.
Nein, ist nicht gewünscht und durch den Schalter "Don't pull routes" deaktiviert.@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Du musst mal sagen, was du genau umsetzen möchtest.
Ein Host und die Spielkonsolen wenn nötig sollen später mit einer public IP von draussen zu erreichen sein.
Spielekonsolen deshalb, weil einige Dienste per v6 nicht zur Verfügung stehen, das kann sich eventuell bald ändern. Aktuell ist ein bestimmter "NAT Type" für ein einwandfreies Onlinepielen notwendig resultierend durch eine Portweiterleitung bestimmter Ports. Oder durch eine direkte Verbindung zu einem Modem. Ist das durch Routing machbar?
Ein Host mit SSH Zugang, einfach als Failover, falls der Zugriff per v6 nicht funzt. Das ist mein Ziel.
Die Konsolen und der Host befinden sich in versch. Subnetzen.
Dieses Doppel NAT ist nicht ideal, das weiss ich auch. Deswegen würde ich eine komplette Weiterleitung auf dem VPS vorziehen. Nur wie mache ich das?
Hier erstmal die Routingtabelle vom VPS:
root@ionos:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.255.255.1 0.0.0.0 UG 0 0 0 ens192 10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 10.255.255.1 0.0.0.0 255.255.255.255 UH 0 0 0 ens192Hoffe, konnte bisschen Licht ins Dunkle bringen.
-
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Nein, ist nicht gewünscht und durch den Schalter "Don't pull routes" deaktiviert.
Die Idee ist aber nun neu. Die Konfig Files oben zeigen was anderes: Serverseitig "redirect gateway" und am Client nichts von route nopull.
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Oder durch eine direkte Verbindung zu einem Modem.
UPnP vermutlich.
Das wäre auch nur eine Weiterleitung, eine die sich eben das Endgerät (Konsole) selbst setzt.Ist das durch Routing machbar?
Wenn es grundsätzlich über die VPN machbar ist, ja. UPnP wird am VPS nicht gehen.
Dieses Doppel NAT ist nicht ideal, das weiss ich auch. Deswegen würde ich eine komplette Weiterleitung auf dem VPS vorziehen.
Die Weiterleitung des ganzen Traffics am VPS auf die pfSense wäre auch NAT. Auf der pfSense ist dann eine weiteres NAT nötig, um auf die einzelnen Geräte zu kommen, also auch Doppel-NAT.
Wenn du kein Doppel-NAT haben möchtest, musst du die Regeln am VPS (mit iptables) setzen und als Targets eben die Ziel-IPs in deinem LAN angeben.Dieses "ens192" hatte ich für das WAN gehalten. Es hat aber eine private IP?
Wenn so, muss ja da auch schon mal NAT im Spiel sein. -
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Die Idee ist aber nun neu. Die Konfig Files oben zeigen was anderes: Serverseitig "redirect gateway" und am Client nichts von route nopull.
Eigentlich nicht. Die Konfigs sind älter, den Tipp gabst Du mir danach.
Hab den vserver zwischenzeitlich neu aufgesetzt, hier die aktuellen Konfigs:
Server:
local 212.227.xxx.yyy port 1195 proto udp dev tun user nobody group nogroup persist-key persist-tun keepalive 10 120 topology subnet server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "dhcp-option DNS 127.0.0.1" push "redirect-gateway def1 bypass-dhcp" server-ipv6 fd42:42:42:42::/112 tun-ipv6 push tun-ipv6 push "route-ipv6 2000::/3" push "redirect-gateway ipv6" dh none ecdh-curve prime256v1 tls-crypt tls-crypt.key crl-verify crl.pem ca ca.crt cert server_server.crt key server_server.key auth SHA256 cipher AES-128-GCM ncp-disable tls-server tls-version-min 1.2 tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 client-config-dir /etc/openvpn/ccd status /var/log/openvpn/status.log verb 3 compressClient:
dev ovpnc2 verb 1 dev-type tun dev-node /dev/tun2 writepid /var/run/openvpn_client2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp4 cipher AES-128-GCM auth SHA256 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 87.168.xxx.yyy tls-client client lport 0 management /var/etc/openvpn/client2.sock unix remote 212.227.xxx.yyy 1195 udp4 ca /var/etc/openvpn/client2.ca cert /var/etc/openvpn/client2.cert key /var/etc/openvpn/client2.key tls-crypt /var/etc/openvpn/client2.tls-crypt ncp-disable compress resolv-retry infinite route-nopull@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
Oder durch eine direkte Verbindung zu einem Modem.
UPnP vermutlich.
Über PPPOE
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Dieses "ens192" hatte ich für das WAN gehalten. Es hat aber eine private IP?
Wenn so, muss ja da auch schon mal NAT im Spiel sein.Der VPS hat nur ein Interface, die ens192 und bekommt die IPs per dhcp zugeteilt, und die ist nicht privat. 212.227. nochwas
Wie das der Anbieter macht, keine Ahnung. Zumindest habe ich in der virtuellen Konsole ein Proxmox Logo beim booten gesehen.
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Die Weiterleitung des ganzen Traffics am VPS auf die pfSense wäre auch NAT. Auf der pfSense ist dann eine weiteres NAT nötig, um auf die einzelnen Geräte zu kommen, also auch Doppel-NAT.
Wenn du kein Doppel-NAT haben möchtest, musst du die Regeln am VPS (mit iptables) setzen und als Targets eben die Ziel-IPs in deinem LAN angeben.Es gibt Unterschiede zwischen routen und weiterleiten?
Und wie soll das gehen? Nach meinem Verständnis brauch es noch ein Routing auf der Sense, oder? Wie soll das Paket wissen, was auf 10.8.0.2 reinschneit, das es zur IP 10.0.99.222 soll?
@viragomann
Wie würdest Du es wuppen? Damit ich irgendwie mal einen Anfang habe... -
@mike69 said in Public IPv4/IPv6 via VPN Tunnel:
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:
Die Idee ist aber nun neu. Die Konfig Files oben zeigen was anderes: Serverseitig "redirect gateway" und am Client nichts von route nopull.
Eigentlich nicht. Die Konfigs sind älter, den Tipp gabst Du mir danach.
Redirect gateway am Server kombiniert mit route-nopull am Client? Nein, solche Tipps gebe ich nicht. Ersteres pusht die Default-Route zum Client, letzteres weist denselben an, sie nicht zu setzen. Hmm, nein, von mir hast du das nicht. Nicht in dieser Kombination.
Aber egal, du magst die VPN nicht als Default-Gateway nutzen, habe ich nun mitbekommen.
Die VPN würde ich allerdings für diesen Zweck in ein /30er-Netz ändern. Ist ja ein Site-2-Site und kein Access-Server. Damit wären die Rollen klar definiert.Am VPN-Server musst du eine Route für dein internes Netz setzen:
route 10.0.99.0 255.255.255.0für das 10.0.99.0/24. Wenn du noch weitere Netze hast, die über die VPN sollen, dann sind noch weitere Zeilen nötig.
Wie erwähnt, iptables ist nicht meine größte Stärke, also im Zweifel hol dir anderswo diesbezüglichen Rat.
Die Masquerading Regel macht das, was auf pfSense Outbound NAT tut:# sense -> vserver iptables -t nat -I POSTROUTING 1 -s 10.8.0.0/24 -o ens192 -j MASQUERADEDie gilt aktuell nur für das VPN-Tunnelnetz. Dieses wird dann gar nicht mehr benötigt. Statt 10.8.0.0/24 kannst du also dein internes Netz reinschreiben. Deine pfSense Outbound NAT Regel lässt vermuten, dass das 10.0.99.0/24 ist.
Du hast aber von verschiedenen Netzen gesprochen. Wenn auch andere über den VPS geroutet werden, musst du die auch mit reinnehmen. Du kannst mehrere dieser Regeln setzen oder die Netzwerkmaske entsprechend erweitern.Die Outbound NAT Regel auf der pfSense wird dann nicht mehr benötigt.
Falls du ausgehende Verbindungen über die VPN routen möchtest (könnte bei Spielen erforderlich sein), musst du das per Policy Routing Regeln machen. Ich glaube aber gelesen zu haben, das hast du bereits gemacht.
Dann musst du noch die Weiterleitung anpassen:
#vserver -> sense iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 10.8.0.2:80Hier dann als Ziel deinen Webserver. Und dann noch weitere Regeln für die übrigen Dienste.
Und jetzt musst du dieses beachten:
@viragomann said in Public IPv4/IPv6 via VPN Tunnel:Achte darauf, dass nur Regeln auf dem speziell hinzugefügten VPN-Interface auf die eingehenden Verbindungen zutreffen, also keine auf dem OpenVPN Tab und keine Floating!
Grund dafür ist, du hast nun mehre Interfaces, an welchen Pakete aus dem WWW ins System kommen, Multi-WAN also. pfSense stellt hier das richtige Zurückrouten der Antwortpakete durch das "Reply-to" Flag sicher, mit welchem es eingehende Verbindungen markiert. Voraussetzung dafür ist, dass am eingehenden Interface ein Gateway eingerichtet ist (geschieht bei OpenVPN durch automatische Konfiguration, das Zuweisen eines Interfaces zur Instanz macht es eindeutig) und dass die Regel, die diese Verbindung erlaubt, nicht am Floating-Tab oder auf einer Interface-Group definiert ist.
Anhand der Filter-Regel wird diese Markierung für das entsprechende Gateway als Reply-to-Ziel gesetzt.
Regeln auf Floating- oder Interface-Group-Tabs können für mehere Interfaces gelten, daher wäre bei diesen das Interface (eigentlich das Gateway), an das zurückgesendet werden soll, nicht eindeutig.
Der OpenVPN Tab ist eine Interface-Gruppe, die sämtliche laufende OpenVPN Instanzen enthält.Ich weiß nicht, ob das nun verständlich ist, aber besser schaff ich es nicht.
Ich denke, das war dann schon alles. Versuch es mal.
