Re: IOS VPN and Wyse Terminal

seth.wilson · ‎09-16-2005

We have remote sites with a VPN over DSL. We are using GRE tunnels and IPSec on a 3825 router at the central site and 1841 routers at the remote sites. We have a problem with the Wyse Terminal 1200LE connecting to a Microsoft Terminal Services cluster over the VPN. Works fine over frame-relay, works fine using RDP to any individual server in the cluster or any individual server outside the cluster. RDP to the NLB cluster works fine from a Laptop PC.

Protocol analysis shows that the Wyse Terminal seems to start ignoring the packets sent by the server about the time that the mouse begins moving.

GRE and IPSEC through Cable modem does not have problems only through SBC/Yahoo DSL. We have multiple sites not working though SBC/Yahoo DSL.

Doesn't seem to be a MTU problem either as the packets that start missing are less than 100 bytes.

I know it is a longshot but... has anyone run into this?

thomas.chen · ‎09-22-2005

To the best of my knowledge, you can check with Wyse Terminal related support team. Looks like the problem is not related to VPN or the ISP.

seth.wilson · ‎09-26-2005

Bump for someone to throw me a bone here.

I opened a case with WYse. They are supposed to call me back today.

I have attached an Ethereal trace. I can save it in other formats for anyone who does not have Ethereal.

At 15 seconds all appears normal, I have logged into the NLB cluster, I have a desktop, icons and a start menu. At 30 seconds, I move the mouse and start trying to click stuff. You'll see that the terminal (10.0.65.152) sends an ack to the last server (10.0.0.10) packet along with the rsh (assumed to be the mouse movement). The terminal continues to send it out for nine seconds. There are acks from the server to these packets. The terminal seems to ignore them and keeps blasting out the packet.

Packets 872 through 894 are tcp retransmissions. I might think there is a problem with these packets going through the VPN due to the the 1500 bytes size. But the df bit is not set. They should get fragmented through the VPN fine. I would think MTU problems would be manifested in any of the other scenarios i have tried. Again just to clarify... there is only one scenario that this doesn't work:

Not working:

WYSE->GRE->IPSEC->DSL->MS NLB cluster IP address

Working:

WYSE->GRE->IPSEC->Adelphia Cable->MS NLB cluster IP address

WYSE->GRE->IPSEC->DSL->Cluster member actual IP address

PC->GRE->IPSEC->DSL->MS NLB cluster IP address

All other forms of network traffic (DNS, DHCP, Printing, Pings etc...) work fine.

seth.wilson · ‎09-29-2005

Took the IPSec portion of the tunnel off. Still the Wyse Terminal will not connect properly with the NLB. It's funny, we have tunnelled strictly IPSec over DSL between the 1841 and a PIX 506 before. Wyse to the NLB worked flawlessly. I am going to try that.

Also not working:

Wyse->GRE->NLB

seth.wilson · ‎09-29-2005

Okay, I took the GRE tunnel out of the picture and tunneled strictly IPSec to a PIX firewall at the site where the server farm resides. Connections to the NLB work fine.

Working:

Wyse->IPSec->NLB

Granted this scenario is running through a PIX 506 not the 3825 router that the GRE tunnels are running through.

The problem is either:

1) Bug in the Wyse Terminal (Case still open, Wyse has Ethereal trace with terminal spitting out endless acks)

2) Some random problem with running GRE over SBC/Yahoo DSL while connecting to MS NLB with Terminal Services

Seems strange that the GRE did not work. The GRE-tunneled packets should have been entirely encapsulated within an IPSec packet. I might be wrong here if the IPSec is done in transport mode (which it is). Anyone have even a remote idea what is up here?

seth.wilson · ‎10-24-2005

Okay, here is an odd one... it works fine with Verizon DSL.