Topic: Can't get WinXP to talk to SME, WIn2k works great...

[ritterhaus]

This is driving me a little daffy, as I can find no other mention of this anywhere on the 'Net. Am I the only one with this problem??

The default pptp server is running on SME 6.0.1. I can connect from Windows 2000 machines, but not Windows XP. No WinXP client I have will connect. I reloaded a laptop with a dual-boot XP (no  service pack) and Win2k and even ran them on the "external" segment of my network (so there's not router between me and the SME server) and 2000 works, but XP doesn't.

What do you mean, "XP doesn't work?" Well, I can connect and authenticate to the prvate network just fine, but I can't DO anything. Try to point a web browser to server-manager, the connection times out. Try to access a remote desktop, or even download a file or view the /var/log/messages file via ssh, and the interface "hangs."

I can find only one error in the system log: mppe_compress[0]: osize too small! (have: 1400 need: 1404); that's it. I've fired up a packet sniffer, data seems to download to the client, but nothing happens on the client side. I've hacked the XP registry thinnking it might be an MTU issue. I've tried logging on from three different XP boxes in three different networks and get the same result. The odd thing is I can't find anyone else who seems to have this prob. I would say this is obviously a client configuration issue (since Win2k works just fine) but it seems to be only my server that's doing this, as everyone else in SME land seems blissfully tunnelng away. Any ideas???

[gzartman]

I think you are going to need to provide a bit more information.  While you've said alot, there really isn't anything in what you have said to help others diagnose what's going. "It doesn't work," in and of itself, usually doesn't get you much mileage, as can be seen by all of the responses to this post.  

I will say this:   I connect to my SME box remotely with pptp using my Win XP SP2 laptop with no problems. The connection is very clunky, even on my 640/256 DSL at home, but it works.

-Start looking through log files and post what might be relevent,
-Detail your situtation,
-Examine any contribs that may be installed on your SME 6 box and/or consider removing them before testing,

Greg

[ritterhaus]

Details, eh?

My SME server is connected to the Internet via DSL. I connect to the VPN (PPTP) from a Windows 2000 professional machine from a remote network. I consider the connection to be successful when I:
-> A. authenticate
-> B. connect to a share
-> C. transfer a file (4 to 5 MB)
-> D. open server-manager in a web browser
-> E. open an RDP connection to the Win2k3 server
-> F. open a VNC connection to my Linux workstation
-> G. run my IMAP e-mail client to the server

The Win2k workstation can successfully get through step E in that list -- I've not tried the others siince, if RDP works (fat as it is) then the others should work as well.

I've attempted to connect from two different machines on two different remote networks, one running WinXP Pro SP2 and all the latest patches, and one running a bare WinXP Pro install unpatched except for the addition of 128-bit encryption. In both cases I can get through step B in my above list. Nothing else works. The client application hangs, and packet captures indicate an eventual time-out and the server closing the connection.

I set up my test laptop on the external network segment to my SME server, so that there is no router or external firewall between it and SME. I configured the laptop to dual-boot Win2k and WinXP Pro. One machine, two OSes, same behaviour: 2000 works like a dream, XP can only access shares.

The symptoms are reminiscent of MTU issues, so on one machine I tweaked the MTU settings in the XP registry, but it did no good. There are no errors in the XP event log, and the SME syslog ony displays the one error I listed in my last post, Jan 22 22:23:14 orinoco kernel: mppe_compress[0]: osize too small! (have: 1400 need: 1404).

The only non-standard thing this SME server does is NIS, as some of my local users run Unix workstations and I haven't had time to play with winbind. I'm not sure how NIS could selectively prevent WinXP hosts from using the VPN. Everything else is stock SME.

[pistonpilot]

I'm not sure if you are joining the XP clients to the domain or not, but if you do, you will need to add the following registry entry:

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netlogon\parameters]
"requiresignorseal"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Netlogon\Parameters]
"requirestrongkey"=dword:00000000
"requiresignorseal"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\Netlogon\Parameters]
"requirestrongkey"=dword:00000000
"requiresignorseal"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"requirestrongkey"=dword:00000000
"requiresignorseal"=dword:00000000

[Damian]

On XP, right click on the VPN icon and select properties.
Click on the Networking tab
Click on the Settings button
"Enable LCP Extensions" should be checked
"Enable Software Compression" should be checked
"Negotiate multi-link for single link connection should be checked

Damian

[ritterhaus]

Thanks to pistonpilot and Damian. The VPN is SAVED!

Actually, the developers connecting to the VPN from home are not joining their machines to the domain, so I didn't need those registry hacks, but I appreciate you taking the time to help out, pp.

Damian, the only thing I didn't have selected was multilink. I'm not sure why this was needed (XP mutiplexes communication over several braodband channels? I thought the hardware would normally do this? Am I barking up the wrong tree?) Nevertheless, it fixed my problem and we can VPN to the network.

Thanks again, all.

[Damian]

We had the same thing with client SME boxes. I captured the IP packets and had a good look. It's something to do with the MTU size on SME (1400) matching the XP MTU size but then when you add the VPN encapsulation (extra 4 bytes) it creates packets larger than SME accepts (1400 bytes becomes 1404 IIRC).
That means every full packet from XP is discarded by SME as being oversize but any fragment packets (less than 1396 bytes before VPN encap) are passed OK. TCP retries seem to mask any errors as none show up on the XP box.
Setting multilink forces SME to go to 1600 bytes - thus removing the problem.
That's as good as I remember it but don't quote me. Important thing is .... it works  

Damian