Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Connecting to remote server

Status
Not open for further replies.

obryant32

IS-IT--Management
Feb 20, 2003
66
US
OK,

Here's a fun one for you. I have the following scenario that is not working. On our network, let's call it Network1, we have a Sonicwall 2040 set up as our firewall. We also do work with a remote company that has a Microsoft ISA server 2000 acting as their firewall on what we'll call Network2. We have a user inside of Network1 that needs to access a computer that is located inside of Nework2. So, on said user's computer we set up a VPN connection to Network2 using Microsoft's VPN wizard. We are able to succesfully connect and authenticate and we get an IP address. We then attempt to use Remote Desktop connection to connect to the resource on Network 2. It connects, but freezes and then eventually the VPN connection disconnects.

Does anyone have any suggestions as to what could be causing this?

Thanks
Matt
 
I would suggest the MTU on the client PC and server. I'm not sure if you allow icmp traffic accross your networks but you can test for MTU blackholes using ping

the connand you need is ping XXXXXXX -f -l ZZZZ

ZZZZ is the size of the packet your sending in theory when you send a packet over the MTU of the system it will tell you that the packet needs to be fragmented if you send under that limit the reply comes back.

The situation you may have is where you send a big packet and the system doesnt tell you it cant be sent and you never get a reply cos the packet is too big.

Test Plan>
1) connect to vpn
2) ping the required host with out using additional switches (verifiy end to end connectivity)
Ping host using switches

test sizes starting with 1480 if it comes back
Packet needs to be fragmented but DF set.
Lower the size in 25's and see if there is a point where
The packets stop replying just goes Request Timed Out

If this happens download DrTCP from and use it to set the MTU size on both ends to 1300 then reboot both ends, and retry your connection!

Skr
 
You also need to check the MTU on the firewall routers, from the server side to remote and the remote to server. Needed MTU sizes can vary from both ends

Use the pathping command from server to remote and do the reverse. Packet losses should be few if any if the MTU size is set correctly at the firewalls

........................................
Chernobyl disaster..a must see pictorial
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top