Remote Desktop Netopia IPSEC issue 2

[kescor]

I have two networks, network A (200.200.200.x) and Network B (192.168.1.x). They are joined via an IPSEC tunnel using two netopia routers (R7100 & R9100 i think).

I can ping, map drives across, remote control using PC Anywhere, but can not establish a RDP session either way.

I have verified no firewalls or nats exist between the tunnel.

What is even more interesting, is if a workstation in either network opens a PPTP tunnel to the other Router, RDP will work.

RDP will work within each network (A or B but not across).

And even more interesting, if I establish from home a VPN PPTP tunnel to say router A, I can RDP all machines within the A network and RDP across the IPSEC tunnel to all machines within network B. The same holds true in reverse.

So, I've established that the machines can RDP eachother within their own networks, but can not across the IPSEC tunnel. But I've established the IPSEC tunnel will support the traffic from my home machine connecting across the networks.

I've also verified the local XP SP2 firewalls are allowing RDP from all addresses.

Anyone have any ideas?

 

[kescor]

One more thing, When I experience the RDP issue, a connection is made, the screen goes blank, but the login prompt never comes up.

I've verified using netstat that the communication is established.

 

[John Lewis]

What happens when the RDP connection fails? Error messages, etc.

Also, try a telnet to one of the RDP hosts across the connection on port 3389 -- 'telnet 192.168.1.xx 3389'. A blank screen with a flashing cursor indicates the connection is accepted, otherwise you should receive an error message.

Are you using computer names to connect, or IP addresses. If you are not using IP addresses, try that to eliminate a name resolution issue.

Finally, the 200.200.200.x network adress for network A is a routable internet address. If you have been assigned public addresses for that network, then good for you. If not, you should be using 192.168.xx.xx, 172.16-31.xx.xx or 10.xx.xx.xx for that network. If you are using one of those and the 200 is just an example, that is great as well.

 

[kescor]

What happens when the RDP connection fails? Error messages, etc.

>> The session starts, the screen never paints with a blank background and the login box never shows. A timeout message finally is displayed to the effect of "communication can not be established"

The telnet on port 3389 works just as you described.

I'm connecting using IP Addresses, not machine names.

 

[John Lewis]

Actually, the telnet was not necessary given the information about the blank screen. We were posting at the same time.

This sounds like one (or both) of the routers is causing a black hole situation on the IPsec connection. To verify, try a ping with the options '-f -l 1472'. I am guessing this will time out.

 

[kescor]

I recieve:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

But, if I can PPTP into Router A and then RDP from my home PC to a workstation in network B (home pc -- PPTP to router A -- IPSEC tunnel to Router B -- to Workstation).

It is working, right?

 

[John Lewis]

Remote desktop is working. The blank screen when you connect (as opposed to an error message) indicates that you are indeed connecting. The telnet test confirms. The fact that it works when you throw the extra VPN connection into the mix further confirms that everything is configured properly.

For some reason, the packets that follow the initial connection are not getting through. The initial setup information is sent in realatively small packets, while the actual desktop information is sent in relatively large packets. When a router gets a packet that is too large to handle, it is supposed to report the situation to the sending device. When this report is not made, packets are often dropped without notice, which could cause the problem at hand.

When you establish a VPN connection with a MS VPN client, a virtual network interface is added which automatically has a smaller packet size (MTU) set in order to compensate for the extra information the VPN adds to the packets. This would cause smaller packets to be sent, which may allow the traffic to continue on past a flaky router without a problem. Seemed to fit the situation.

The response to the last ping indicates that the router is indeed sending the notice that the packets are too large. This is counter to what I was thinking.

Perhaps the second router in the chain is the problem. Try the ping with the extra options again, decreasing the 1472 by 16 until you get either a good reply or a request timed out. If you get a good reply first, increase the number again until you get either the same message as the last post or a request timed out.

If at any time you get the request timed out, it would indicate that the second router is acting up. If you don't see the request timed out, the integrety of the routers will be confirmed and we will need to look for something else.

 

[kescor]

mhkwood,

Great diagnostic work. That indeed was the problem and solution.

I set the MTU size to 1400 at the remote office and they are connecting without the need of the extra VPN clients.

Thank you.

 

[John Lewis]

Glad to be of help in solving your problem.

But . . . I would not consider this a long term solution. As you add new hosts at the site, they will need to be modified as well. The router in question is not behaving properly. It would be best to upgrade it either by a firmware upgrade or physical replacement if possible. If that is not possible, a MTU of 1400 will not kill anything, you will just need to remember that it has to be set.