OpenVPN port forwarding iptables

[DJannik]

Hallo zusammen,
und zwar habe ich einen OpenVPN Server auf meinem Debian 9 aufgesetzt, funktioniert soweit auch, nur würde ich jetzt gerne bestimmte Ports an einen Clienten weiterleiten.
Auf dem richtigen Weg bin ich auf jeden Fall, nur die Praxis sieht mal wieder anders aus

Internet-Link: ens3
OpenVPN: tun0
VPN-Client-Adresse: 10.8.0.2
Server-Host: OVH

Was ich bisher an iptables gemacht habe

VPN-Betrieb

Code: Alles auswählen

iptables -A INPUT -i ens3 -m state --state NEW -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o ens3 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i ens3 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE
iptables -A OUTPUT -o tun+ -j ACCEPT

Die Portweiterleitung

Code: Alles auswählen

iptables -t nat -A PREROUTING -i ens3 -p udp --dport 1500 -j DNAT --to-dest 10.8.0.2
iptables -t nat -A PREROUTING -i ens3 -p udp --dport 3005 -j DNAT --to-dest 10.8.0.2
iptables -t nat -A PREROUTING -i ens3 -p udp --dport 3101 -j DNAT --to-dest 10.8.0.2
iptables -t nat -A PREROUTING -i ens3 -p udp --dport 28960 -j DNAT --to-dest 10.8.0.2
iptables -t nat -A PREROUTING -i ens3 -p udp --dport 3478 -j DNAT --to-dest 10.8.0.2
iptables -t nat -A PREROUTING -i ens3 -p udp --match multiport --dports 27000:27030 -j DNAT --to-dest 10.8.0.2
iptables -t nat -A PREROUTING -i ens3 -p tcp --match multiport --dports 27015:27030 -j DNAT --to-dest 10.8.0.2

Noch ein paar Anmerkungen

• es ist mir schon fast peinlich, aber ALLE policys sind auf ACCEPT; macht da oben bestimmt was überflüssig, ich weiß, aber beschäftige mich erst seit paar Tagen mit iptables
• die oben aufgeführten Ports werden als filtered/open angezeigt, alle anderen Ports sind dennoch closed

Danke schon mal!!

[TomL]

dennoch werden die oben aufgeführten Ports immer noch als closed angezeigt wenn ich das über einen online Port-Checker überprüfe

Vielleicht verstehe ich die Frage falsch... aber von außen und über irgendeinen Online-Port-Checker sollte eigentlich nur Port 1194 offen sein.

[DJannik]

Vielleicht verstehe ich die Frage falsch... aber von außen und über irgendeinen Online-Port-Checker sollte eigentlich nur Port 1194 offen sein.

Ich dachte ich könnte mir es sparen, die Zeilen zu posten, da die default policy ja sowieso ACCEPT ist
aber folgende Regeln sind auch noch aktiv

Code: Alles auswählen

iptables -A INPUT -p udp --dport 1500 -j ACCEPT
iptables -A INPUT -p udp --dport 3005 -j ACCEPT
iptables -A INPUT -p udp --dport 3101 -j ACCEPT
iptables -A INPUT -p udp --dport 28960 -j ACCEPT
iptables -A INPUT -p udp --dport 3478 -j ACCEPT
iptables -A INPUT -p udp --match multiport --dports 27000:27030 -j ACCEPT
iptables -A INPUT -p tcp --match multiport --dports 27015:27030 -j ACCEPT

Ich habe das ganze grade nochmal überprüft und keine Ahnung was ich da gestern gemacht habe, aber die Ports um die es geht sind nicht closed sondern filtered/open
Alle anderen Ports, an denen ich nichts gemacht habe, werden mir aber als closed angezeigt
(habe den Post jetzt berichtigt)

Aber wie bekomme ich die Ports denn nun an meinen Clienten weitergeleitet?

[mat6937]

Aber wie bekomme ich die Ports denn nun an meinen Clienten weitergeleitet?

Du willst vom Server via VPN, lauschende Ports auf dem VPN-Client erreichen?
Dann brauchst Du auf deinem Server eine definierte Route via VPN-Interface in das (Nicht-VPN-)Subnetz deines Clienten.

[DJannik]

Du willst vom Server via VPN, lauschende Ports auf dem VPN-Client erreichen?
Dann brauchst Du auf deinem Server eine definierte Route via VPN-Interface in das (Nicht-VPN-)Subnetz deines Clienten.

Ja genau, wegen DSLite funktioniert das anders nicht. Ich verstehe was du meinst, aber wie setze ich das um?
Helfen mir die iptables Regeln oben so überhaupt weiter dann, also stimmen die überhaupt inhaltlich?

[mat6937]

Ich verstehe was du meinst, aber wie setze ich das um?
Helfen mir die iptables Regeln oben so überhaupt weiter dann, also stimmen die überhaupt inhaltlich?

Ich weiß jetzt nicht ob diese iptables-Regeln nützlich oder hinderlich sind.
Wenn es nicht funktioniert, dann kannst Du die iptables-Regeln der filter-table ja mal (temporär) löschen.

Versuch mal auf dem Server mit:

Code: Alles auswählen

route add -net 192.168.xxx.0 netmask 255.255.255.0 gw 10.8.0.x dev tun0

(oder gleichwertig).
Das Subnetz und die IP-Adresse des gw musst Du anpassen. Auf dem Client sollte mit iptables das richtige source-NAT (MASQUERADE) gesetzt sein. Danach machst Du einen Ping auf die interne IP-Adresse des Clienten und einen Portscan auf einen lauschenden TCP-Port.

[DJannik]

Auf dem Client sollte mit iptables das richtige source-NAT (MASQUERADE) gesetzt sein. Danach machst Du einen Ping auf die interne IP-Adresse des Clienten und einen Portscan auf einen lauschenden TCP-Port.

Ich hatte bisher kein Erfolg, mein Client ist auch Windows und nicht Linux. Route auf meinem Server ist gesetzt, bekomme den Clienten trotzdem nicht angepingt.
Weder über 10.8.0.2 noch über 192.168.0.50 (locale Client-IP)

Code: Alles auswählen

route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.8.0.2 dev tun0

das für meinen Server stimmt aber oder?

hab dann noch probiert nobind in der Client-config auszukommentieren, hat aber keine Veränderung mit sich gebracht, weiß auch nicht genau in welchen Fällen man diese braucht
Server-config enthält außerdem folgende Zeile

Code: Alles auswählen

push "redirect-gateway def1 bypass-dhcp"

aber das muss ja auch so sein.

Wie setze ich denn die richtige source-NAT auf dem Client?

[mat6937]

Route auf meinem Server ist gesetzt, bekomme den Clienten trotzdem nicht angepingt.
Weder über 10.8.0.2 noch über 192.168.0.50 (locale Client-IP)

Code: Alles auswählen

route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.8.0.2 dev tun0

das für meinen Server stimmt aber oder?

Wie sind auf deinem Server die Ausgaben von:

Code: Alles auswählen

ip a
route -n
iptables -nvx -L -t nat

?

[DynaBlaster]

Ich verstehe das Setup noch nicht. Port 27015 und Co sehen stark nach Half-Life-Gamserver und Co. aus. Letzterer läuft also auf dem Client mit der IP 192.168.0.50 bzw. 10.8.0.2?

Wo steht denn der OpenVPN-Server? Irgendwo im Internet oder hat der auch ne IP im Netz 192.168.0.0/24? Gibts nen dritten Recher, der sich da als VPN-Client verbindet und von dem aus die Ports 27015 und Co. auf dem Rechner 192.168.0.50/24 erreicht werden sollen?

Standardmässig ist nen OpenVPN-Server so konfiguriert, das der pro VPN-Verbindung /30er-Netze aufspannt und keine Client-to-Client-Kommunikation zulässt.

Sprich Client 1:
IP: 10.8.0.2/30
GW/VPN-Server-IP: 10.8.0.1/30
Network 10.8.0.0, Broadcast 10.8.0.3

Client 2:
IP 10.8.0.6/30
GW/VPN-Server-IP: 10.8.0.5/30
Network 10.8.0.4, Broadcast 10.8.0.7

usw..

Ich würde als erstes schauen, ob die Windows-Kiste bei aktivem VPN via 10.8.0.2 vom Debian-VPN-Server (10.8.0.1) pingbar ist . Ggf. die Windows-Firewall checken, durchaus möglich, das die das VPN-Netz als öffentlich und damit nicht als vertrauenswürdig erachtet. Das gleiche gilt für die Ports, die erreicht werden sollen. Firewall auf der Windows-Kiste? Lauschen die Serveranwendungen auf dem Window-Rechner überhaupt auf der dem VPN-Interface oder "binden" die sich nur an die 192.168.0.50?

[mat6937]

und zwar habe ich einen OpenVPN Server auf meinem Debian 9 aufgesetzt, funktioniert soweit auch, ...

Was genau meinst Du mit "funktioniert soweit auch" und wie hast Du das festgestellt?
Ist der Windows-Rechner (VPN-Client) dein Gerät? Kennst Du dich mit Windows aus?

[DJannik]

Wie sind auf deinem Server die Ausgaben von:

Code: Alles auswählen

ip a
route -n
iptables -nvx -L -t nat

Code: Alles auswählen

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:31:ea:54 brd ff:ff:ff:ff:ff:ff
    inet 51.12.12.12/32 brd 51.12.12.12 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::fxxx:3xxx:fxxx:exxx/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fd42:42:42:42::1/112 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::2d9e:8b5a:8a45:edaf/64 scope link flags 800
       valid_lft forever preferred_lft forever

Code: Alles auswählen

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         51.12.12.1     0.0.0.0         UG    0      0        0 ens3
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
51.12.12.1     0.0.0.0         255.255.255.255 UH    0      0        0 ens3

Code: Alles auswählen

iptables -nvx -L -t nat
Chain PREROUTING (policy ACCEPT 25458 packets, 1179649 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 16450 packets, 633457 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 193 packets, 18939 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 206 packets, 19530 bytes)
    pkts      bytes target     prot opt in     out     source               destination
    7525  1090695 MASQUERADE  all  --  *      ens3    10.8.0.0/24          0.0.0.0/0

Ich verstehe das Setup noch nicht. Port 27015 und Co sehen stark nach Half-Life-Gamserver und Co. aus. Letzterer läuft also auf dem Client mit der IP 192.168.0.50 bzw. 10.8.0.2?

Wo steht denn der OpenVPN-Server? Irgendwo im Internet oder hat der auch ne IP im Netz 192.168.0.0/24? Gibts nen dritten Recher, der sich da als VPN-Client verbindet und von dem aus die Ports 27015 und Co. auf dem Rechner 192.168.0.50/24 erreicht werden sollen?

Lauschen die Serveranwendungen auf dem Window-Rechner überhaupt auf der dem VPN-Interface oder "binden" die sich nur an die 192.168.0.50?

Bei der 192.168.0.0/24 hatte ich einen Denkfehler, hab das Routing inzwischen schon wieder entfernt, hat kein Sinn gemacht. Es gibt nur einen Clienten mit der lokalen IP 192.168.0.50. Der Client ist eben an einem DSLite Link und deswegen auch der Aufwand hier. Der Client bekommt im VPN-Netz die 10.8.0.2 zugewiesen. Der VPN-Server steht in Frankfurt und hat eine statische public IP. Mittlerweile kann ich sowohl den Clienten vom Server aus, als auch umgekehrt anpingen. Und ich schätze die binden sich nur an die 192.168.0.50, dachte aber das ist nicht schlimm, da ja ohnehin der gesamte Traffic über VPN läuft dann.

Was ich jetzt versucht habe und da hab ich jetzt auch nochmal was verändert, mit folgenden Befehlen die geöffneten Ports direkt an den Clienten weiterzuleiten. Das heißt wenn sich jemand an Port 28960 an meinem VPN verbindet, soll dieser direkt an meinem Client landen. Und das Spiel um was es geht ist übrigens MW2. Es ist kein eigener Server, das Spiel zeigt mir, wenn keine Ports geöffnet sind NAT:strict an, wenn ich die Ports über den Router ganz normal öffnen würde, würde sich das zu NAT:open ändern, was mir dann eben die Möglichkeit gibt, Spiele zu hosten.

Code: Alles auswählen

iptables -t nat -A PREROUTING -i ens3 -p udp --dport 28960 -j DNAT --to-destination 10.8.0.2:28960

Hier mal den einen Port als Beispiel, habe das natürlich für alle Ports jetzt mal so aufgeschrieben aber hab das alles auch oben in der iptables Ausgabe entfernt, Zwecks Überblick und weil ich nicht weiß ob das überhaupt richtig so ist.

[mat6937]

Bei der 192.168.0.0/24 hatte ich einen Denkfehler, hab das Routing inzwischen schon wieder entfernt, hat kein Sinn gemacht. Es gibt nur einen Clienten mit der lokalen IP 192.168.0.50. Der Client ist eben an einem DSLite Link und deswegen auch der Aufwand hier. Der Client bekommt im VPN-Netz die 10.8.0.2 zugewiesen.

Code: Alles auswählen

iptables -t nat -A PREROUTING -i ens3 -p udp --dport 28960 -j DNAT --to-destination 10.8.0.2:28960

D. h. Du willst die Dienste (daemons) auf dem Windows-Client, an der VPN-Transfer-Netz-IP-Adresse lauschen lassen?
Dann schau mit z. B. wireshark (oder gleichwertig) auf dem Windows-Client nach, ob ein Portscan dort ankommt, wenn Du mit o. g. und gesetzter DNAT-Regel (auf dem Server) einen Portscan aus dem Internet auf deinem Server und den Port 28960 machst.

[DynaBlaster]

Vielleicht ist das Problem auch einfach nur deaktiviertes IP_Forward auf dem Debian-Server

Code: Alles auswählen

cat /proc/sys/net/ipv4/ip_forward

1 heisst aktiv, 0 heisst inaktiv

Ansonsten sieht das eigentlich gut aus. iptables-seitig müsste das hier reichen, um Anfragen aus dem Internet an 51.12.12.12:28960 auf 10.8.0.2:28960 weiterzuleiten

Code: Alles auswählen

iptables -t nat -A PREROUTING -i ens3 -p udp --dport 28960 -j DNAT --to-destination 10.8.0.2:28960
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j MASQUERADE
# optional, wenn die Default-Policy für die FORWARd-Chain auf DROP gesetzt ist
#iptables -A FORWARD -i tun+ -o ens3 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
#iptables -A FORWARD -i ens3 -o tun+ -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Wenn der Windows-Client tatsächlich alles durch das VPN routet, müsstest du bei https://www.wieistmeineip.de entsprechend auch 51.12.12.12 statt der DSLlite-IP angezeigt bekommen. Das impliziert dann allerdings auch ein bereits aktiviertes ip_forward auf dem Debian-Server. Für den MW-Serverdaemon heisst das aber weiterhin, das der auch auf Anfragen an 10.8.0.2 reagieren muss. Wenn der/die Dienst(e) nur auf 192.168.0.50 reagieren, hilft auch das Prerouting auf 10.8.0.2 nix. Dann müsste man die Windows-Kiste überreden, ebenfalls Router zu spielen und Pakete an 10.8.0.2 an 192.168.0.50 weiterzugeben und andersherum.

[DJannik]

Über wieistmeineip bekomme ich die Server-IP angezeigt, das heißt ip_forward ist auf jeden Fall aktivert.

Dann schau mit z. B. wireshark (oder gleichwertig) auf dem Windows-Client nach, ob ein Portscan dort ankommt

Habe gestern mal mit den gesetzten Regeln ein Portscan an 28960 UDP gemacht, auf meinem Client ist aber nichts angekommen.

Für den MW-Serverdaemon heisst das aber weiterhin, das der auch auf Anfragen an 10.8.0.2 reagieren muss. Wenn der/die Dienst(e) nur auf 192.168.0.50 reagieren, hilft auch das Prerouting auf 10.8.0.2 nix. Dann müsste man die Windows-Kiste überreden, ebenfalls Router zu spielen und Pakete an 10.8.0.2 an 192.168.0.50 weiterzugeben und andersherum.

Habe auf jeden Fall schon einen Weg gefunden, wie man das realisieren könnte, Windows unterstützt das nämlich nur für TCP, aber nicht UDP...
Was aber auch der Fall ist, der MW-Daemon kann nach außen über Port 28960 kommunizieren OHNE gesetztes Routing zwischen 192.168.0.50 <-> 10.8.0.2
Das heißt ein Routing auf dem Client wäre sowieso entbehrlich?
Aber das Problem ist ja eben, dass ein Portscan nicht mal ankommt.

Und ich weiß nicht in wie fern das relevant ist aber in der VPN-Client-config habe ich das standardmäßige "nobind" auskommentiert, aber das sollte sich wohl eher als Vorteil erweisen
Gibts sonst noch was zu beachten an config-Parameter?

[mat6937]

Habe gestern mal mit den gesetzten Regeln ein Portscan an 28960 UDP gemacht, auf meinem Client ist aber nichts angekommen.
...
Aber das Problem ist ja eben, dass ein Portscan nicht mal ankommt.

Mit welchem Tool hast Du den UDP-Portscan gemacht?

Versuch mal mit einem TCP-Portscan, denn das ist einfacher und hier im Test nicht relevant (ob TCP oder UDP).

[DJannik]

Mit welchem Tool hast Du den UDP-Portscan gemacht?

Versuch mal mit einem TCP-Portscan, denn das ist einfacher und hier im Test nicht relevant (ob TCP oder UDP).

https://www.ipfingerprints.com/portscan.php
habe damit gescannt, funktioniert aber, das ist nicht das problem

habe grade nochmal mit tcp gescannt, ist aber auch nichts angekommen

[mat6937]

habe grade nochmal mit tcp gescannt, ist aber auch nichts angekommen

Wie stellst Du fest, dass nichts ankommt? Über das Web-Tool oder schaust Du an "vorderster Stelle" mit einem dafür geeigneten Tool auf deinem Windows-PC, nach? Kannst Du im VPN-Server (tun0-Interface) nachschauen, ob dort während des TCP-Scans, Datenpakete durch gereicht werden?

[DJannik]

Wie stellst Du fest, dass nichts ankommt? Über das Web-Tool oder schaust Du an "vorderster Stelle" mit einem dafür geeigneten Tool auf deinem Windows-PC, nach? Kannst Du im VPN-Server (tun0-Interface) nachschauen, ob dort während des TCP-Scans, Datenpakete durch gereicht werden?

Ja, habe direkt auf dem Client nachgeschaut. Habe jetzt grade am tun0 Interface gecaptured, da werden die Pakete auf jeden Fall zu 10.8.0.2 weitergereicht.
Das heißt jetzt muss ich nur noch rausfinden, warum die auf dem Client nicht ankommen. Vielleicht wird ja auch der Port geändert aber eigentlich sollte das auskommentierte "nobind" in der Client-config genau das verhindern, wenn mich nicht alles täuscht. An der Firewall kann es auch nicht liegen, die hab ich nämlich gestern extra zum Testen deaktiviert.

Habe grad beim Googlen noch was gefunden von wegen POSTROUTING im nat-table mit SNAT, aber das würde ja nur Pakete betreffen die den Server dann wieder verlassen oder?

[mat6937]

Ja, habe direkt auf dem Client nachgeschaut. Habe jetzt grade am tun0 Interface gecaptured, da werden die Pakete auf jeden Fall zu 10.8.0.2 weitergereicht.
Das heißt jetzt muss ich nur noch rausfinden, warum die auf dem Client nicht ankommen.

Naja, die Datenpakete kommen auf dem Client schon an, denn die 10.8.0.2 (tun0) ist doch auf dem Client, oder?

Der Client (Windows-PC) leitet diese nur nicht weiter an den lauschenden Dienst (daemon).

[DJannik]

Naja, die Datenpakete kommen auf dem Client schon an, denn die 10.8.0.2 (tun0) ist doch auf dem Client, oder?
Der Client (Windows-PC) leitet diese nur nicht weiter an den lauschenden Dienst (daemon).

Ich bin ein Stück weitergekommen, die Pakete kommen auf dem Client an, du hast Recht, nur nicht auf dem ursprünglichen Port, sondern auf einem ganz anderen.
Habe gestern nur den einen Port gecaptured aber dann macht das auch Sinn. Fast alle Anfragen werden am Clienten zwischen Port 50000-60000 verarbeitet, die Zuweisung scheint zufällig zu erfolgen. Die Ursache dafür liegt aber am OVPNServer, das bestätigt ein Capturing auf dem Server.
Ich muss OVPN also dazu bringen, die gleichen Ports zu verwenden, wenn das geschafft ist, ist alles gut.

[mat6937]

Fast alle Anfragen werden am Clienten zwischen Port 50000-60000 verarbeitet, die Zuweisung scheint zufällig zu erfolgen. Die Ursache dafür liegt aber am OVPNServer, das bestätigt ein Capturing auf dem Server.
Ich muss OVPN also dazu bringen, die gleichen Ports zu verwenden, wenn das geschafft ist, ist alles gut.

Das verstehe ich nicht. Geht es evtl. um einen source-Port (mit dem tun-Interface) auf deinem Client, weil Du schreibst, zwischen 50000 und 60000.
Du hast doch auf deinem Client einen bestimmten (definierten) lauschenden Port konfiguriert? Warum kann dieser lauschende Port auf dem Client, vom Server aus nicht erreicht werden?

[DJannik]

Das verstehe ich nicht. Geht es evtl. um einen source-Port (mit dem tun-Interface) auf deinem Client, weil Du schreibst, zwischen 50000 und 60000.
Du hast doch auf deinem Client einen bestimmten (definierten) lauschenden Port konfiguriert? Warum kann dieser lauschende Port auf dem Client, vom Server aus nicht erreicht werden?

Bei den randomizten Ports waren viele fortlaufend, könnte gut sein dass das ein Sicherheits-Feature ist. Und das hatte nichts mit dem Portscan oder sonst was zu tun, ich hab einfach ein bisschen Traffic produziert und der meiste ist eben über diese Portrange gelaufen, Remote Ports waren natürlich die entsprechenden Service-Ports.

Ich konnte es noch nicht ausprobieren, aber vielleicht ist "setenv FORWARD_COMPATIBLE 1" meine Lösung, bin mir nicht sicher ob die Option das oder etwas anderes bewirkt.
Werde das aber auch noch mit den Optionen --bind und --local testen, vielleicht hilft ja was davon.

[mat6937]

..., aber vielleicht ist "setenv FORWARD_COMPATIBLE 1" meine Lösung, bin mir nicht sicher ob die Option das oder etwas anderes bewirkt.

Wo setzt Du diese Option? Ich denke dein Windows-PC wird das Problem sein, denn wenn Server und Client als OS Linux haben, wird diese Option nicht benötigt.

[DJannik]

Wo setzt Du diese Option? Ich denke dein Windows-PC wird das Problem sein, denn wenn Server und Client als OS Linux haben, wird diese Option nicht benötigt.

kann man in der client-config setzen, aber war auch ohne Erfolg
--bind und --local waren auch ohne Erfolg

https://s19.directupload.net/images/200129/2qqlgf3r.png
der markierte ist ein portscan auf tcp 27015, kommt aber eben nicht auf port 27015 an

[mat6937]

der markierte ist ein portscan auf tcp 27015, kommt aber eben nicht auf port 27015 an

Wenn der Portscan nicht ankommt, dann kann man doch auch nicht sagen, dass ein bestimmter Portscan (hier auf tcp 27015) auf einem anderen Port (der markierte) ankommt. Wie hast Du festgestellt, dass der Markierte für den destination-Port 27015 bestimmt war? Wenn doch, was sollte/könnte die Datenpakete auf den anderen (markierten) Port umgeleitet haben?