XP SP2 and XP's VPN Client

[najitaka]

M$ responded to me and told me to restore my system to SP1 until they could fix the problem.

 

[AcidGreg]

Hello everyone!

I have a similar problem...

I have a network setup that looks like this:

VPN server (part of a LAN) <---> ROUTER <---> ISP (ADSL [static IP]) <---> ISP (ISDN dial-up dynamic IP) <---> VPN client

The router is configured to allow incoming PPTP traffic, and forward it to the VPN server's IP.
The VPN server is the simple Windows XP PRO incoming VPN connection capability...
The VPN client is the simple Windows XP PRO VPN connection [Add new connection, etc.]...
The VPN is configured for PPTP, and the client is configured to have static class C IP address (192.168.0.22).
The VPN server has a class C IP address too: 192.168.0.3.

Now before SP2, I used to be able to connect from the client using PCAnywhere through VPN to the server (which runs a PCAnywhere host service) through VPN. Now, although the VPN connection is established, the PCAnywhere connection times out. I tried to ping 192.168.0.3 (the VPN server) from a command prompt and it doesn't respond. I then tried to ping some other machines in the VPN server's LAN, also running XP PRO SP2 (same rules as the server) and the respond OK. One of them also runs a PCAnywhere host service in which I can connect to, and ping successfully!
It seems that somehow the SP2 firewall blocks the VPN-incoming data when they are destined to that same machine that hosts the VPN server...

Until now it seems like the problem you are describing above... However, I have tried setting up a PCAnywhere client in the VPN server's LAN and tried to connect to the server from there, and I can connect OK! I can also ping the VPN server's machine successfully from the local LAN.

So far, the workaround to my problem has been to setup a PCAnywhere client along with the host service in the machine I can connect to [not the VPN server machine, which is the one I want to control with PCAnywhere] and after connecting from home with PCAnywhere to it, connect from it again with PCAnywhere to the VPN server's machine, effectively bypassing whatever VPN/SP2/loopback problem is there. The whole process is very slow ofcourse, being a double PCAnywhere session, but... I couldn't do anything else.

Any ideas?
(I haven't tried the aformentioned suggestions, but I will try them really soon on the VPN server machine. The client also runs SP2 but I guess that's not the problem, right?)

 

[fblack]

I'll give you a little more detail about what I do and maybe you can apply it also.

-Connect the VPN.
-Open a DOS window
-Type IPConfig/all and get the IP address for your VPN (in this example I'll use 192.168.4.10)
-In the Same DOS Window, type the following
-ROUTE ADD 192.168.4.0 MASK 255.255.255.0 192.168.4.10 METRIC 1
Which is ROUTE ADD <target network> MASK <target network subnet mask> <interface to use - the IP address assigned to you by the VPN> <metric>
-Now the VPN will work.
-You'll have to do this each time you connect the VPN

assumptions in the above example
-192.168.4.0 MASK 255.255.255.0 is the target network (inside the VPN) and is a full class C. You will need to use your particular parameters.

Fred

 

[dbergtkd]

The "official" word from our M$ rep is to upgrade the DHCP server to Windows 2003. Once this is done, you can setup static routes for a certain range of numbers such as numbers doled out to VPN clients. We have done this and it does seem to work. It also does not seem to break pre-SP2 machines. Good luck.

 

[AcidGreg]

I tried what you say..
ROUTE ADD 192.168.0.0 MASK 255.255.255.0 192.168.0.22 METRIC 1

No improvement.. It has to be due to the bug Microsoft issued that hotfix for. It says that the firewall blocks traffic to loopback addresses other than 127.0.0.1. That would be my case as the traffic is directed from the VPN connection to the loopback address 192.168.0.3 (which is the IP of the machine hosting both the PCAnywhere host I wish to connect to and the VPN server...).

What is that hotfix anyway? A downloadable file or a registry hack? Has anyone contacted Microsoft and got it already? There is no download link; all it says is "contact us", etc.. I am not in the mood of paying more money to M$ because they didn't see this coming, and they don't consider it serious enough for a publicly available patch!

 

[MainframeGuy]

OK Acid - understand your frustration... this hotfis is, I hate to tell you, not something thatg I think will help. I got hold of it - it is a version of TCPIP.SYS which is essentially the pre-SP2 version, leastways that is how I understand it. There is also a registry mod which is DEFINITELY not going to help as that is for the non PPTP VPN protocal (I forget the acronym). Basically the bad news is you need to listen to what the previous poster said - I get a feeling here that M$ are looking to make any changes at the server end and NOT with the clients. Basically they are tightenning up, in a most tight assed way (IMHO). VPN used to be nice and friendly, it retained password ADN encryptionh security so I personally see no risk there - however M$ in their infinite wisom do.

I suggest raising an incident with them - and mentioning you know others have issues. I did this and have only had bullshit so far - bot if enough do it then surely we all together add up to more than M$? If not I want to die and go to Linux / FreeBSD heaven!

PS if you still want the old TCPIP.SYS you can probablyu google a download - if you don;t PM me and I'll see what I can do.

 

[fblack]

Originally posted by: dbergtkd
The "official" word from our M$ rep is to upgrade the DHCP server to Windows 2003. Once this is done, you can setup static routes for a certain range of numbers such as numbers doled out to VPN clients. We have done this and it does seem to work. It also does not seem to break pre-SP2 machines. Good luck.

That's not right - Did the M$ rep ever think that a lot of people connect to devices like routers and firewalls with VPNs?

Fred

 

[AcidGreg]

Well I have replaced the SP2 version of TCPIP.SYS with the newer one Microsoft released with the hotfix, which you can find here: http://bink.nu/?ArticleID=2391

Anyway, when I get back home, I will post the results. Hopefully it will work now...

 

[fblack]

I installed the hotfix - no change - it still doesn't work. In fact, if you're fast enough, you can see that the correct route is added to the route table when the VPN connects, but it quickly goes away. I still have to manually add the correct route.

Fred

 

[MainframeGuy]

Yeah Acid, as fblack said, I think you are probably going to be disappointed - for me it improved things slightly, insofar as I needed the updated TCPIP.SYS to even be able to ROUTE ADD and redirect my telnet session through, but I do not have anything like the convenient operation I had before (have to do that manually for each VPN session I have) plus still unable to connect to Exchange server for my emails.

Interesting how entirely inconsistent M$ are in their response to what remains, essentially, the one problem! There must surely be someone within M$ who actually knows what they changed, and why, and could either address this or explain the action?

 

[AcidGreg]

Well applying the hotfix did nothing, just as you predicted...
I am going to apply it now to the client machine too, and check another time.
The whole ROUTE ADD thing is supposed to be done on the client machine, right? Just after establishing the VPN connection...
I am going to try that too one more time.

 

[MainframeGuy]

Yes Acid - you have to do it on the client and after making the VPN connection - think about that - so that you know the IP address the you connected on for the last two digits of your command! Hope it helps you workaround. It's annoying it has to be done then and is dynamix - means you cannot slipstream it into the win.ini file or anything

 

[AcidGreg]

Applying the hotfix on the client did nothing either...

Well the ROUTE ADD is no problem because in my case the VPN client's IP is statically configured to be 192.168.0.22. I could possibly have a batch file or something to run after the connection. However it did not work. I used this:
ROUTE ADD 192.168.0.0 MASK 255.255.255.0 192.168.0.22 METRIC 1
The LAN adapter IP on the VPN server (and PCAnywhere host) machine is 192.168.0.3, so I use the 192.168.0.0 MASK 255.255.255.0.
As I said before the VPN client is statically assigned the IP 192.168.0.22, so I used this too.
I did this in a command prompt after establishing the VPN connection to the server. I still couldn't connect to the PCAnywhere host nor ping the server for that matter...
Then I thought of something. I rebooted (to be sure the manual route was erased from the route tables) and reconnected to the VPN.
The VPN server is configured to automatically assign IP addresses to the clients in the range of 192.168.0.x, where x is 20-30.
The server holds itself the IP 192.168.0.20. I tried to connect to it instead of 192.168.0.3, which is the normal (LAN adapter) server machine's IP and TADAaaaaaaaaaaaaaaaa IT WORKS!?

I don't know if the hotfix had something to do with it. PRE-SP2 I was able to connect to 192.168.0.3, but I had never tested 192.168.0.20 to see if I can connect to it too. The sure thing is that after SP2 I can't connect to 192.168.0.3. Now the ability to connect to 192.168.0.20 might have come from Vanilla XP PRO, SP1, SP2, or the TCP/IP hotfix. I don't know...

Anyway for the rest of you people here: Try to use the IP address that is assigned to the VPN server interface. Might work for you too..

 

[EngenZerO]

i actually did an expirment... my cisco vpn client in sp2 as long as the vpn client is installed and ran before the sp2 update. I ended up having to reformat two of my boxes so that they could have vpn software so I could work from home. go figure.

 

[AMCRambler]

I'm not sure if you guys have done this but there's a second place you have to disable the firewall for SP2. The first is the advanced tab under the network connection properties where there is the radio buttons to enable and disable the firewall. On that tab there's also a button, I forget what it sais because I'm on a 2000 machine now and can't check, but under there it actually lets you specify specific types of traffic to allow or disallow and there's a top level check box to enable this for the network connection. Even after I disabled the firewall on the tab and hit apply, ftp was still being blocked on me. So I went looking around and found that checkbox still checked. Unchecked it and ftp started working. Perhaps this is still set on yours?

 

[MainframeGuy]

Does anyone know if M$ ae going to move anywhere on this one? Believe it or not I have gone so far as to build myself another rig and I am holding that one at SP1 because of this exact issue so that I have the convenience of VPN on my main rig.... Talk about overkill!

 

[najitaka]

The last response that I got from M$ is that they were working on a fix and they would let me know when it is ready. That was around 9/9/2004. I've been using the route add workaround found in this thread for the past two months for my VPN connections that are having this problem. Not all of my connections require this workaround, some work fine without the route add. I think it depends on the server that is hosting the VPN connection or some option with the connection.

 

[MainframeGuy]

OK - thread resurrection time! I really hope someone will pick up on this..... the issue has resurfaced for me and this time it is more severe! First thing though - has anyone heard ny good news? Any SP2 fix or other workarounds?

I particularly ask the latter question because I have relocated and reconfigured my network (it is now a bit complex with Dlink DSL-G604T modem/router for access and Linksys which refuses to be a WAP!) and no longer can I use the ADD ROUTE workaround.... either that or I have fogotten how you derive the first IP address (I thought it is the IP for the VPN server, but when I try that it says invalid mask because they are different from the one I connect when I (successfully) dial into VPN. Maybe my company has made some changes to their VPN server, but not that I am aware of - and of course it will still work with SP1 but right now I only have my laptop running at that level!

If anyone can offer any help it would be much appreciated!

cheers

 

[wondersteve]

I have run into the same issue with users at my work, try this:

Disabling the Firewall
Go to Start, then Control Panel.
Go into Administrative Tools, the go into Services
Look for the service ?Windows Firewall/Internet Connection Sharing (ICS)?, double click on it.
Service should be Started, Stop it.
Change the startup type to Manual or Disabled, so long as it does not start up the next time the computer is restarted.
Click Apply and close the service entry.
User should be to continue the install of the VPN client and connect.

 

[MainframeGuy]

thanks WonderSteve - but just tried that and it made no difference

 

[skyking]

Is there a third party VPN client that you can install? This is a bewildering problem to say the least. I was going to set up VPN access at a new customer, but the machine I would have them use is being shipped with sp2, of course

 

[imported_Oz]

Similar problem: XP2 client, PPTP connections. For 5 to 10 seconds after connecting the VPN, I can reach through, but after that, not. More specifically, I can ALWAYS reach through as long as the target address is on the same subnet as the address the VPN DHCP server gave me.

Here's why: as an example, when I first connect, a route is added that looks like this:

10.0.0.0 255.0.0.0

I am given a 10.65.128.X address. The target servers are on 10.89.10.X

With the class A mask and address, the route is clear. But within 10 seconds, with no action by me, the route changes to:

10.65.128.0 255.255.128.0

In other words, it becomes a modifed C, and clearly the 10.89 routes will no longer head that way because the mask and address forbid it.

So this is clearly some problem with how it is handling VPN routes. Feel free to bug MS about this, because it is 100% their bug.

I may just add the class A back in manually....

 

[MainframeGuy]

Yeah - I wish M$ could be bugged enough to change this! They should not get away with stuff like this - but they do... not only am I bugging them personally (although I have to admit giving up now) but the company I work for - a multi-million $ outfit that is in the software business! is bugging them and can get no resonse - so there ya go - switch to a Linus VPN client and you should be fine, hey?

 

[MainframeGuy]

Well - just to wrap this one up now SP2 is a foregone conclusion.....

I am still using the "add Route" aorkaround to TelNet with SP2 and VPN - looks like I will forever be entering that command at least once/day because it cannot easily be scripted...

And as for my Outlook connection to Exchange Server - well someone at work hit the same problem, but found a way around it by adding an additional DNS server to the set for the primary connection - it seems this additional DNS enables the looking up of the Exchange server so that Outlook can do emails once again.

Between them this works around my problem - but I still have issues with M$ and how they could just "push" this through with a SP that had no business changing things quite so severely from an operational standpoint, IMHO.