Server Fault Asked by Reece on December 13, 2020
I have a RDP user who has successfully been using RDP from his laptop to his workstation in our office when he is at home.
It is configured to use our public IP and port 10378 and has been working fine until about 2 weeks ago when it just stopped working for him.
I’ve checked our Firewall’s policies and the port forwards are still as they were when it was working fine. The allowed external IP’s is still set to ‘ANY’ and the desktop PC is still listening on the same RDP port I configured months ago.
Can it be that the ISP for his home internet connection is blocking traffic to one specific IP address? Or a few specific TCP Ports?
How can I test and prove this? Or what else could it be?
I tried to ask this on Network Engineering but was shunned for being off-topic, so I’m coming here hoping someone may be able to help…
Old topic, but I want to warn future readers that presenting RDP directly to the Internet - even on a nonstandard port - is an incredibly bad idea.
Set up a secure VPN from the user’s laptop to a network or to a specific machine in their workplace and run RDP traffic through that encrypted tunnel. This solves the possible issue of RDP traffic being intercepted by the ISP, and it works around possible weaknesses in the RDP protocol security.
Answered by Mikael H on December 13, 2020
Yes - ISP's can and do block certain services on residential broadband links. It's also possible that the router/firewall combo at the user's house is blocking connections to some ports.
Here are some steps to confirm-
Eliminate the home router: Confirm that the router configuration isn't doing some kind of blocking (to potentially include app recognition mechanisms looking for non-standard ports, etc). If this is inconclusive then you can try either connecting the user's computer directly to the Internet connection or an alternate (and known-working) firewall.
If it's still not working on the direct connection then it makes sense to break out the sniffer. Install Wireshark and capture all traffic while attempting to initiate a connection. Confirm that the packet is as expected, look for the TCP handshake and, more importantly, look for any kind of ICMP unreachable messages coming back (port administratively prohibited, etc). If you're seeing ICMP coming back note whether it's coming from somewhere within the carrier or from the far end (i.e. the corporate edge router or firewall).
It also may be helpful to set up another sniffer at the corporate side to confirm whether packets are making it at all. If, for example, you're seeing TCP SYN packets coming in but nothing going back then you'd want to figure out why. If you're seeing SYN come in from the user's side and ACK go back but that ACK doesn't show up at the user's side then that indicates something else may be blocked (..this is unlikely).
Answered by rnxrx on December 13, 2020
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP