Beiträge von Chrysen

  • Wireguard port forward zweite public ip

    so, hab grade mal folgende Regeln eingestellt


    SSH erlauben

    iptables -A INPUT -i eth0 -p tcp --dport zzzzz -m state --state NEW,ESTABLISHED -j ACCEPT

    iptables -A OUTPUT -o eth0 -p tcp --sport zzzzz -m state --state ESTABLISHED -j ACCEPT


    ---

    Ping von außen nach innen erlauben.

    iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

    iptables -A OUTPUT -p icmp --icmp-type echo-reply -j ACCEPT


    ---

    Ausgehend dns erlauben

    iptables -A OUTPUT -p udp -o eth0 --dport 53 -j ACCEPT

    iptables -A INPUT -p udp -i eth0 --sport 53 -j ACCEPT


    ---

    Wireguard freigeben

    iptables -A INPUT -i eth0 -p udp --dport xxx -j ACCEPT

    iptables -A OUTPUT -o eth0 -p udp --dport yyy -j ACCEPT



    dann habe ich noch per Default alles andere an In und Output gesperrt

    iptables -P INPUT DROP

    iptables -P OUTPUT DROP




    Sobald ich diese Regel auch noch ausführe klappt der Wireguard Tunnel nicht mehr, obwohl der Forward selbst ja freigegeben ist.

    iptables -P FORWARD DROP



    Und wenn ich jetzt eine Domain anpinge klappt das, aber wenn es eine IP ist ist nicht.

    Ist ja nicht kritisch, alles relevante funktioniert. Auch Systemupdates usw.

  • Wireguard port forward zweite public ip

    also braucht es noch eine input drop Regel für port 8080 für jede Portfreigabe.


    Dann werden sozusagen alle anfragen dieses Ports nicht mehr auf dem Server "verarbeitet" sondern direkt weitergeleitet.


    Oder direkt eine input drop Regel für alles und dann SSH freigeben.

  • Wireguard port forward zweite public ip

    Zitat von frank_m

    Genau. Man kann auch die Default Policy auf DROP stellen.


    Du musst unterscheiden zwischen INPUT und FORWARD. Für INPUT brauchst du den Wireguard Port, aber keine 8080 Regel. Für FORWARD brauchst du die Regeln für dein Heimnetz (8080 z.B.), aber keinen Wireguard Port.

    meine global alles zu blockieren außer die Ports die auch erreichbar sein sollen.


    Und der ssh port wurde geändert, und stimmt natürlich das, dass über ssh viel einfacher zu bedienen ist.

  • Wireguard port forward zweite public ip

    Also diese regeln funktionieren auch


    PostUp = iptables -A FORWARD -m state --state ESTABLISHED,RELATED -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 tcp --dport 8080 -d 192.168.1.21 -j ACCEPT

    PostUp = iptables -t nat -A POSTROUTING -o wg11 -d 192.168.1.21 -p tcp --dport 8080 -j SNAT --to-source 10.0.0.1


    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 udp --dport 8080 -d 192.168.1.21 -j ACCEPT

    PostUp = iptables -t nat -A POSTROUTING -o wg11 -d 192.168.1.21 -p udp --dport 8080 -j SNAT --to-source 10.0.0.1


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

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

    PostUp = iptables -t nat -A POSTROUTING -o wg11 -d 192.168.1.22 -p tcp --dport 8080 -j SNAT --to-source 10.0.0.1


    PostUp = iptables -t nat -A PREROUTING -i eth0 -d xxx.xxx.95 -p udp --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 POSTROUTING -o wg11 -d 192.168.1.22 -p udp --dport 8080 -j SNAT --to-source 10.0.0.1




    und zum abrunden sollte es doch reichen mit einer drop regel alle Ports die nicht benötigt werden zu sperren.

    glaub man kann das doch negieren und somit alles dicht machen außer z.b. 8080 + Wireguard selbst.

    dann kann man ja sogar den ssh Port dicht machen wenn man alles direkt über Wireguard macht.

    wenn man dann wirklich mal ssh braucht kann man ja per Netcup SCP über die Bildausgabe das manuell wieder aktivieren.

  • Wireguard port forward zweite public ip

    Genau, möchte natürlich nur einzelne Ports öffnen und nicht alle anfragen auf der öffentlichen IP weiterleiten.


    und bei dem Masquerade nimmt der die öffentliche IP mit Port 8080 und leitetet die Anfrage über Wireguard mit der IP 10.0.0.1 weiter mit einem zufälligen Port und in dem Paket ist dann der richtige Port enthalten damit der Wireguard Client weiß wohin das Paket dann muss. Somit kann man dann zweimal den Port 8080 von beiden öffentlichen IPs nutzen.


    Wenn man dann snat nutzen möchte im POSTROUTING dann muss man das dann für jede interne IP machen und braucht dann kein Masquerade mehr? So würde ich den Beitrag verstehen..

  • Wireguard port forward zweite public ip

    sorry verstehe den ersten Absatz nicht recht, werde nachher aber noch versuchen das was sicherer zu bei bekommen.


    Habe gelesen das die erste iptable gerne genommen wird wenn es einfach sein soll für eine Grundsicherung.


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


    Dann kann es doch eigentlich nur an der letzten Regel liegen.


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

  • Wireguard port forward zweite public ip

    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.

  • Wireguard port forward zweite public ip

    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


  • Wireguard port forward zweite public ip

    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

  • Wireguard port forward zweite public ip

    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



  • Wireguard port forward zweite public ip

    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.


  • Wireguard port forward zweite public ip

    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.

  • Wireguard port forward zweite public ip

    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:


  • Wireguard port forward zweite public ip

    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

  • Wireguard port forward zweite public ip

    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 ?

  • 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