8
Port forwarding durch Wireguard Tunnel
Hallo zusammen,
ich brauch bei einer Herausforderung eine kleine Hilfestellung.
Ich hänge hier an einem kleinen Thema mit VPN WG Tunnel.
Kurze Beschreibung worum es geht.
Es geht um 2 Sites und in jeder Site einen Server, sagen wir einfach mal Site A ist ServerA und Site B ServerB.
ServerA hat ein Interface mit öffentlicher IP und benutzet die Firewall UFW auf dem System, ServerB ist in einem Intranet, keine Firewall auf dem Server direkt.
Ich würde gerne Ports von der öffentlichen IP über einen VPN WG Tunnel auf ServerB erreichen können.
Normal würde ich sagen ein klassisches port forwarding. (wäre schön wenn es das wäre)
Also Tunnel zwischen ServerA und ServerB steht. ServerA hat die IP 10.0.5.1 und ServerB die IP 10.0.5.2
Ich kann auch beide ServerA/B untereinander erreichen jeweils über 10.0.5.1 und 10.0.5.2.
Gehen wir mal davon aus ich möchte den Port 80 von ServerA auf ServerB durch den Tunnel forwarden.
Ich kann per curl 10.0.5.2 von ServerA die Textseite auf ServerB erreichen.
Beim Starten des WG Tunnel auf ServerA bekomme ich auch die Meldung
Das gleich auch auf ServerB
Nun hat ServerA ja noch eine UFW Firewall, hier habe ich folgende befehle noch hinzugefügt.
und in der Datei dies am ende beigefügt.
Nun hab ich noch in der Datei folgendes ein kommentiert.
An ServerB wurde keine weitere Konfiguration vorgenommen.
Leider bekomme ich nicht den port 80 über ServerA an ServerB weitergeleitet.
Ach so auf ServerA zeigt mir iptables -L folgendes zum forwarding:
und der UFW Status:
Ich füge hier noch ein kleines Bild bei, vielleicht weiß jemand wo mein Fehler liegt.
Danke vorab für die Hilfe.
Grüße
ich brauch bei einer Herausforderung eine kleine Hilfestellung.
Ich hänge hier an einem kleinen Thema mit VPN WG Tunnel.
Kurze Beschreibung worum es geht.
Es geht um 2 Sites und in jeder Site einen Server, sagen wir einfach mal Site A ist ServerA und Site B ServerB.
ServerA hat ein Interface mit öffentlicher IP und benutzet die Firewall UFW auf dem System, ServerB ist in einem Intranet, keine Firewall auf dem Server direkt.
Ich würde gerne Ports von der öffentlichen IP über einen VPN WG Tunnel auf ServerB erreichen können.
Normal würde ich sagen ein klassisches port forwarding. (wäre schön wenn es das wäre)
Also Tunnel zwischen ServerA und ServerB steht. ServerA hat die IP 10.0.5.1 und ServerB die IP 10.0.5.2
Ich kann auch beide ServerA/B untereinander erreichen jeweils über 10.0.5.1 und 10.0.5.2.
Gehen wir mal davon aus ich möchte den Port 80 von ServerA auf ServerB durch den Tunnel forwarden.
Ich kann per curl 10.0.5.2 von ServerA die Textseite auf ServerB erreichen.
Beim Starten des WG Tunnel auf ServerA bekomme ich auch die Meldung
iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens192 -j MASQUERADEiptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADEufw route allow on ens192 proto tcp to 10.0.5.2 port 80/etc/ufw/befor.rules*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i ens192 -p tcp --dport 80 -j DNAT --to-destination 10.0.5.2
-A POSTROUTING -o ens192 -j MASQUERADE
COMMIT/etc/ufw/sysctl.confnet/ipv4/ip_forward=1An ServerB wurde keine weitere Konfiguration vorgenommen.
Leider bekomme ich nicht den port 80 über ServerA an ServerB weitergeleitet.
Ach so auf ServerA zeigt mir iptables -L folgendes zum forwarding:
Chain ufw-user-forward (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere 10.0.5.2 tcp dpt:httpund der UFW Status:
ufw status
Status: active
To Action From
-- ------ ----
51822/udp ALLOW Anywhere
10.0.5.2 80/tcp ALLOW FWD Anywhere on ens192Ich füge hier noch ein kleines Bild bei, vielleicht weiß jemand wo mein Fehler liegt.
Danke vorab für die Hilfe.
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5313496253
Url: https://administrator.de/forum/port-forwarding-durch-wireguard-tunnel-5313496253.html
Ausgedruckt am: 28.12.2024 um 04:12 Uhr
8 Kommentare
Neuester Kommentar
Hier steht's
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP
Dein Problem ist das der Traffic mit einer externen IP beim Server B ankommt, und da dieser Antworten per Default über sein Default GW und nicht über den Tunnel rausschickt, so kommt es zu asymmetrischem Routing und keiner Verbindung. Also entweder ein SRC-NAT des Traffics an Server A in den Wireguard-Tunnel oder den Traffic per Tagging markieren und per Policy-Route zurück über den Tunnel schicken.
Btw. das Masquerading zwischen den Netzen braucht es übrigens nicht das ist ein Performance-Killer.
Gruß wurstel.
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP
Dein Problem ist das der Traffic mit einer externen IP beim Server B ankommt, und da dieser Antworten per Default über sein Default GW und nicht über den Tunnel rausschickt, so kommt es zu asymmetrischem Routing und keiner Verbindung. Also entweder ein SRC-NAT des Traffics an Server A in den Wireguard-Tunnel oder den Traffic per Tagging markieren und per Policy-Route zurück über den Tunnel schicken.
Btw. das Masquerading zwischen den Netzen braucht es übrigens nicht das ist ein Performance-Killer.
Gruß wurstel.
1
Und die gemeinen Fussfallen, die in solchem Jumphost Setups mit Port Forwarding lauern bei inbound NAT sollte man genau beachten! Dann kommt das auch sofort zum Fliegen:
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP
Der Fehler ist auch hier leider wieder das überflüssige NAT im Tunnel. Das Einzige was hier geNATet werden muss ist der Outbound Traffic an Server A ins Internet und der Inbound Port Forward Traffic an Server A. An Server B muss gar nichts geNATet werden das ist auch kontraproduktiv.
Das hiesige WG Tutorial beschreibt das.
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren
Routing zwischen zwei PfSense - Nutzung von public IP
Der Fehler ist auch hier leider wieder das überflüssige NAT im Tunnel. Das Einzige was hier geNATet werden muss ist der Outbound Traffic an Server A ins Internet und der Inbound Port Forward Traffic an Server A. An Server B muss gar nichts geNATet werden das ist auch kontraproduktiv.
Das hiesige WG Tutorial beschreibt das.
Hallo,
erstmal danke Ihr beiden, für die Antwort und Hilfestellung, ich werde mir mal die links durchlesen und und schauen ob ich weiter komme.
nochmal Danke.
erstmal danke Ihr beiden, für die Antwort und Hilfestellung, ich werde mir mal die links durchlesen und und schauen ob ich weiter komme.
nochmal Danke.
Hallo zusammen,
also ich habe es jetzt erstmal zum fliegen bekommen, nur schicke ich jetzt alles über den Tunnel also ServerB hat nun in der wg0.conf unter allowedip 0.0.0.0/0 stehen, ist unschön, aber vielleicht finde ich noch für Debian eine andere Lösung.
Mal ne kleine Frage, kann ich mal meine Konfiguration posten und vielleicht kann sich mal einer ansehen ob ihr irgendwie da zu viel drin habe?
Danke im Voraus.
Grüße
also ich habe es jetzt erstmal zum fliegen bekommen, nur schicke ich jetzt alles über den Tunnel also ServerB hat nun in der wg0.conf unter allowedip 0.0.0.0/0 stehen, ist unschön, aber vielleicht finde ich noch für Debian eine andere Lösung.
Mal ne kleine Frage, kann ich mal meine Konfiguration posten und vielleicht kann sich mal einer ansehen ob ihr irgendwie da zu viel drin habe?
Danke im Voraus.
Grüße
aber vielleicht finde ich noch für Debian eine andere Lösung.
Einfach nur einmal das WG Tutorial lesen und verstehen!Dort steht doch genau drin wie man ein sinnvolles Split Tunneling unter Wireguard einrichtet. Das was du da jetzt machst mit dem Gateway Redirect ist völlig kontraproduktiv und eine Sackgasse.
Tip: Einfach nur die relevanten IPs unter den Allowed IPs eintragen, dann klappts auch mit dem Split Tunneling! 😉
Es ist übrigens vollkommen wurscht ob Debian, Ubuntu, Arch, Windows oder MacOS. Die WG Konfiguration ist bekanntlich immer gleich und völlig unabhängig vom OS.
Danke, aber ich habe das bezüglich des forwadings gemacht damit die Pakete welche aus dem Internet zu ServerA kommen und er diese über den WG Tunnel an ServerB geschickt werden auch den Rückweg wieder finden.
Da ich das nun durch eure links verstanden habe, denke ich
Eure links und Erklärungen basierten auf pfsense oder opnsene bezüglich BINAT.
Und da mein System ein Debian ist, und ich nicht weiß wie ich dem System beim forwaden sagen kann das diese Pakete bitte wieder über den Tunnel zurück gehen sollen hatte ich das so eingestellt.
Es ist doch so, das ServerB die Pakete versucht über seinen eigenen Gateway zu antworten welches ins leere läuft.
Vielleicht stell ich mich auch nur ein wenig b..... an.
Bitte korrigiere mich wenn ich hier es doch nicht richtig verstanden habe.
Danke im Voraus für die Hilfe.
Da ich das nun durch eure links verstanden habe, denke ich
Eure links und Erklärungen basierten auf pfsense oder opnsene bezüglich BINAT.
Und da mein System ein Debian ist, und ich nicht weiß wie ich dem System beim forwaden sagen kann das diese Pakete bitte wieder über den Tunnel zurück gehen sollen hatte ich das so eingestellt.
Es ist doch so, das ServerB die Pakete versucht über seinen eigenen Gateway zu antworten welches ins leere läuft.
Vielleicht stell ich mich auch nur ein wenig b..... an.
Bitte korrigiere mich wenn ich hier es doch nicht richtig verstanden habe.
Danke im Voraus für die Hilfe.
Und da mein System ein Debian ist, und ich nicht weiß wie ich dem System beim forwaden sagen kann das diese Pakete bitte wieder über den Tunnel zurück gehen sollen hatte ich das so eingestellt.
Per iptables die eingehenden connections mit einem TAG versehen, dann eine weitere Routing-Table anlegen, in der Table das Default-GW auf den Wireguard-Tunnel legen und am Ende mit einer Routing-Rule (ip rule add) den vorhin getaggten Traffic über die neue Routing-Table leiten. Einfaches Policy-Routing .werden auch den Rückweg wieder finden.
Das ist die wenig intelligente Holzhammermethode die zwar klappt aber sämtlichen remoten Traffic in den Tunnel routet.Kollege @5175293307 hat es schon gesagt. Wenn du die Tutorials oben gelesen hast, ist der Trick ja das man den Port Forwarding Traffic an Server A auch inbound auf die Tunnel IP 10.0.5.1 DNATet (...oif tun0 masquerade). Damit bekommt der Traffic eine Tunnel Absender IP und der remote Webserver sendet die dann auch immer in den Tunnel zurück statt sie lokal an seinem Router direkt zu forwarden.
So ginge es etwas effizienter ohne die Holzhammermethode. 😉
