5
OpenVPN Client als Gateway im Netzwerk für weitere Geräte
Moin,
ich versuche seit Wochen die Öffentliche IP Adresse eines VPS Server bei Strato/Netcup/Hetzner zu meiner Sophos XG Home zu routen.
Ich habe auf den vServer bei Strato ein OpenVPN Server installiert. Die Verbindung baut bei mir zuhause eine extra VM auf. Dieses funktioniert auch soweit. Die VM geht über den VPN Server ins internet. Nun möchte ich gerne das andere Geräte im Netzwerk ebenfalls über die VPN-VM rausgehen können.
In der Sophos habe eine SD-WAN Route angelegt die sagt das zum Beispiel https://myip.is via 172.16.x.250 (die VPN-VM) gehen soll.
Das hat ebenfall schon geklappt. Eine ICMP Anfrage geht auch über den Tunnel raus. Die Antwort von dem Webserver geht nur bei dem VServer bei Strato ein und wird nicht durch den Tunnel zu dem anfragenden Gerät geroutet.
Folgende iptables Einstellungen habe ich auf der VPN-VM angelegt:
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ens34 -j MASQUERADE
iptables -A FORWARD -i ens34 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o ens34 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Unter /etc/sysctl.conf habe ich auch net.ipv4.ip_forward auf 1 gestellt ( net.ipv4.ip_forward=1)
Vieleicht hat jemand von euch noch eine Idee.
ich versuche seit Wochen die Öffentliche IP Adresse eines VPS Server bei Strato/Netcup/Hetzner zu meiner Sophos XG Home zu routen.
Ich habe auf den vServer bei Strato ein OpenVPN Server installiert. Die Verbindung baut bei mir zuhause eine extra VM auf. Dieses funktioniert auch soweit. Die VM geht über den VPN Server ins internet. Nun möchte ich gerne das andere Geräte im Netzwerk ebenfalls über die VPN-VM rausgehen können.
In der Sophos habe eine SD-WAN Route angelegt die sagt das zum Beispiel https://myip.is via 172.16.x.250 (die VPN-VM) gehen soll.
Das hat ebenfall schon geklappt. Eine ICMP Anfrage geht auch über den Tunnel raus. Die Antwort von dem Webserver geht nur bei dem VServer bei Strato ein und wird nicht durch den Tunnel zu dem anfragenden Gerät geroutet.
Folgende iptables Einstellungen habe ich auf der VPN-VM angelegt:
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ens34 -j MASQUERADE
iptables -A FORWARD -i ens34 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o ens34 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
Unter /etc/sysctl.conf habe ich auch net.ipv4.ip_forward auf 1 gestellt ( net.ipv4.ip_forward=1)
Vieleicht hat jemand von euch noch eine Idee.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 6764763853
Url: https://administrator.de/contentid/6764763853
Printed on: May 5, 2024 at 01:05 o'clock
5 Comments
Latest comment
Das Problem ist das du die am vServer eingehenden Pakete outbound auf eine OpenVPN Tunnel IP NATen musst, damit die Endgeräte in deinem Heimnetz diese als Zieladresse "sehen" um sie wieder in den Tunnel zum vServer rückrouten zu können. Ansonsten würden diese Pakete durch den Heimrouter direkt wieder ins Internet geroutet werden.
Diese Forenthreads beschreiben die Thematik:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP
Ein Wireshark Trace würde auch dir hier helfen.
Nebenbei gefragt: Warum setzt du solch mehr als schlecht performantes und wenig skalierendes VPN Protokoll wie OpenVPN ein? Eigentlich eher kontraproduktiv.
Statt dieser Frickelei mit der VM könntest du die Sophos oder auch FritzBox direkt per IPsec VPN an den vServer hängen was die deutlich besser, performantere und Resourcen sparende Lösung wäre.
Ein hiesiges Forenturotial beschreibt dir die einfache Lösung dafür Schritt für Schritt inkl. richtiger NAT Regeln auf dem vServer.
Sollte dir das zu anspruchsvoll sein wäre als 2te Wahl Wireguard ebenfalls besser.
Diese Forenthreads beschreiben die Thematik:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP
Ein Wireshark Trace würde auch dir hier helfen.
Nebenbei gefragt: Warum setzt du solch mehr als schlecht performantes und wenig skalierendes VPN Protokoll wie OpenVPN ein? Eigentlich eher kontraproduktiv.
Statt dieser Frickelei mit der VM könntest du die Sophos oder auch FritzBox direkt per IPsec VPN an den vServer hängen was die deutlich besser, performantere und Resourcen sparende Lösung wäre.
Ein hiesiges Forenturotial beschreibt dir die einfache Lösung dafür Schritt für Schritt inkl. richtiger NAT Regeln auf dem vServer.
Sollte dir das zu anspruchsvoll sein wäre als 2te Wahl Wireguard ebenfalls besser.
Nebenbei gefragt: Warum setzt du solch mehr als schlecht performantes und wenig skalierendes VPN Protokoll wie OpenVPN ein?
Naja, jedes OpenVPN ist deutlich schneller als eine Fritzbox mit VPN.
Aber ja, die Frage ist berechtigt. Ich würde als VPN Server die Sophos Box verwenden, anstatt dahinter eine VM dafür werkeln zu lassen, dann bleibt das Routing zentral im Sophos.
Auch auf der Strato Seite könntest du ein Sophos installieren. Dann kannst du es sogar bequem über RED Tunnel lösen.
ist deutlich schneller als eine Fritzbox mit VPN.
So pauschal lässt sich das nicht sagen, denn das 7.5er Release hat da einen deutlichen Schub nach oben gebracht. Generell hast du aber Recht das die dafür FB ungeeignet ist wenn man schon eine Sophos betreibt.Für den TO in seinem o.a. Design aber auch irrelevant, denn er würde das VPN ja immer mit der Sophos machen wie du ja auch schon richtig sagst. Die Frickelei mit der VM ist völlung unnötig und auch sehr schlechtes VPN Design weil der TO so ungeschützten Internet Traffic in sein lokales LAN per Port Forwarding senden muss. Ein sicheres VPN Design sieht anders aus...ganz besonders wenn man eine Sophos sein eigen nennt.
Von daher ist auch vollkommen unverständlich wenn man solche gute und sinnvolle Hardware betreibt die das alles von sich aus mit deutlich besserer Performance kann warum man dann noch on Top solche dann überflüssige OpenVPN Frickelei macht?! Aber heute ist ja wieder Freitag! 🐟😉
Die Sophos auf der Strato Seite ist unnötig, denn das kann ein simples apt install strongswan deutlich einfacher und besser. Nebenbei werkelt auf der Sophos ja auch nix anderes als der IPsec Charon Daemon. Wozu also die überflüssige Mühe?! 😉
Ja, ein IPSec reicht auf der Strato Seite. Ich habe mich eben für ein Sophos entschieden, damit die Verwaltung die Gleiche bleibt, wie zu Hause auch. Auch wollte ich nicht, dass der (bei mir der Hetzner-) Server das VPN direkt annimmt. Das erledigt die Sophos VM und der Server ist von der Aussenwelt isoliert, bis auf die VPN Portdurchreichung zur Sophos VM. Der Server hat dann aus der Sophos VM eine eigene interne Netzwerkschnittstelle erhalten, die durch Sophos verwaltbar ist.
Vielen Dank für euere Antworten.
Der Hautggrund warum ich kein IPSec verwenden möchte ist, das die Sophos dann das dopplete an Strom verbraucht.
Ich habe einen NUC mit einem i5, 2TB NVMe und 64GB RAM und 2 Nics mit ESXI 8.0 am laufen. Dort sind akteull 5 VMs am laufen. Auch die Sophos ist eine VM.
Der aktuelle Verbauch liegt ohne IPSec mit aktiver OpenVPN Verbindung bei 28W mit IPSec über 50W.
Die Performance via OpenVPN reicht mir für meine zwecke vollkommen aus. Dieser soll hauptsächlich für SMTP versand dienen und eingehende HTTPS anfragen.
Die Provider listen ja leider die IP Adressen aus Privattarifen auf die SPAMHAUS liste ....
Der Hautggrund warum ich kein IPSec verwenden möchte ist, das die Sophos dann das dopplete an Strom verbraucht.
Ich habe einen NUC mit einem i5, 2TB NVMe und 64GB RAM und 2 Nics mit ESXI 8.0 am laufen. Dort sind akteull 5 VMs am laufen. Auch die Sophos ist eine VM.
Der aktuelle Verbauch liegt ohne IPSec mit aktiver OpenVPN Verbindung bei 28W mit IPSec über 50W.
Die Performance via OpenVPN reicht mir für meine zwecke vollkommen aus. Dieser soll hauptsächlich für SMTP versand dienen und eingehende HTTPS anfragen.
Die Provider listen ja leider die IP Adressen aus Privattarifen auf die SPAMHAUS liste ....
