Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

This one is driving me nuts. I have a Terminal Server at a client's location (they are an RV park, and have a rather extensive internal network with multiple DSLAM's). The TS has 2 NIC's: one connected to the local (office) network, through a router to a DSL modem, then on to the Park network; the other (a USR brand) connected directly to a DSL modem with a public IP through the Park network.

I have RDP bound only to the USR NIC, and I am using Wireshark to monitor the port 3389 traffic on it.

If I use RDC to connect from another computer on the Office LAN, using the public IP address, everything goes fine and I get a login screen; Wireshark shows lots of port 3389 traffic going both ways.

If I try to connect from outside the park (using the same public IP), Wireshark show three successive INBOUND port 3389 packets at 3 to 6 second intervals, with NO outbound ones, then my RDC client gives the old "this computer can't connect to the remote computer" message.

It is like the computer is refusing to answer any RDP traffic unless it is from a local IP. Windows firewall is turned off (I even went into Services.msc and made sure the service isn't running), and there are no third-party security products running on this computer.

The most annoying thing is that this used to work fine. About 2 months ago it became intermittent, and now is won't work at all. I have traded out the NIC I am using (it was an Intel, now a USR), with no change in behavior.

share|improve this question
add comment

2 Answers

If you don't want to remove your default gateway, you can create a new route to ensure ParkLan data goes the right direction. From a CMD prompt:

route add 172.13.12.0 mask 255.255.254.0 172.13.12.1

The gateway you give it should be the gateway for the ParkLan adapater. What this does is force Windows to route data from that LAN to the correct network. I've seen your problem before, and it was where Windows was trying to send the reply packets across the wrong NIC.

share|improve this answer
add comment

Try removing the default gateway from the internal NIC and assigning a default gateway to the external (USR) NIC.

share|improve this answer
    
Thanks, Joe! Looks like that did the trick. Since it was an intermittent problem (although mostly didn't work), I will have to wait a few days to make sure it is working consistently. Send me your address and I'll drop you a Starbucks card! Steve –  Steve Nov 19 '09 at 0:27
    
Happy to help and glad you got it sorted. No need for the cup o' joe (no pun intended), I'm sure you'll be answering one of my questions in the not too distant future. ;) –  joeqwerty Nov 19 '09 at 2:32
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.