Working installation now broken after upgrade

[rickcrites]

My installation of VPN version 1.0.7 was working fine until two days ago.

The auto-update system suggested I upgrade. So, I did. At both ends of the VPN.

Now, my system tunnels and connects, but neither the server nor the client is accessible from the other machine. I cannot browse or see shared folders from either end.

I have checked my home (client) machine and find that the "computer browser" service is active and starts automatically. I found that the office (server) computer also had the same service active and starting automatically, but have now disabled it at that end.

If I try START | RUN and \\the IP address of the host, I get "The network path was not found."

When I open WinGate and look at the Accessible Networks, on this computer (home/client), under routes, I see: 'the IP address of this computer '/ 255.255.255.255 "(forcibly enabled)," which is unusual. From the office (server) end, I see the same route as "(Ignored / Local conflict)." This doesn't seem to be a good sign.

What in the heck could be going on here?

When I upgraded, I only downloaded and installed the VPN upgrade. I did not install the Wingate upgrade because 1) I didn't think I needed to, and 2) when I did think to try that, the install program had so many unexpected and confusing options and questions, and informed me that if I uninstalled my settings would be lost, etc. , that I bailed out. I don't need or want all the Wingate features and options. The computers at both ends of the VPN have broadband service with NAT routers and DHCP, etc. So, I don't need WinGate's NAT or DHCP or proxy server, etc.

I am tempted to just roll-back to the previous version. I need to quickly get this back to a working condition. But, if someone can quickly help me sort this out, I won't.

Help, please...

EDITED 11/22/03:

This problem has not gone away. None of the DOZENS of experiments I have tried has yielded any significant change. Does ANYONE have ANY ideas about the "forcibly enabled" and "ignored / local conflict" messages?

I have discovered that I can get the system working for a short time by rebooting the server (office) computer. The above messages disappear for a time and I can use the VPN. Then, within an hour, the messages reappear and the VPN stops working. The only solution then becomes rebooting the server again.

I could really use a hand here...

Rick

[adrien]

Hi

What are the actual IP address ranges you are using at each site on the VPN. Normally you only get any sort of conflict in routes if IP addresses in the same subnet are used. What network masks are you using in the adapters on the WinGate VPN server and client machines?

We made some changes in VPN 1.1 regarding updating of routes, and specifically the way WinGate VPN remembers whether you have decided you want to publish a route or not.

If you never did anything to the routes other than the default, it is possible we missed an upgrade scenario. One way to clear this is in the registry, if you open regedit.exe on the VPN client, go to

HKEY_LOCAL_MACHINE\Software\Qbik Software\WinGate\VPN\Join\1\LocalRoutes

you can safely delete any subkey from here. We no longer store the route unless it is an override from the default dynamic behaviour.

Adrien

[rickcrites]

Both computer networks are behind Linksys NAT router/firewalls.

The client machine (at home) is set with a static IP of 192.168.1.100. It is part of a home network that is not part of the VPN, and which has IP addresses assigned by DHCP to start with 192.168.1.101.

The server machine (at the office) is set to a static IP of 192.168.2.200. It is part of a small network that is (or should be) part of the VPN, and which has IP addresses assigned by DHCP to start with 192.168.2.201

Both use sub-net mask 255.255.255.0, as that is the default for the routers.

I have ZoneAlarm at both ends, but it does not seem to effect the problem. I have tried disabling ZoneAlarm at both ends with no apparent difference.

This setup was working under the previous version.

It seems that when I reboot the server, the routing table is cleared and the system sees the routes correctly. Then, after a period of time, one machine or the other seems to start thinking that it needs to start publishing the routes of the other machine. Then, suddenly, there is a conflict and the VPN stops working.

I have turned off RIP2 transmitting and listening on both machines, and on the one router that has that as an option that is changable. That seems to have no effect. I also shut down the "computer browsing" service on the server machine. So, now, only one machine on the network has this service enabled. I seems to make no difference whether I set either or both machines to publish only the local machine or the local network routes. Nothing seems to make any difference. I have spent countless hours fiddling with settings and trying things to isolate and handle the problem. No joy.

Does this shed any light on the subject?

I will check the registry entries you suggested and let you know what I find.

Rick

[adrien]

Hi

Sorry to take so long to get back to you!

We made some changes in the way that the ENS driver hooks NDIS with the release of 5.0.8 onwards, so from 5.0.7 to 5.1 or 5.2 is a fairly different driver in terms of that hooking. This does come into play significantly when it comes to other products that have hooking drivers.

It is possible that the ZoneAlarm will be causing problems (even if it is not started, since their driver will still have to load at system boot to be there for when the app starts).

If it is a simple test, I would recommend trying removing ZoneAlarm completely from both servers. If this fixes the problem, then let me know and I will look more into ZoneAlarm compatibility as well.

Adrien

[rickcrites]

I did upgrade from 1.0.7. So, those changes you mentioned are probably the root of the problem.

I will set the ZoneAlarm to not load at system start. This sets the service (TrueVector) to 'manual' instead of 'automatic' and should (unless I am mistaken) cause it to load only when demanded by the program.

I have discovered another anomally and don't know what to make of it. Perhaps you will have some idea. Matt asked whether I can ping the external address of the other machine when VPN is connected. I find that I cannot ping ANY address beyond my router's default external gateway (24.96.0.1). I have turned off ZoneAlarm, and tried to disable the firewall in Wingate. I can't seem to get any ping out to anywhere. I can traceroute, with no problem, to any location. But, no ping. Could my ISP be blocking ping? I can hardly imagine that..... I will look for the switch that sets the VPN to load at system start, and will try disabling that. I should be able to ping the net somehow.

Any other ideas?

Rick

[Pascal]

Perhaps you will have some idea. Matt asked whether I can ping the external address of the other machine when VPN is connected. I find that I cannot ping ANY address beyond my router's

Can you ping the internal address of the host when you are connected, though ?

[rickcrites]

I can get the VPN to work for about 15-30 minutes at a time by rebooting or (sometimes) shutting down the Wingate engine and restarting. During that "up" time, I can ping the internal address (assigned by the router) of either machine from the other machine.

Then, spontaneously, the VPN crashes and the distant machine shows as "(not accessible)." The pattern is the same regardless which machine I am sitting at and watching. When the distant machine is "not accessible" it is not possible to ping that distant machine.

At Adrien's request, I have disabled ZoneAlarm so that the service does not automatically load at system start. The service ("TrueVector") is now off at both ends. Unfortunately, the pattern described above just happened again. The VPN was up for about 20-30 minutes, during which time my contact management software was able to get part-way through its synchronization routine. Then, the VPN went down and will probably stay down until I reboot the server at the other end.

Did I see some mention on a forum post of a need to reset the MTU to avoid getting a routes problem/conflict? Is that the MTU setting on the NIC card of the computer, or a setting of the router? Is that something I should be trying to change or not?

I appears to me that the problem revolves around some factor that is causing a route conflict. That was obvious when the message "ignored / local conflict" was occuring all the time. But, even though the messages have subsided, the pattern remains much the same.

So, ZoneAlarm doesn't seem to be the culprit. What else could it be?

Rick

[adrien]

We have had another report lately of a situation where an end of the VPN tries to publish routes it learned from the other end back to this other end, causing a conflict.

The only way I can guess this might happen is if RIP is learning the routes from the other end, then publishing.

What are the 3 RIP settings set to in the VPN General configuration in GateKeeper? Normally you only need the top of the three options set.

Adrien

[rickcrites]

This sounds like exactly what is happening. I have had this idea myself.

This end of the VPN is set to the default RIP settings: Listen on, send on and publish off. I am certain that the other end is set the same. I intentionally left them in the default configuration after I uninstalled and reinstalled the new version a few days ago.

I have RIP disabled in the router at this end; both transmit and receive are off. The router at the other end does not have a way to set RIP on or off that I can find. It _could_ be listening and republishing without me being able to do anything about it.

Shall I change the settings in Gatekeeper? I am certain that I have tried turning those setting off in the past, but not lately. Perhaps not since the last upgrade.

Rick

[adrien]

I would try turning RIP listening off in GateKeeper at both ends.

This is really only useful if you have another RIP sender on the network (i.e another VPN, or other subnets through a router) that you wish to publish over your VPN.

Adrien

[rickcrites]

For the sake of making the data available to readers of the forum, I am going to post here the data from my email exchange with tech support. I hope this is ends up being of help to others.

============================

I seem to have perhaps stumbled onto a solution. The VPN has been up for over 12 hours now - a record for recent times.

Here are the changes I made yesterday that seem to have made the difference. I am not sure which one is the key, but you may have enough additional knowledge to recognized the pertenant one.

I was in the "properties" area of the TCP/IP protocol for my adapter on the home (WinXP) computer. I notice that "Register this connection's address in DNS" was checked. It occurred to me that "registering" this address could be part of the problem with the routes. So, I unchecked this.

I also noticed that in the "settings" area of the properties of the "internet connection" in my "network connections" the ports and protocols of the VPN are on the list of devices that can be shared/opened to host internet services. Somewhere along the line, I had experimented with checking these boxes to be sure that the ports were open and available (808/UDP, 808/TCP, 809/UDP and 809/TCP). This was one of the dozens of things I have experimented with over the past weeks to try to get this problem solved. Yesterday, I found these boxes checked and decided to uncheck them. So, there are now no boxes checked in the connection sharing settings.

And, finally, I noticed that I had QoS (Quality of Service) Packet Scheduler service installed and active for my NIC adapter. Since I did not recall ever installing that service, and do not recognize it from working with other NICs and other operating systems, I decided to uncheck the box for that service and see what happened.

Unfortunately, that is three changes at the same time. It makes it hard (for me) to know what change might have been the key one. So, I intend to now individually add some or all of these back in and see what happens. If you can tell me which ones probably were not involved, or, for example, whether the QoS service is important to have inabled, I will appreciate it.

All of this occurred before I got your note about the MTU changes. So, I have not made those changes.

Can you give me any feedback about the changes I did make, and which might be the key one?

I will let you know what else I determine.

[rickcrites]

Unfortunately, the problem is not completely solved.

I am no longer getting the "ignored / local conflict" message at the client end. But, I still get it occasionally at the server end. Fortunately, I seem to be able to fix it by stopping and restarting the Wingate VPN Engine at either end (as opposed to having to reboot the server). Then it runs fine for a while.

I am now ready to make the MTU changes that you recommended, but cannot find the place in the OS to do it. Can you clue me in on where/how to make that change?

Rick

[adrien]

Hi Richard

We found the cause of a couple of problems with the VPN today.

We will be releasing a fix soon this week, however I can send you a special engine which resolves the problems before that if you wish.

The other problem with the VPN we fixed related to NetBIOS name lookups over the VPN. This was broken if there were any entries in the list of ports to relay that were disabled. Looks like the fix for this from before was not a good one, but we have tested this thoroughly now, and it seems solid.

Adrien

[rickcrites]

I would be glad to try the new update. I probably can't make things worse. ;-)

I think you have my email address through the priority support line. I have been corresponding with Matt. You can send me the file, or send me a link and I will download it.

Thanks for your help.

Rick

[ajdionne]

I have the identical problem. Can you post fix or email it to me.

Running Wingate 5.2 on Server and 1.2 VPN standalone on client machine.
Ran well in older version until I have upgraded. Ineed this fix A.S.A.P


Regards

Andre

[adrien]

Hi

the downloads are now available on our download link at

http://www.qbik.com/download.php

Adrien