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?
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:
WYSE->GRE->IPSEC->DSL->MS NLB cluster IP address
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.
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.
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.
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?
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...