6
RDP-Verbindung mit NAT
Hey,
ich habe folgende Konstellation:
HomeOffice:
FritzBox, übernimmt Internet-Einwahl: 192.168.x.1
Zyxel USG40W: bekommt Internet von Fritzbox über WAN1: WAN1-IP 192.168.x.2
Laptop im WLAN der FritzBox: 192.168.x.30
Zyxel USG40W ist per IPSec mit der ZyWall 310 in der Firma verbunden.
ZyWall 310 in der Firma hat die 10.0.x.1
Der RDS hat in der Firma 10.0.x.20
Nun habe ich auf der Zyxel USG40W ein NAT ertellt:
Incoming Interface: WAN1
SourceIP: any
External IP: WAN_IP
Internal IP: RDS_IP
PortMapping: 3389
Policy:
From: any (hatte auch schon WAN eingestellt)
TO: IPSec_VPN 10.0.x.5-10.0.x.22
Source: any
Destination: RDS_IP
Service RDP
User: any
Action: Allow
Starte ich ein RDP mit der IP 192.168.x.2 funktioniert die Verbindung nicht und ich bekomme in der USG40W folgenden Eintrag:
"Match default rule, DROP - 192.168.x.30:50002 - 10.0.x.20:3389 - ACCESS BLOCK
Das NAT müsste dann ja stimmen, aber scheinbar ist die Policy falsch.
Braucht ihr noch mehr Info?
Danke für eure Hilfe im Voraus.
!!EDIT!! Ich habe es nicht nur schlecht beschrieben, sondern eigentlich auch was ganz wichtiges vergessen zu erwähnen. Sinn der ganzen Sache soll sein, dass der Client im WLAN der FritzBox am RemotedesktopClient die 192.168.199.2 als Remoteadresse eingibt und damit auf den RDS kommt.
ich habe folgende Konstellation:
HomeOffice:
FritzBox, übernimmt Internet-Einwahl: 192.168.x.1
Zyxel USG40W: bekommt Internet von Fritzbox über WAN1: WAN1-IP 192.168.x.2
Laptop im WLAN der FritzBox: 192.168.x.30
Zyxel USG40W ist per IPSec mit der ZyWall 310 in der Firma verbunden.
ZyWall 310 in der Firma hat die 10.0.x.1
Der RDS hat in der Firma 10.0.x.20
Nun habe ich auf der Zyxel USG40W ein NAT ertellt:
Incoming Interface: WAN1
SourceIP: any
External IP: WAN_IP
Internal IP: RDS_IP
PortMapping: 3389
Policy:
From: any (hatte auch schon WAN eingestellt)
TO: IPSec_VPN 10.0.x.5-10.0.x.22
Source: any
Destination: RDS_IP
Service RDP
User: any
Action: Allow
Starte ich ein RDP mit der IP 192.168.x.2 funktioniert die Verbindung nicht und ich bekomme in der USG40W folgenden Eintrag:
"Match default rule, DROP - 192.168.x.30:50002 - 10.0.x.20:3389 - ACCESS BLOCK
Das NAT müsste dann ja stimmen, aber scheinbar ist die Policy falsch.
Braucht ihr noch mehr Info?
Danke für eure Hilfe im Voraus.
!!EDIT!! Ich habe es nicht nur schlecht beschrieben, sondern eigentlich auch was ganz wichtiges vergessen zu erwähnen. Sinn der ganzen Sache soll sein, dass der Client im WLAN der FritzBox am RemotedesktopClient die 192.168.199.2 als Remoteadresse eingibt und damit auf den RDS kommt.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666937
Url: https://administrator.de/forum/rdp-verbindung-mit-nat-666937.html
Ausgedruckt am: 21.04.2025 um 13:04 Uhr
6 Kommentare
Neuester Kommentar
Vorweg: Private IP-Adressen (10.0.0.0 bis 10.255.255.255, 172.16.0.0 bis 172.31.255.255 und 192.168.0.0 bis 192.168.255.255) braucht man nicht verschleiern. Die haben keinerlei Aussagewert und werden millionenfach verwendet. Es macht deine schlecht verständliche Beschreibung noch viel unverständlicher.
Das Problem dürfte sein, irgendwas an der Regel nicht passt, aber deine ganze Konstruktion ist fürn Popo. Wenn du WLAN haben willst, dann investiere 30€ in einen Access Point und pack den auf die andere Seite der Firewall.
Was genau an der Regel nicht passt, müsste man jetzt mit ordentlichen Logs herausfinden, die die Verbindungsparameter aufschlüsseln. Ist auch die Frage, ob die Kiste NAT auf IPSec-Gegenstellen überhaupt zulässt, weil IPSec in der Regel eine restriktive Regelerzeugung vorsieht, die auf beiden Seiten des Tunnels erfolgen muss.
Das Problem dürfte sein, irgendwas an der Regel nicht passt, aber deine ganze Konstruktion ist fürn Popo. Wenn du WLAN haben willst, dann investiere 30€ in einen Access Point und pack den auf die andere Seite der Firewall.
Was genau an der Regel nicht passt, müsste man jetzt mit ordentlichen Logs herausfinden, die die Verbindungsparameter aufschlüsseln. Ist auch die Frage, ob die Kiste NAT auf IPSec-Gegenstellen überhaupt zulässt, weil IPSec in der Regel eine restriktive Regelerzeugung vorsieht, die auf beiden Seiten des Tunnels erfolgen muss.
Der Fehler ist das der TO fälschlicherweise eine NAT Regel erstellt hat was grundsätzlich für das Vorhaben ja der falsche Weg ist.
Was er braucht ist eine Port Forwarding Regel ! Sprich der VOR der NAT Firewall des Zyxel liegende WLAN Client braucht eine Port Forwarding Regel für den RDP Port TCP 3389 damit dieser Client so die Zyxel NAT Firewall überwinden kann die mit der FritzBox in einer Doppel NAT Kaskade arbeitet.
So sähe das dann richtig aus:
Incoming External IP: 192.168.x0 /24 (Erlaubt alle Absender IPs aus dem .x Netz (WLAN)
Forward to Internal IP: 10.0.x.20 (Zieladresse des RDP Servers)
PortMapping: TCP 3389
Zusätzlich muss im Firewall Regelwerk der TCP 3389 Zugang auf die Firewall WAN IP 192.168.x.2 aus dem Absender IP Netz 192.168.x.0 /24 erlaubt sein.
Port Forwarding kann genau einen TCP UDP Port auf einen Zielhost mappen. Mehrere geht nicht !
So wird ein Schuh draus und dann klappt das auch sofort !
Was er braucht ist eine Port Forwarding Regel ! Sprich der VOR der NAT Firewall des Zyxel liegende WLAN Client braucht eine Port Forwarding Regel für den RDP Port TCP 3389 damit dieser Client so die Zyxel NAT Firewall überwinden kann die mit der FritzBox in einer Doppel NAT Kaskade arbeitet.
So sähe das dann richtig aus:
Incoming External IP: 192.168.x0 /24 (Erlaubt alle Absender IPs aus dem .x Netz (WLAN)
Forward to Internal IP: 10.0.x.20 (Zieladresse des RDP Servers)
PortMapping: TCP 3389
Zusätzlich muss im Firewall Regelwerk der TCP 3389 Zugang auf die Firewall WAN IP 192.168.x.2 aus dem Absender IP Netz 192.168.x.0 /24 erlaubt sein.
Port Forwarding kann genau einen TCP UDP Port auf einen Zielhost mappen. Mehrere geht nicht !
So wird ein Schuh draus und dann klappt das auch sofort !
1
Zur einfachen Erweiterung von aqui.
Woher soll der Client wissen wohin er routen soll.
Das geht alles auf den Standard Gateway 192.168.x.1 ins nirwana.....
Entweder du sagst es dem Client das er das Netz 10.0.x.20 über 192.168.x.2 findet oder der Fritzbox.
Woher soll der Client wissen wohin er routen soll.
Das geht alles auf den Standard Gateway 192.168.x.1 ins nirwana.....
Entweder du sagst es dem Client das er das Netz 10.0.x.20 über 192.168.x.2 findet oder der Fritzbox.
Ich habe es nicht nur schlecht beschrieben, sondern eigentlich auch was ganz wichtiges vergessen zu erwähnen. Sinn der ganzen Sache soll sein, dass der Client im WLAN der FritzBox am RemotedesktopClient die 192.168.199.2 als Remoteadresse eingibt und damit auf den RDS kommt.
Trotzdem oder besser deshalb …
dass der Client im WLAN der FritzBox am RemotedesktopClient die 192.168.199.2 als Remoteadresse eingibt und damit auf den RDS kommt.
Das widerspricht dann völlig der IP Adressierung die du oben angegeben hast wo der RDP Server in einem 10er Netz liegt. Jetzt ist man hier völlig verwirrt und versteht gar nichts mehr. 😠Macht ein zielführendes Troubleshooting nicht gerade einfacher.... Ggf. postest du einmal eine kleine Topologieskizze mit wirklich verlässlicher IP Adressierung an der wir uns für einen zielgerichtete Hilfe bzw. Lösung orientieren können ?!
Nur so viel: Dein Design ist grundsätzlich nicht besonders intelligent und aus Sicherheitssicht ziemlich kontraproduktiv. Welchen Sinn hat es VOR der Firewall gelegene IP Netze durch eine Firewall zu zwingen ? Genau DAS will man ja eigentlich nicht mit dem Einsatz einer Firewall die das lokale Netz schützen soll. Besser wäre es in jedem Falle das WLAN der FritzBox dort zu deaktivieren und dir einen separaten WLAN Accesspoint in dein lokales Netzwerk zu legen.
So musst du keine sinnfreien Löcher in die Firewall bohren und kannst das sicherheitstechnisch sauber abbilden.
Technisch noch viel besser wäre es die FritzBox selber komplett durch ein reines NUR Modem wie ein Draytek Vigor 165 oder Zyxel VMG 3006 zu ersetzen und die Firewall den Internet Dialin direkt machen zu lassen. Doppel NAT Kaskaden wie du sie betreibst oben sind immer kontraproduktiv.
Die dann überflüssige FritzBox kannst du dann im internen LAN als Telefonieserver bzw. WLAN AP betreiben wenn du es musst. Das wäre Infrastruktur technisch sinnvoll. Nicht diese Kaskaden Fricklei die du oben machst und dann die Firewall durch Löcher ad absurdum führst.
Dann hättest du das VPN auch von deiner FritzBox direkt auf die Firmenzyxel realisieren können. Die FB ist ja selber aktiver IPsec VPN Router.
