Terminal Server through Site-to-Site PIX VPN

[jdeaner]

I have a problem accessing a terminal server through a PIX 515. We have a site-to-site VPN that works fine one way but not the other. We can ping all we want to each other and I can go across the vpn to a terminal server but I just get a timeout the other way (the same goes when trying to trust domain). I know TS has a hard coded timeout of 120ms, can this be changed? The problem is that a terminal server and pc-anywhere both timeout when trying to connect from T1 to DSL. I believe this has to do with the DSL connection, which is a little more than 128k. The other site has 1/2 T1. When I do a ping I rarely get any response times under 500-1000ms from the 1/2 T1 side to the DSL side. The main difference between the 2 PIX config's is that one uses dynamic maps. Any input besides a faster provider would help. Thanks!

 

[marsmann]

...along the lines of "faster provider", you could be running into legitimate speed issues.

You didn't specify whether both PIX's were configured equally allowing the necessary TS traffic to each other, so I'm going to assume the configs are fine.

That being the case, your problem is most likely due to your DSL connection. I'm willing to bet you are running an asynchronous connection, and with a "download" speed of 128k your upload speed is most likely half of that. The VPN overhead is taking up all the bandwidth on the return traffic from the DSL connection. Low Speed Async connections are vpn killers. You may not need to change providers, but find out whether they will offer a synchronous connection for your DSL service. If this is the case, your VPN will never work properly under those conditions. Async DSL sucks for this type of thing. It will always be slow, patchy and experience timeouts.

Satellite Internet is another really sucky setup for this. Never consider sat inet for vpns... or wireless access points.....

Personally, I prefer 384k/384k connections and better for any vpn related services I configure.

Talk to your provider - run bandwidth tests between sites and see what speed results you get. I guarantee your TX and RX between sites will vary greatly.

 

[jdeaner]

That's what I was expecting. Thanks for the info!

-Jason

 

[yizhar]

HI.

You should also try to lower the MTU on the terminal server and on a test client. Try first a realy low value like 500.

Both the VPN and some DSL implementations add their overhead to packets and might cause fragmentations and related problems.
So try and see if lower MTU can help here.
You can also play with "ping -f -l ???" to test for best MTU value.

Another option to consider - since you have fixed ip addresses at each site, you can try direct connection from one site to the terminal server on the other, without VPN, bye simply using static and access-list to open TCP port 3389 as with other services.
This test will help you check if the VPN is related to the problem, and this can also be a good workaround, and can be used with additional OS built in security features.

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[jdeaner]

I've tried the static IP mapping several times, even on-site, and still there was no luck. Here is what I get from doing a ping test from the main location to the remote location:


**This is the
Highest I can
Go and still
Be in the 110ms range**

C:\>ping -f -l 100 10.40.10.2

Pinging 10.40.10.2 with 100 bytes of data:

Reply from 10.40.10.2: bytes=100 time=110ms TTL=128
Reply from 10.40.10.2: bytes=100 time=109ms TTL=128
Reply from 10.40.10.2: bytes=100 time=109ms TTL=128
Reply from 10.40.10.2: bytes=100 time=110ms TTL=128

C:\>ping -f -l 1416 10.40.10.2

Pinging 10.40.10.2 with 1416 bytes of data:

Reply from 10.40.10.2: bytes=1416 time=437ms TTL=128
Reply from 10.40.10.2: bytes=1416 time=422ms TTL=128
Reply from 10.40.10.2: bytes=1416 time=422ms TTL=128
Reply from 10.40.10.2: bytes=1416 time=422ms TTL=128

Ping statistics for 10.40.10.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 422ms, Maximum = 437ms, Average = 425ms

C:\>ping -f -l 1417 10.40.10.2

Pinging 10.40.10.2 with 1417 bytes of data:

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.

Ping statistics for 10.40.10.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\>

Unfortunately, I cannot gain access to the physical servers at this time due to location. Am I correct by thinking that the only way to change the MTU (for TS as well) is through the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and add a new DWORD 'MTU' with some decimal value

Can the MTU be changed anywhere else? Also, a little more information on what this ping test actually tells me besides the connection stinks, could help. I am in the midst of trying to debug the PIX on the remote side to see if the tunnel is passing correctly.

-jason

 

[yizhar]

HI.

The default MTU for Etherenet is 1500.
The test shows that you should configure a value of 1416 or lower.
The added encapsulation of the DSL or VPN or both causes the problem.

There are many utilities to set the MTU so you don't have to directly mess with the Registry.

It is best to set the MTU on both sides of the connection.

Bye
Yizhar Hurwitz

http://come.to/yizhar

http://teachers.sivan.co.il/yizhar

 

[jdeaner]

Thanks for the knowledge! Everything is working fine now. Seems I must not have done a WRITE T on the PIX after adding the SYSOPT PERMIT IPSEC command.

-jason