Public IPv4/IPv6 via VPN Tunnel

mike69

@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 infinite

Logs zu dieser Verbindung kann bei Bedarf nachgereicht werden.

JeGr

@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 :)

mike69

@jegr

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.

JeGr

@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...

viragomann

@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.

mike69

@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?

viragomann

@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.

mike69

@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?

viragomann

@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.

mike69

@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... :)

viragomann

@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!

JeGr

@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 ;)

viragomann

@jegr
Eingehende Verbindungen funktionieren auch mit einer einzigen VPN-Instanz nicht, wenn eine Regel am VPN-Tab sie zulässt.

JeGr

@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.

viragomann

@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.

mike69

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:80

Damit 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.

viragomann

@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.

mike69

@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....

viragomann

@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.

mike69

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.