Wireguard port forward zweite public ip

    Moin, 8)


    vielleicht hat ja einer von euch eine Idee woran es scheitert.


    Folgendes habe einen root Server und möchte von 2 public IPS ports in mein Netzwerk leiten.


    Habe auf dem root Server und zuhause Debian aufgesetzt und die Grund Konfiguration gemacht, der Tunnel steht und mit IP tables kann ich ports weiterleiten an die gewünschte interne IP system zuhause. (Das Debian system zuhause fungiert als "Router" und leitet nur weiter)


    Allerdings gelingt mir das nicht mit der anderen Public IP

    Habe die IP in der /etc/network/interfaces eingetragen so wie es im netcup wiki steht mit z.B. ens3, ens3:1 usw natürlich das Gateway und so angepasst auf mein system.


    Mit dem Befehl ip a tauchen auch die IP Adressen zusammen mit dem interface auf.


    Habe dann versucht in der WG config die vorhandenen regeln zu kopieren und anzupassen auf das neue interface + andere IP im Heimnetz. Ohne Erfolg.


    Hatte auch versucht das zweite Gateway anzugeben von der zweiten IP in der Netzwerk config.

    Wahrscheinlich fehlt mir eine statische Route für die andere IP?


    Wenn der normale wireguard Tunnel mit der alten Konfiguration steht und ich mich dann verbinde mit der zweiten public IP dann geht das auch.


    Also ich kann mich dann mit beiden public IPS an dem selben Dienst anmelden. Obwohl die IP tables anders eingerichtet sind.


    Bei bedarf schicke ich mal alle config files usw. :P


    MfG


    Chrysen

  • Go to Best Answer
    Quote from Chrysen

    Habe die IP in der /etc/network/interfaces eingetragen so wie es im netcup wiki steht mit z.B. ens3, ens3:1 usw natürlich das Gateway und so angepasst auf mein system.

    Gateway angepasst? Die zweite IP wird doch auf die erste geroutet. Da ändert sich nichts am Gateway. Die 2. IP hat ja üblicherweise auch Subnetzmaske /32. ens3:1 macht man ja häufig auch nicht mehr, sondern weist die IPs direkt dem Hauptinterface zu. Das sollte aber für deinen Anwendungsfall keinen Unterschied machen.


    Quote from Chrysen

    Habe dann versucht in der WG config die vorhandenen regeln zu kopieren und anzupassen auf das neue interface + andere IP im Heimnetz. Ohne Erfolg.

    Ganz ehrlich: Ich hätte nicht erwartet, dass dies 2. IP überhaupt einen Einfluss auf die WG conf hat. An den Allowed IPs ändert sich ja nichts, da du ja eh natten musst.


    Vielleicht hab ich aber auch das Problem nicht richtig verstanden.Du willst von zwei öffentlichen IPs Ports in ein Heimnetz leiten, richtig? Das geht problemlos über einen Tunnel.

    ja genau, möchte von zwei öffentlichen IPs Ports in mein Heimnetz öffnen.


    hier einmal die iptables regeln aus der Wireguard config, die funktionieren für die Haupt IP.


    Es wird erfolgreich der Port 8000 udp und tcp geöffnet.


    PostUp = iptables -A FORWARD -i ens3 -o wg0 -j ACCEPT

    PostUp = iptables -A FORWARD -i wg0 -o ens3 -j ACCEPT

    PostUp = iptables -t nat -A PREROUTING -i ens3 -p udp -m multiport --dport 8000 -j DNAT --to 192.168.1.21

    PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE


    PostUp = iptables -A FORWARD -i ens3 -o wg0 -j ACCEPT

    PostUp = iptables -A FORWARD -i wg0 -o ens3 -j ACCEPT

    PostUp = iptables -t nat -A PREROUTING -i ens3 -p tcp -m multiport --dport 8000 -j DNAT --to 192.168.1.21

    PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE


    PostDown = iptables -D FORWARD -i ens3 -o wg0 -j ACCEPT

    PostDown = iptables -D FORWARD -i wg0 -o ens3 -j ACCEPT

    PostDown = iptables -t nat -D PREROUTING -i ens3 -p tcp -m multiport --dport 8000 -j DNAT --to 192.168.1.21

    PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE


    PostDown = iptables -D FORWARD -i ens3 -o wg0 -j ACCEPT

    PostDown = iptables -D FORWARD -i wg0 -o ens3 -j ACCEPT

    PostDown = iptables -t nat -D PREROUTING -i ens3 -p udp -m multiport --dport 8000 -j DNAT --to 192.168.1.21

    PostDown = iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE


    oder muss man wenn man die anderen ips nutzen will direkt mit diesen arbeiten und nicht mit dem Interface ens3 ?

    • Best Answer

    Meines Erachtens ist das Regelset kompletter Unsinn, und die entscheidenden sind auch syntaktisch falsch.


    Zunächst braucht jede Regel nur 1x drin zu sein. Einmal "iptables -A FORWARD -i ens3 -o wg0 -j ACCEPT" reicht. Wobei ich das Forwarding nicht so uneingeschränkt erlauben würde, sondern eher eine Regel für die Antworten auf etablierte Verbindungen und dann port-spezifsche Regeln nutzen würde. Dann macht "multiport" nur Sinn, wenn es auch mehrere Ports in der Regel gibt. Und bei DNAT muss man einen Zielport eingeben. Bei mehreren öffentlichen IPs macht es ggf. Sinn, die mit anzugeben, weil ja vielleicht das Ziel der zweiten IP anders sein soll, als das der ersten (wofür braucht man sonst zwei öffentliche IPs?).


    Ein korrektes Beispiel sähe für mich so aus:

    Code
    iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i ens3 -p tcp --dport 8080 -d 192.168.1.21 -j ACCEPT
iptables -t nat -A PREROUTING -i ens3 -d <öffentliche IP 1> -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.21:8080

iptables -A FORWARD -i ens3 -p tcp --dport 8080 -d 192.168.1.22 -j ACCEPT
iptables -t nat -A PREROUTING -i ens3 -d <öffentliche IP 2> -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.22:8080

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ens3 -j MASQUERADE

    So leitest du Port 8080 von deiner ersten öffentlichen IP auf 192.168.1.21 weiter, und von der zweiten öffentlichen IP auf 192.168.1.22. Außerdem erlaubst du Antworten auf etablierte Verbindungen. Das ganze für UDP dann synonym.

    Werde das morgen mal testen vielen dank schonmal dafür.

    Bin schon n paar Tage dran weil ich des mit dem ens3:1 usw getestet hab und das nicht so recht wollte.

    Und hatte die Config halt kopiert und vervierfacht, es sollte ja nicht so schlimm sein wenn was doppelt ist. (Außer natürlich die Übersicht wenn Wireguard nach dem starten die Einträge wg.conf neu sortiert


    Werde dann berichten 8o

    Quote from Chrysen

    Und hatte die Config halt kopiert und vervierfacht, es sollte ja nicht so schlimm sein wenn was doppelt ist.

    Falsch. Bei iptables ist die Reihenfolge der Regeln von essentieller Bedeutung, da sie der Reihe nach abgearbeitet werden und bei einem Match die Abarbeitung beendet wird. man sollte sich sehr genau überlegen, welche Regel wo steht.

  • Chrysen

    Selected a post as the best answer.

  • Chrysen

    Selected a post as the best answer.

    Mh, war wohl doch etwas zu voreilig,

    aus irgendeinem Grund geht es nicht mehr.


    Habe mal die Wireguard Config Files angehängt und die Ausgabe von ip addr.


    Wahrscheinlich war gestern noch eine iptable Regel aktiv zusammen mit den neuen.


    habe natürlich auch neu gestartet und zich Möglichkeiten getestet sowie den Server auch komplett neu installiert.


    Die alten Regeln alleine Funktionieren noch so wie vorher, also der Tunnel steht und funktioniert auch soweit.


    Der Wireguard Client dient nur dazu um die Anfragen von außen auf die Endgeräte zu lassen und macht sonst nix.



    Server Config



    Client Config:


    Quote from Chrysen

    Mh, war wohl doch etwas zu voreilig,

    aus irgendeinem Grund geht es nicht mehr.

    Was ging denn mal? Nach dem "ich werde es testen" kam ja nichts mehr.


    Der Client macht NAT und leitet nicht sein Internet über den Tunnel. Hm. Da müsste man jetzt noch mal genauer hinsehen. Kannst du dir mal mit tcpdump ansehen, wie die Pakete den VPN Client in Richtung LAN verlassen? Also vor allem Quell- und Ziel-Adresse?

    Also gestern konnte ich über beiden öffentlichen IPs auf zwei verschiedene Clients im Heimnetz zugreifen mit dem selben Port.


    und mit der alten Regel geht es zumindest über die primäre öffentliche IP


    PostUp = iptables -A FORWARD -i eth0 -o wg0 -j ACCEPT

    PostUp = iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT

    PostUp = iptables -t nat -A PREROUTING -i eth0 -p tcp -m multiport --dport 8080 -j DNAT --to 192.168.1.22

    PostUp = iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE


    Also die Fritzbox hat die 192.168.10.1

    Der Wireguard Client hat die 192.168.1.10 und ist noch hinter einer pfsense weil ich die Netzwerke halt getrennt halten möchte soweit.


    Hier ein Auschnitt aus dem tcpdump

    es wurde ein Ping vom Server zu dem Gerät hinter dem Wireguard Client gemacht


    Hier kann man auch schön den Verlauf sehen.

    Jetzt hast du mich völlig verwirrt.


    Quote from Chrysen

    Also die Fritzbox hat die 192.168.10.1

    Oha. Wo kommt das Netz denn plötzlich her? Davon war bislang überhaupt noch nie die Rede. Spielt das eine Rolle in dem VPN Setup?


    Quote from Chrysen

    es wurde ein Ping vom Server zu dem Gerät hinter dem Wireguard Client gemacht

    Das Testszenario hilft natürlich nicht weiter. Von einem kommt das Paket direkt vom Server, zum anderen gibt es für Ping keine FORWARD Regel (die gab es gestern noch, in den neuen Regeln nicht mehr). Es sollte schon ein Zugriff auf einen weitergeleiteten Port sein, den du testest, um die komplette Kette zu überprüfen.

    Nein wollte das andere netz nur mal erwähnt lassen. Die Pfsense hängt an der Fritzbox, und hinter der pfsense ist der Wireguard Client und die anderen Netzwerkteilnehmer.


    Also bei einem tcpdump auf das Wireguard Interface mit der neuen Regel passiert nichts.


    bei der altern Regel sieht das Ergebnis so aus. Der Port wurde zum Test auf ein SSH Server gelegt.


    Quote from Chrysen

    Also bei einem tcpdump auf das Wireguard Interface mit der neuen Regel passiert nichts.

    Die Aussage lässt knapp eine Millionen unterschiedliche Interpretationen zu. Auf dem Server? Auf dem Client? Von außen? Durch den Tunnel?


    Quote from Chrysen

    bei der altern Regel sieht das Ergebnis so aus. Der Port wurde zum Test auf ein SSH Server gelegt.

    Was für ein Ergebnis? Ist das eine Weiterleitung komplett durch den Pfad? Dabei ist NAT auf Client-Seite aktiv? Von SSH sieht man da übrigens nichts, das ist Port 8080. Vielleicht solltest du dir angewöhnen, tcpdump mit "-n" aufzurufen, das macht es übersichtlicher.

    Und wie sieht es mit der neuen Regel aus?

    Achso, also wenn ich per ssh von außen über die öffentliche IP Zugreifen möchte passiert bei dem tcpdump auf dem wireguard interface des Clients nichts bei der neuen Konfiguration.


    bei der alten Konfiguration mit tcpdump -n auf dem Wireguard interface des Client kommt das, jetzt kann man auch den richtigen Port sehen.



    und wenn ich versuche mit der neuen Konfiguration mich von außen auf eine öffentliche IP zu verbinden bekomme ich bei einem tcpdump auf dem Wireguard Interface auf dem Server folgendes:


    Also für mich sieht das so aus als wenn der Server gemäß iptable auf die richtige IP+Port weiterleitet.

    Fehlt vielleicht noch eine Regel ?

    Code
    Server Wireguard tcpdump neue config

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wgtest, link-type RAW (Raw IP), snapshot length 262144 bytes
16:29:36.011218 IP xxx.xxx.xxx46.21490 > 192.168.1.21.8080: Flags [S], seq 4184510097, win 65535, options [mss 1460,sackOK,TS val 217848406 ecr 0,nop,wscale 10], length 0
16:29:37.017098 IP xxx.xxx.xxx46.21490 > 192.168.1.21.8080: Flags [S], seq 4184510097, win 65535, options [mss 1460,sackOK,TS val 217849413 ecr 0,nop,wscale 10], length 0
16:29:39.065034 IP xxx.xxx.xxx46.21490 > 192.168.1.21.8080: Flags [S], seq 4184510097, win 65535, options [mss 1460,sackOK,TS val 217851461 ecr 0,nop,wscale 10], length 0
16:29:43.097114 IP xxx.xxx.xxx46.21490 > 192.168.1.21.8080: Flags [S], seq 4184510097, win 65535, options [mss 1460,sackOK,TS val 217855493 ecr 0,nop,wscale 10], length 0
16:29:51.417057 IP xxx.xxx.xxx46.21490 > 192.168.1.21.8080: Flags [S], seq 4184510097, win 65535, options [mss 1460,sackOK,TS val 217863812 ecr 0,nop,wscale 10], length 0



    Nein das ist so ok, bei der Regel die Funktioniert habe ich nachher auch eth0 genutzt, wahrscheinlich geht beides wie man auf den Bildern sehen kann.


    Ich ändere das ganze mal trotzdem auf ens3 als test

    Also wenn ens3 genutzt wird bricht der sofort die Verbindung ab wenn man versucht sich von außen per ssh zu verbinden, und bei dem tcpdump auf der WIreguard schnittstelle des Servers kommt kein output.

    also eth0 sollte demnach schon stimmen

    ja da gibt es einen sichtbaren unterschied, bei der neuen config zeigt der die Route direkt an von meiner externen IP zu der internen IP von dem ssh Server

    bei der alten config sieht man nur den Traffic zwischen dem Wireguard interface und dem Heimnetz.


    Fehlt vielleicht eine FORWARD Regel auf das wg interface ?


    Code
    neue config

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wgtest, link-type RAW (Raw IP), snapshot length 262144 bytes
17:53:56.170909 IP xxx.xxx.xxx.67.62864 > 192.168.1.21.8080: Flags [S], seq 3668390752, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:53:57.185702 IP xxx.xxx.xxx.67.62864 > 192.168.1.21.8080: Flags [S], seq 3668390752, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:53:59.191086 IP xxx.xxx.xxx.67.62864 > 192.168.1.21.8080: Flags [S], seq 3668390752, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:54:03.197071 IP xxx.xxx.xxx.67.62864 > 192.168.1.21.8080: Flags [S], seq 3668390752, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:54:11.205399 IP xxx.xxx.xxx.67.62864 > 192.168.1.21.8080: Flags [S], seq 3668390752, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0


    glaube jetzt funktioniert das

    habe die Regel folgendermaßen geändert


    PostUp = iptables -A FORWARD -i eth0 -p tcp --dport 8080 -d 192.168.1.21 -j ACCEPT

    PostUp = iptables -t nat -A PREROUTING -i eth0 -d xxx.xxx.xxx.12 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.21:8080

    PostUp = iptables -A FORWARD -i eth0 -p udp --dport 8080 -d 192.168.1.21 -j ACCEPT

    PostUp = iptables -t nat -A PREROUTING -i eth0 -d xxx.xxx.xxx.12 -p udp --dport 8080 -j DNAT --to-destination 192.168.1.21:8080

    PostUp = iptables -A FORWARD -i eth0 -p tcp --dport 8080 -d 192.168.1.22 -j ACCEPT

    PostUp = iptables -t nat -A PREROUTING -i eth0 -d xxx.xxx.xxx.95 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.22:8080

    PostUp = iptables -A FORWARD -i eth0 -p udp --dport 8080 -d 192.168.1.22 -j ACCEPT

    PostUp = iptables -t nat -A PREROUTING -i eth0 -d xxx.xxx.xxx.95 -p udp --dport 8080 -j DNAT --to-destination 192.168.1.22:8080

    PostUp = iptables -t nat -A POSTROUTING -o wg10 -j MASQUERADE

    PostDown = iptables -D FORWARD -i eth0 -p tcp --dport 8080 -d 192.168.1.21 -j ACCEPT

    PostDown = iptables -t nat -D PREROUTING -i eth0 -d xxx.xxx.xxx.12 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.21:8080

    PostDown = iptables -D FORWARD -i eth0 -p udp --dport 8080 -d 192.168.1.21 -j ACCEPT

    PostDown = iptables -t nat -D PREROUTING -i eth0 -d xxx.xxx.xxx.12 -p udp --dport 8080 -j DNAT --to-destination 192.168.1.21:8080

    PostDown = iptables -D FORWARD -i eth0 -p tcp --dport 8080 -d 192.168.1.22 -j ACCEPT

    PostDown = iptables -t nat -D PREROUTING -i eth0 -d xxx.xxx.xxx.95 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.22:8080

    PostDown = iptables -D FORWARD -i eth0 -p udp --dport 8080 -d 192.168.1.22 -j ACCEPT

    PostDown = iptables -t nat -D PREROUTING -i eth0 -d xxx.xxx.xxx.95 -p udp --dport 8080 -j DNAT --to-destination 192.168.1.22:8080

    PostDown = iptables -t nat -D POSTROUTING -o wg10 -j MASQUERADE



    Also oben gelöscht und unten angepasst. bestimmt gibt es noch verbesserungspotential.

    Komme so auf jeden Fall auf beide Maschinen per ssh drauf auf demselben Port von zwei verschiedenen öffentlichen IPs.

    Ja, was du jetzt halt noch machst, ist ein Masquerade auf den VPN Traffic. Damit kommen in deinem Heimnetz keine Pakete von öffentlichen IPs an, die dein Heimnetzgerät dann natürlich über seine Default-Route beantworten würde. Das wird nicht klappen.


    Dennoch würde ich das Forwarding ins Heimnetz einschränken, schon aus Sicherheitsgründen.