OPNsense mit Deutsche Glasfaser DS-Lite und VPS Wireguard Tunnel im Tunnel... Sinnvoll?

[runnerschreck92]

Moin Community,

ich bin seit kurzem Besitzer einer Glasfaserleitung der deutschen Glasfaser.
Wie bekannt ist hat man mit diesen Anschluss ja leider keine offentlich IPv4.

Da ich hier zu Hause mehrere NAS von Synology stehen habe, sowie diverse home Automatisierung welche nur lokal konfigurierbar sind, benötige ich zwingend eine VPN-Verbindung.
Ebenso den direkten Zugang (Portweiterleitung) zu einem das NAS (DSM) um einfach via Link ohne VPN Dateien zu teilen.

Mein Telekom Anschluss mit 175 Mbit läuft noch ziemlich genau ein Jahr.
Ich habe also genug Zeit mich in die Materie einzufuchsen.

Ich muss dazu sagen dass ich 2014/2015 genau die gleiche Thematik mit einem Unitymedia Anschluss hatte.
Dort bin ich damals verzweifelt wieder zurück auf einen VDSL 25 gewechselt.
Dort konnte ich nicht mal meine Damaligen Fritz Heizkörperthermostate aus der Ferne steuern

Stand jetzt läuft der Glasfaseranschluss parallel mit ein paar Test aufbauten.
Zum Testen hatte ich auch schon eine Fritzbox dran und habe mich dort erfreulicherweise via Wireguard von meinem Handy einwählen können.

Die Freude hielt leider nur bis zum ersten Hotelaufenthalt an. Da war mangels IPv6 im Hotel WLAN nämlich keine Verbindung mehr möglich.

Ergo habe ich mir in der letzten Zeit einen wahrscheinlich viel zu leistungsstarken AM4 Homeserver zusammengestellt und dort PFSense sowie OPNsense installiert.
Schlussendlich bin ich aktuell bei OPNsense hängen geblieben und habe mir dazu einen VPS bei OVH gebucht.

Hier habe ich auch eine Verbindung zum VPS Server via Wireguard aufbauen können. Zusätzlich habe ich auf dem VPS den Post-up und post down-eintrag für einen weiteren VPN Port (51821) erstellt.

Auf der Firewall habe ich eine zweite Wireguard Instanz angelegt und den entsprechenden Peer.
Als Endpunkt ist die IP des VPS angegeben mit der entsprechenden Portnummer.
Wie kann ich prüfen ob die Post up and post down-einträge sauber übernommen wurden und die Ports an das Gateway weitergeleitet werden?

Nun müsste ich ja eigentlich ein NAT erstellen welches diese Portnummer aus dem vps-vpn-netzwerk wieder auf das WAN leitet. So dass die Firewall auf die eingehende Kommunikation reagieren kann.

An der Stelle kann ich aber nur eine IP-Adresse angeben nicht das WAN-Interface.

Habt ihr Ideen? Oder generell eine andere Lösung.

Ich bin mir nicht ganz sicher ob die Firewall für den Heimgebrauch nicht etwas zu groß ist, und ich doch eher auf Ubiquity oder ähnliches wechseln sollte.
Mein Fritz System hier zu Hause ist auch schon über 5 Jahre alt, läuft aber tatsächlich absolut rockstable.
Müsste aber auch irgendwann mal ersetzt werden.


Vielen Dank vorab für eure Beiträge.
Leider mit dem Handy geschrieben, ggf. etwas schwierig zu lesen.

 

[till69]

und habe mir dazu einen VPS bei OVH gebucht

Dann würde schon ein einfacher Portmapper (IPv4 -> IPv6) ausreichen:
https://superuser.com/questions/1503996/socat-ipv4-to-ipv6-routing

 

[dudex13]

alternativ kannst du dir auch mal Tailscale anschauen, finde es irgendwie angenehmer von der Konfiguration und Handhabung , damit lassen sich auch Routen zu anderen Geräten oder Subnetze weiterleiten.

 

[Fard Dwalling]

Ich hatte dazu damals das hier eingerichtet:
https://www.feste-ip.net/dslite-ipv6-portmapper/universelle-portmapper/

Vielleicht kannst du dann auf das ganze VPS verzichten.

 

[runnerschreck92]

Dann würde schon ein einfacher Portmapper (IPv4 -> IPv6) ausreichen:
https://superuser.com/questions/1503996/socat-ipv4-to-ipv6-routing

Das muss ich mir mal ansehen.
DG hat aber wohl auch öffter mal das Problem das keine IPV6 verfügbar ist. Dann steht man ja auch wieder blöde da. Daher war meine Idee ausgehend eine Verbindung zum VPS aufzubauen.

alternativ kannst du dir auch mal Tailscale anschauen, finde es irgendwie angenehmer von der Konfiguration und Handhabung , damit lassen sich auch Routen zu anderen Geräten oder Subnetze weiterleiten.

Das kenne ich nicht, kann ich mir aber auch mal ansehen.

Ich hatte dazu damals das hier eingerichtet:
https://www.feste-ip.net/dslite-ipv6-portmapper/universelle-portmapper/

Vielleicht kannst du dann auf das ganze VPS verzichten.

Ja das wäre ja auch wie von till69 beschrieben.

 

[norKoeri]

[Mein Internet-Anbieter] hat aber wohl auch öfter mal das Problem das keine IPv6 verfügbar ist.

Das ist dann aber eher Fehler, also die Ausnahme. Oder hattest Du das selbst schon? Auf alle Eventualitäten kannst Du Dich kaum vorbereiten. Aber wenn Du auch in diese Richtung denken musst, würde ich eher ein Fallback/Failover über DSL und/oder Mobilfunk planen als auf IPv4-only zu gehen.

 

[Fard Dwalling]

Mobilfunk ist genauso schlecht. Ist auch Shared IP und teilweise IPv6.

 

[h00bi]

Das kenne ich nicht, kann ich mir aber auch mal ansehen.

mach das, ich bin mit Tailscale so zufrieden, dass ich das ggf. nächstes Jahr bei uns in der Firma einführen will.

 

[runnerschreck92]

Hallo zusammen,



ich muss das Thema nochmal hochholen.

Ich bin von der opnSense nun wieder auf die pfSense gewechselt.
Auch hier habe ich einen einwandfrei Funktionierenden WG-Tunnel zu meinem VPS.
Durch Weiterleitung auf dem Server kann ich auch auf interne Ports zugreifen. Das habe ich aber wieder deaktiviert, da ich via VPN in meinem Heimnetz terminieren möchte.


Tailscale ist sicher gut, aber ich habe in meinem Netzwerk immer wieder wechselnde Geräte, da möchte ich wie gesagt einfach via VPN reingehen und so arbeiten, als wäre ich zuhause.

Ich habe auf dem VPS für die zweite Wireguard Instanz auf der pfSense nun ein Post up / down für in meinem Fall Port 51821 angelegt.

Wireguard auf der pfSense konfiguriert. Und via Handy ausprobiert. Es gibt nun auch einen Handshake, aber es fließen keine Daten von der pfSense Richtung Handy.
Ich denke da muss NAT mäßig irgendwas gemacht werden, da die Daten ja nicht über den WAN rausgehen dürfen, sondern wieder in den S2S_VPS-Tunnel mit Port 51821 terminieren müssen.

Hat jemand einen Ahnung dazu?

Warum der ganze aufwand wieder?
Ich war letzte Woche wieder in einem Hotel, wo es nur IPv4 gab, demensprechend komme ich nicht via Wireguard auf mein tollen DS-Light Anschluss.

 

[Harrdy]

Wie sieht den die config deiner zwei Wireguard Instanzen aus?

Über Allowed IPs beschränkt du natürlich, welcher Traffic über den jeweiligen Tunnel darf.

Eine mögliche Variante wäre ein SNAT um den Traffic richtg zu maskieren, damit er trotz der Allowed IP Einstellung durch den Tunnel kommt. Noch dazu muss natürlich das Forwarding aktiv und erlaubt sein.

iptables -t nat -A POSTROUTING ! -s 10.0.80.1/24 -d 192.168.0.0/24 -o $wg -j SNAT --to 10.0.80.1

Ich nutze ein Bash Script um dies bei mehreren Interfaces zu realisieren. Hier ein Beispiel.

[Interface]
Address = 10.0.80.1/24
SaveConfig = False
Mtu = 1412
PrivateKey =
PostUp = /etc/wireguard/wga.sh -A wg_eltern
PostDown = /etc/wireguard/wga.sh -D wg_eltern

!/bin/bash

if [ $# -eq 0 ]; then
    echo "No parameters provided. Usage: $0 [-A|-D]"
    exit 1
fi

action=$1

case $action in
    -A)
        sysctl -w net.ipv4.ip_forward=1
        ;;
    -D)
        # Call down.sh script
        ;;
    *)
        echo "Invalid parameter. Usage: $0 [-A|-D]"
        exit 1
        ;;
esac

eth=ens3
wg=$2

iptables "$action" INPUT -i "$wg" -j ACCEPT

iptables "$action" FORWARD -i "$wg" -j ACCEPT
iptables "$action" FORWARD -i "$eth" -o "$wg" -m state --state ESTABLISHED,RELATED -j ACCEPT

if [ "$wg" == "wg_eltern" ]; then
        iptables -t nat "$action" POSTROUTING ! -s 10.0.80.1/24 -d 192.168.0.0/24 -o $wg -j SNAT --to 10.0.80.1
        iptables -t nat "$action" POSTROUTING ! -s 10.0.80.1/24 -o $wg -j MASQUERADE
fi

 

[DLMttH]

demensprechend komme ich nicht via Wireguard auf mein tollen DS-Light Anschluss.

Es wäre schön, wenn du deinen DG-Anschluss nicht immer DS-Lite nennen und drüber schimpfen würdest. Es ist kein DS-Lite, sondern CG-NAT.

Ich habe DS Lite (1&1) und komme, weil mein Provider seine Hausaufgaben gemacht hat, dank PCP über IPv4 in mein Heimnetz und musste dafür nicht mal selbst was einstellen, außer den Wireguard-Zugang nach Anleitung einzurichten.

 

[Bob.Dig]

Grundsätzlich könntest Du auch ein Portforward machen von dem VPS durch einen bestehenden WG-Tunnel auf einen weiteren WireGuard-Server auf der pfSense. Das würde Sinn machen, wenn auf dem VPS sonst nichts läuft.
Da deine Beschreibung unklar ist, war das vielleicht eh dein Plan, aber beurteilen kann man das so nicht.

 

[runnerschreck92]

Hi zusammen,

erstmal vielen Dank.
Ja CG-NAT ist es, das stimmt DLMttH.
Genau Bob.Dig, der VPS soll nur Ports weiterleiten sodass ich sauberen und zuverlässigen zugriff auf mein Netzwerk habe. Sonst wird der nichts machen.

Also ich habe auf dem VPS folgende Config:

Spoiler: Konfig VPS

[Interface]
PrivateKey = <XXXXXX>
Address = 10.100.90.0/31
SaveConfig = true
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
ListenPort = 51820
PreUp = iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 10.100.90.1
PreUp = iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 10.100.90.1
PreUp = iptables -t nat -A PREROUTING -i ens3 -p udp --dport 51821 -j DNAT --to-destination 10.100.90.1
PreUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostDown = iptables -t nat -D PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 10.100.90.1
PostDown = iptables -t nat -D PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 10.100.90.1
PostDown = iptables -t nat -D PREROUTING -i ens3 -p udp --dport 51821 -j DNAT --to-destination 10.100.90.1
PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE

[Peer]
PublicKey = <public Key der pfSense>
AllowedIPs = 10.100.90.0/31
PersistentKeepalive = 25

Auf meiner pfSense sieht es wie folgt aus. (siehe Screenshots)

 

[Bob.Dig]

Also allowed IPs sollte für das Tunnel-Netz immer /32 sein und nicht

10.100.90.0/31

Außerdem ist /31 generell keine Empfehlung, Du solltest stattdessen ein /30 nutzen.
Ich würde im Tunnel zu OVH auch nicht NATen, da müsstest Du also auch noch einiges ändern in Linux. Ziemlich viele Baustellen.

 

[runnerschreck92]

Okay das wusste ich schonmal nicht.
Ich habe das nun auf dem VPS sowie der pfSense geändert.
Das war aber ja nur eine Einstellung die den VPS <-> pfSense Tunnel betraf.
Dieser läuft wie zuvor. Anbei der Ping Auszug.


Was kann ich weiter tun?
Irgendwie ist es für mich noch ein Rätzel, der Groschen klemmt noch.
Wobei ich sagen muss, ich bin eher in der Hardware zuhause. Subnetze usw. puhh... man lernt aber dazu.
Das macht ja auch spaß.

 

[Bob.Dig]

Wenn Du jetzt einen /30 nutzt, dann kannst Du nicht weiter 10.100.90.0 als Adresse nutzen...
Zeig doch mal deine aktualisierte Linux Config, ohne NAT im Tunnel etc.
In pfSense würde ich in den Tunneln auch erst mal alles erlauben, später kann man die Regeln immer noch fest zurren.

 

[runnerschreck92]

Also irgentwie habe ich es jetzt wieder zum laufen bekommen...

Spoiler: Konfig VPS

Address = 10.100.90.1/30
SaveConfig = true
PreUp = iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 10.100.90.2
PreUp = iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 10.100.90.2
PreUp = iptables -t nat -A PREROUTING -i ens3 -p udp --dport 51821 -j DNAT --to-destination 10.100.90.2
PreUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -t nat -D PREROUTING -i ens3 -p tcp --dport 80 -j DNAT --to-destination 10.100.90.2
PostDown = iptables -t nat -D PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to-destination 10.100.90.2
PostDown = iptables -t nat -D PREROUTING -i ens3 -p udp --dport 51821 -j DNAT --to-destination 10.100.90.2
PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE
ListenPort = 51820
PrivateKey = XXX

[Peer]
PublicKey = XXX
AllowedIPs = 10.100.90.1/30
Endpoint = 94.31.84.144:51820

Mein Handy kann sich jetzt aber nicht mehr verbinden.
Wenn ich nat rauslösche, ist die Konfig fehlerhaft.

 

[Bob.Dig]

Ich sehe hier keine Verbesserung zu davor. Außerdem darf allowed IPs nie der eigenen Adresse des Interfaces entsprechen, das hast Du schon die ganze Zeit falsch. Hier muss die IP der pfSense drin stehen, also z.B. 10.100.90.2/32.

 

[runnerschreck92]

Ich habe die IP von der Schnittstelle der pfSense nun eingetragen. 10.100.90.2/32.
Was soll ich an der Konfig denn ändern?

Für heute höre ich auf...
Weitere 4 Stunden ohne Erfolg.

Ich möchte mich einfach nur von meinem Handy auf die Firewall einwählen.
Aus einem typischen Hotel wo nur ipv4 verfügbar ist.
Ich brauche keine üppige Performance, es soll einfach nur laufen.

 

[Harrdy]

Auch beim Port Forwarding durch den Tunnel brauchst du ein SNAT. Wenn du es so machst wie aktuell, kommen deine Anfragen beim VPS an, werden über den Tunnel an deine pfSense geschickt. Diese antwortet jedoch nicht über den Tunnel, sondern über ihr Standard-Gateway. Der Client, der die Anfrage gestellt hat, kann mit dieser Antwort nichts anfangen, da es keine passende Session für diese IP gibt. Mit SNAT laufen die Antworten wieder korrekt über den Tunnel zurück zu deinem VPS. Eine Alternative wäre, reply-to in der pfSense-Firewall zu manipulieren, damit die Antworten ohne SNAT wieder durch den Tunnel geleitet werden. Das Problem könntest du auch in einem tcpdump nachvollziehen, wenn du die Pakete sowohl am VPS als auch an der pfSense auf den entsprechenden Interfaces analysierst.