Vraag

RDP Extern

  • 23 augustus 2018
  • 29 reacties
  • 693 keer bekeken

Hi Allen,

Ik probeer van buitenaf een rdp connectie op te zetten. Maar er komt geen enkele traffic (gecontroleerd met wireshark) aan op de pc in het netwerk. RDP op het netwerk zelf werkt prima.
Ik heb ook een aantal andere poorten geforward staan en deze werken prima.
Ik maak gebruik van een Experia Box v10A
Op de pc in het nerwerk staat windows firewall compleet uit.
Port forward staat als volgt ingesteld:
Private IP: 192.168.2.9
Protocol: TCP & UDP
Private Port: 3389
Public Port: 8080 (Ook andere poorten geprobeerd, voorlopig eerst maar is deze proberen)

VPN is niet wat ik hiervoor wil gebruiken.
Wat kan ik nog proberen?

29 reacties

Reputatie 7
Laat de public port ook 3389 zijn en zorg er voor dat het IP adres van die PC niet kan wijzigen.
Kan je overigens op het LAN wel een RDP sessie opzetten met 192.168.2.9.

Overigens is het openstellen van RDP één van de dingen die ik nooit zal doen zolang RDP geen mechanisme kent om automatisch IP adressen te blokkeren na bijvoorbeeld 3 foutieve inlogpogingen binnen 5 minuten.
Ja op het lan lukt het wel. public poort wijzigen naar 3389 werkt helaas niet.
Reputatie 7
Kan je eens een screenshot plaatsen van de port-forwarding?

Reputatie 3
Badge
Toevallig een firewall op de Experiabox die de RDP connectie weigert?
Reputatie 7
Als de 192.168.2.9 de PC is, dan zou het verkeer daar gewoon naar doorgezet moeten worden.
Het kan nog zo zijn dat je RDP op die PC geblokkeerd hebt voor externe IP adressen.
In het onderstaande screenshot een voorbeeld waarbij RDP alleen vanaf het eigen lokale netwerk mogelijk is.


Test de connectie ook werkelijk vanaf een andere locatie of via 3/4G want het zou ook maar zo kunnen zijn dat de V10A een probleem heeft met NAT loopback. NAT loopback is vanuit het eigen LAN via het publieke IP adres een ander apparaat op het eigen LAN benaderen.


Dit zou alles moeten toelaten.

Plaatje van jouw is van de windows firewall. Deze staat volledig uit bij mij, maar staat wel hetzelfde ingesteld.
Reputatie 7
Brrr, ook dat nog, een firewall die volledig uit staat.
Een infectie van een ander apparaat op jouw LAN en bam daar gaat je PC.

Windows 10 Home of Pro ... of zelfs nog Windows 7?
Windows 10 pro.

Eerst maar is aan de praat krijgen. Kunnen we later wel naar de veiligheid gaan kijken 😉.
Reputatie 7
Er is dan mijns inziens niets wat de werking tegen zou moeten houden.
Een RDP sessie naar het publieke IP adres, geïnitieerd via 3/4G of op een andere locatie via Internet, wordt doorgezet naar 192.168.2.9 (port-forwarding) en de 192.168.2.9 accepteert die RDP sessie. Tenminste zo staat het geconfigureerd. Werkt het niet, dan gaan mijn eerste gedachten richting een bug in de firmware van de V10A, waarvan ik begrijp dat er nog wel meer foutjes in zitten.

Misschien dat iemand van KPN hier wat zinnigs over kan zeggen.
Dan moeten we maar wachten totdat die hier reageren? Want de klantenservice stuurde me hierheen.
Grappig is dat andere port-forwardings wel gewoon werken.
Dus het lijkt toch iets te zijn met de onderliggende pakketjes en de inhoud ervan.
Reputatie 7
Zet de port-forwarding eens op alleen TCP i.p.v. TCP&UDP.
Heeft dat een ander resultaat?
Dat heb ik in het begin ook geprobeerd.
Dat werkte ook niet. RDP heeft ook udp nodig volgens mij. (Zag in wireshark namelijk ook udp connectie en data)
Reputatie 6
Badge +7
Misschien al geprobeerd, maar ik zou eerst die portforward rule even weer verwijderen, dan een gecontroleerde restart en powercycle van de V10A en dan weer een rule met alleen TCP en op standaard poort 3389, dus geen portmapping.
Het kan zijn dat als je UDP toelaat er iets anders doorheen gaat, ofwel een UDP connectie bestaat niet (UDP is connectionless). Kwamen die UDP paketten van de client (jouw eigendom)?
Je hebt op de 1 of andere manier vastgesteld dat er op een hogere protocollaag wel verbinding was? Hoe? Ik ben er alijd van uitgegaan dat RDP alleen TCP nodig heeft.
Kijk e.v.t. ook nog eens de optionele gateway in de settings op zowel client alse server na; die kan ook makkelijk roet in het eten gooien en zou ik expliciet mijden.
Forwarding Verwijderd.
Restart
Forwarding toegevoegd.
Restart.

Geen wijziging. Nog steeds geen enkel bitje wat de server bereikt.

Hierbij een wireshark trace van een rdp connectie op het lokale netwerk.
Je ziet dat er af en toe ook udp data naar 3389 (client->server).
Het kan uiteraard zo zijn dat udp niet perse nodig is, maar alleen gebruikt word als het kan.

Reputatie 6
Badge +7
Zo uitgevoerd heeft weinig nut; UDP nog steeds doorlaten geeft onzekerheid. Hoe weet je zeker dat die UDP paketten van de (jouw) client komen? En niet van een willekereurige andere computer, in het ergste geval een attacker?
En: Je kan net zo makkelijk concluderen dat 'bits' wel aankomen bij de server aan de hand van deze trace.
Er lijkt mij eerder op applicatie niveau iets mis te gaan i.c.m. IP laag.
TCP staat op het moment alleen open.

Bij source staat toch echt de client ip. En de udp pakketjes zijn er alleen tijdens de rdp sessie.
Maar goed dit was een trace van een verbinding via het LAN netwerk.
Vanaf buitenaf is er niks te zien op de trace.

Onder tussen de Windows firewall weer aangezet. En alles ingesteld (edge traversal). Maar nog steeds niks.

Sta open voor ideeën.
Reputatie 6
Badge +7
Bij source staat 192.168.2.2, nu realiseer ik me dat je denk ik vanuit je LAN RDP extern probeert te benaderen. Dit is niet echt extern. Extern zou zijn als je met de client op een ander netwerk zit met een ander publiek IP adres, dus b.v. je smartphone in hotspot modus, daar de client aan linken en dan V10A_WAN_IP_ADDR :3389 met de RDP client benadert.

Voor benaderen vanuit intern met extern adres heb je een goed werkende NAT loopback of hairpin NAT nodig in de V10A. Kan best zijn dat dat niet het geval is. Ook bij de V10 in SIB bedrijf werkt NAT loopback niet.
Reputatie 7
Voor benaderen vanuit intern met extern adres heb je een goed werkende NAT loopback of hairpin NAT nodig in de V10A. Kan best zijn dat dat niet het geval is.Dat kan, zoals al eerder aangegeven, inderdaad de oorzaak zijn. Test anders eens via een 3/4G verbinding of vanaf het LAN van buren, kennissen of familie.

Ook bij de V10 in SIB bedrijf werkt NAT loopback niet.De NAT loopback op de V10 (zonder A) werkt gelukkig prima.
Bij source staat 192.168.2.2, nu realiseer ik me dat je denk ik vanuit je LAN RDP extern probeert te benaderen. Dit is niet echt extern. Extern zou zijn als je met de client op een ander netwerk zit met een ander publiek IP adres, dus b.v. je smartphone in hotspot modus, daar de client aan linken en dan V10A_WAN_IP_ADDR :3389 met de RDP client benadert.

Voor benaderen vanuit intern met extern adres heb je een goed werkende NAT loopback of hairpin NAT nodig in de V10A. Kan best zijn dat dat niet het geval is. Ook bij de V10 in SIB bedrijf werkt NAT loopback niet.


Dit was alleen als voorbeeld voor de traffic. Ik probeer vanaf extern te verbinden.

NAT loopback werkt prima voor me nas en andere webservices.
Begin er toch langzamerhand wel aan te denken dat er toch iets door kpn word geblokkeerd.

Zijn er nog opties om dingen uit te proberen?
Reputatie 6
Badge +7
Zijn er nog opties om dingen uit te proberen?
Het is mij niet duidelijk of je al geprobeert hebt met de optie 'Do not use and RD Gateway server' aangevinkt EN tevens van daadwerkelijk extern.
Zie https://www.youtube.com/watch?v=4laT7uE_snU
Zijn er nog opties om dingen uit te proberen?
Het is mij niet duidelijk of je al geprobeert hebt met de optie 'Do not use and RD Gateway server' aangevinkt EN tevens van daadwerkelijk extern.
Zie https://www.youtube.com/watch?v=4laT7uE_snU


Ja die optie heb ik geprobeerd. En test vanaf me werk en 3g/4g.

Ondertussen heb ik een simpel programmatje geschreven die een tcp connectie maakt. Lokaal werkt dit, maar over het internet krijgt deze ook geen connectie.
Ook vanaf lan naar wanip word de connectie geweigerd.

Een tcp connectie over het internet naar poort 80 (webserver/192.168.2.2) werkt wel.

Dus het lijkt misschien toch te liggen aan de specifieke pc.

Ik ga de portwarding is naar 192.168.2.2 omzetten en kijken wat er dan gebeurd.
Ok andere pc/server werkt ook niet.
Misschien ligt het toch aan Windows 10.
Windows firewall aan of uit maakt geen verschil.
Reputatie 6
Badge +7
Ik zou inderdaad proberen eerst eens helemaal aan een andere kant van mogelijkheden om een portforwarding te benutten gaan zitten. Zoals je zelf al hint, probeer b.v. Win10 en RDP effecten en de betreffende PC's uit te sluiten. Er kan nog zoveel mis zijn en ik neem aan dat je niet al in detail alle logbestanden van Win10 m.b.t. dit probleem hebt door geplozen. 2 linux boxen met telnet/netcat/http o.i.d. als connectie test zou ik nemen om te kijken of het de V10A of KPN link is.

Reageer