Weird Problem

[v3locity]

I have set up Wingate VPN with the following configuration.

LAN 1 >>> INTERNET <<< LAN 2

The Wingate VPN Server is set up on LAN 1 and on LAN 2, a client is configured to connect to the VPN Server. The connection can be established. Both LAN have a router and Wingate runs behind it. Port forwarding has been set up on LAN 1 so that the VPN server can accept connections.

The problem is that, when a computer in LAN 2 tries to connect to a FTP server running on the same computer as the VPN Server, the client in LAN2 cannot download the file. On the server, I can see that the client is connected. But the transfer just fails. It says "Requesting file" on the client. File sharing too cannot work, we can view each other shares, but it normally times out.

Also, on the routers in both LANs, static routes have been configured so that the router knows the route to the VPN clients. I have disabled RIPv2 in Wingate as I have configured the routes manually. Before disabling RIP, the problem still occurs.

All the computers can be ping and the ping times are normal. It ranges from 30 ms to 60 ms. When we try with network games, eg. Warcraft, we could play. But when either party does not have a map and warcraft tries to send it over, the transfer will not work. Gameplay is fine when both parties have the game map.

[Pascal]

Refer to the VPN Setup guide for tests with large ping packets. This sounds as if there might be an MTU problem (Usually seen when packet sizes approaches the MTU).

Try those tests and see if that helps.

[v3locity]

OK. I tried pinging the machines with 1422 bytes of data. All of them could not go through. But if i use the standard ping (32 bytes) it will be fine.

So how do I solve the MTU problem ? What value should I change it to and where do I change the settings? We are using ADSL connection across the VPN.

[Pascal]

http://forums.qbik.com/viewtopic.php?t=3099

This has a good discussion on MTU issues.

[v3locity]

OK. I have changed the MTU to 1350 and most of the file transfer problem have been solved.

Another question is that, let's say I have a VPN client which connects to the Internet via PPPoE (ADSL). He will get a public IP of 218.x.x.x for example and he has a local IP of 192.168.2.2.

When he has connected to the VPN Server, (192.168.0.2) and he tries to download a file via FTP, the FTP Server sees his computer's ip address as 218.x.x.x. Shouldnt the FTP server see his IP as 192.168.2.2 ?? Where as, other clients they will be seen as 192.168.x.x instead of their WAN IP address. Why?

[Pascal]

Depends on what he connects to. If he connects to the external IP of the FTP Server, that will be routed through the Internet normally. Also, a connection by name (e.g. myftpservername.com) will resolve to the external IP and will connect to that.

If the FTP Server is on your local network and he connects to its internal IP, it should be tunneled across the VPN.

[v3locity]

He connects to the FTP Server via the FTP Server's Internal IP, 192.168.0.2 but the server still see's his IP as his WAN IP.

[Pascal]

Any chance you can post the route tables (route print from the command line) for the VPN Server and VPN Client here?

You can mask out your public IP - just want to see what the routing tables look like internally.

[v3locity]

Routes from VPN Server :
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.2 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.2 192.168.0.2 20
192.168.0.2 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.0.255 255.255.255.255 192.168.0.2 192.168.0.2 20
218.111.63.56 255.255.255.255 192.168.0.1 192.168.0.2 20
224.0.0.0 240.0.0.0 192.168.0.2 192.168.0.2 20
255.255.255.255 255.255.255.255 192.168.0.2 192.168.0.2 1
Default Gateway: 192.168.0.1
===========================================================================

Route from Client :

Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 219.95.201.74 219.95.201.74 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.2.0 255.255.255.0 192.168.2.2 192.168.2.2 20
192.168.2.2 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.2.255 255.255.255.255 192.168.2.2 192.168.2.2 20
219.93.218.177 255.255.255.255 219.95.201.74 219.95.201.74 1
219.95.201.74 255.255.255.255 127.0.0.1 127.0.0.1 50
219.95.201.255 255.255.255.255 219.95.201.74 219.95.201.74 50
224.0.0.0 240.0.0.0 192.168.2.2 192.168.2.2 20
224.0.0.0 240.0.0.0 219.95.201.74 219.95.201.74 1
255.255.255.255 255.255.255.255 192.168.2.2 192.168.2.2 1
255.255.255.255 255.255.255.255 219.95.201.74 219.95.201.74 1
Default Gateway: 219.95.201.74
===========================================================================

[genie]

Erm... It looks fine... We have a long discussion today regarding this setup. My thoery was this:

- The client sends connection request to the FTP server
- Client OS checks the routing table and having no route to IP address 192.168.2.x uses the defualt route which is bound to the external interface.
- WG VPN wraps the packet delivers it to the other side where it gets unwrapped and delivered with the reals source address (which is the client's expetrnal IP) to FTP server.
- FTP server uses the default route, which does not go through WG VPN and hence is not VPNed causing the client's VPN support to deliver the packet as it is thus confusing the client.

We will need to run a couple of tests in our test lab to find the best way around this problem.

[v3locity]

Hm.. Lets say in LAN games, my friend (who is the client) hosts a game, i will see that my game connects to his WAN ip. But the connection still works. Weird isn't it ?

[v3locity]

Another question, instead of using the routes on the individual LANs in the network, can wingate VPN act like a PPTP server and distribute IP to the clients ? I think that would be better as it is unlikely to have conflicts.

[Pascal]

Yeah, it will show up the WAN IP. We saw that in QA yesterday. It's simply because of the way routing happens (Default route, because the OS doesn't have a specific destination for your remote network). Traffic will still be encrypted, etc. so that's all good. We are looking at ways to get it to show the 'real' IP; but that will be a while away.

Is WinGate also your default gateway?

[v3locity]

On the LAN where the wingate server is installed, Wingate is not the default gateway for the network. A router is the default gateway and all computers have it as its default gateway. Port 809 is forwarded to the computer hosting the VPN.

Another question, lets say the network on which the VPN server reside is 192.168.0.x and another computer which belongs to another LAN running WinXP ICS wishes to join the VPN. But the problem is that this client's network is also on the 192.168.0.x ( since WINXP ICS sets that as default ), what will the steps required to avoid conflict if I would not want to change the IP of any exisiting networks.

Is that possible?

[organekd]

I've recently been hired to fix a bunch of issues in a small office. They are running Wingate VPN 1.2.3 on NT server 4.0 running SP6. What I find absolutely amazing is that with the VPN software enabled, the server dissappears from the network as if it is hidden. If you go to start-run, and type in the servername as an UNC, the server shares are visable. This happens with the firewall disabled and the local network card set to private/trusted. Apparently the owner of this business dials in, and the server is available over the VPN link. Using the built-in help with Wingate VPN, I have done my best to ensure that all settings have been verified with the documentation. WINS is insalled on the server and it does appear to be functioning correctly. Do you have any suggestions?

Thanks,

Dan.

[Pascal]

Can you post details of the subnets in use? E.g. VPN Installation is "192.168.0.x" while the VPN client is "192.168.1.x", etc.

Also, when the server "disappears" from the local network - is that whenever the software is running or with a VPN link established?

Have you checked if there is a Realtek 8029 card in the server? If there is, you might need to enable the workaround in advanced options. (You will need version 2.0 or higher of WinGate VPN for that however)

[organekd]

The server is using a 3com 3c905B-TX card, and the server is using RAS for dial-in access. Though I think this is a rather unusual topographical connection for VPN, it is how it was set up by someone else..

The current routing table is..
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 169.254.0.3 169.254.0.1 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
169.254.0.0 255.255.0.0 169.254.0.1 169.254.0.1 1
169.254.0.1 255.255.255.255 127.0.0.1 127.0.0.1 1
169.254.255.255 255.255.255.255 169.254.0.1 169.254.0.1 1
224.0.0.0 224.0.0.0 169.254.0.1 169.254.0.1 1
255.255.255.255 255.255.255.255 169.254.0.1 169.254.0.1 1
===========================================================================

What is totally out of the ordinary on this, is how the server name drops from "Browseable" computers, however, if you were to browse the unit directly by invoking the UNC path directly to the server, it does show shares, and the shares will map to the clients. Through the VPN tunnel, everything "Appears" to work correctly.. If I disable the VPN software and restart the server, the server name shows up until the VPN software is once again enabled.

Thanks,

Dan.

[Pascal]

Ah. Try setting a normal, private IP in one of the three recognised ranges. (Rather than using the Autonet address)

[organekd]

Will attempt. He has over 250 pieces of equipment on this network.. It will take me a while...

Thanks,

Dan.

[Pascal]

Hmmm. Can you isolate the test to one or two machines? (Without renumbering the entire network)

[Pascal]

Actually, this is very likely to be your problem. I just had a dig through some old emails. A customer of ours was working with the Canadian reseller/distributor in an attempt to resolve a similar problem, also with WinGate VPN 1.2.3.

Do you recall my emailing you last week regarding this weird WinGate VPN issue? Where you can't see the Server itself. I've just spent the last two hours again trying to get this thing going. :o(
We've tried both version 1.2.3 and 2.x. Varying degrees of success except that the Server is NEVER visible.

After quite a few troubleshooting steps we ended up with this.

Thought you might be interested to know that once we changed the IP addresses from the 169.254.x.x range everything is working. :o)

If you simply renumber the VPN Server and one other machine that should be able to see it on the network you should (Theoretically) be able to test if the same resolution will work for you.

[organekd]

I will attempt the renumbering sequence. I'd just been informed as well, that the numbers currently in use on the network were assigned by the customer's ISP at one point. I will have to validate whether or not they will still be required. I had seen this software on another network about 6 months ago, running a non-privatized IP structure, and the system was working. I suspect one thing that may be worth trying is a re-application of the service pack. NT4 does some rather unusual stuff after things like network cards are changed out, etc. I've been tempted by other issues on his network, to recommend the server gets reloaded with the O/S as I suspect there may be something funny with the network bindings.

I will let you know, how the network renumbering goes. Won't be able to start the renumbering sequence for about 12 hours though...

Thanks,

Dan.

[organekd]

Managed to strike a rather unusual resolution on this one. Tried a renumbering of the network using IP address 192.168.0.1 on the server with a subnet mask of 255.255.255.0 and the peer at 192.168.0.2, and wouldn't you know, the problem still persisted, now with a plethera of other issues. What I found did work, however, is reverting back to the original IP, and adding a second IP to the network card (This done in advanced configuration). Apparently the firewall is now blocking everything on the second IP, of which we decided to use 192.168.3.1 subnet mask of 255.255.255.255 of which should allow for almost anything to connect in now. Strange resolution, but it did "Fix" the issue. I still think it is related to the O/S in some strange way.

Thanks,

Dan.

[Pascal]

Either that or a very sick network.

[organekd]

I was able to determine that this is apparently a common issue due to how NT4.0 deals with the Browser Service specifically. If more than 1 server is on the network, the next server will take over this function. Somehow, (Might want to play with this a bit) the VPN software apparently communicates with the software in such a way as to "hide" the server from those locally attached, reguardless of IP. On a "Clean" install of the server, using suggested IP's, on a 3c905B-TX card, we were able to duplicate the issue. This only happens to those locally connected to the VPN server. Let's call the server "Server1" for example. Loaded with NT4 SP6, with workstations running 98SE, XP, etc., was able to determine n this instance where only 1 server was running, that the server disappears from the list of computers visable from the local network. By typing in the UNC \\server1 at start/run, the shares are viewable. If a second server is running, Let's call this "Server2", then both servers will remain listed. I am not sure how the browsing service becomes effected, however, to correct Server1's issue, I found that stopping the Wingate VPN engine alone isn't enough (unless you want to wait about 50 minutes), but stopping/starting the Browser service does seem to correct this. Starting the VPN service again, the server will remain in the browsable list for some time, only again to disappear again. I don't know if this is particular to NT4 in the way it is handled, however, I am now attempting to test this with WINS turned off. This doesn't seen to effect how the VPN handles the pipeline, and the VPN does seem to see all units via the Browser service. Might this be caused by a conflict with another component in the NT server configuration, i.e. Services for Macintosh, or perhaps, Idunno, the fact that the server by default makes Lan Manager 2.0 broadcasts? In either case, I am tempted to install a backup protocol (Such as Netbeui or other) to keep the server list consistant. Idunno.. Any suggestions?

Thanks,

Dan.

[organekd]

Discovered last combo (Disable wins) did not work.. Again, disappeared. Based on MS Techtips database on Browser service, though the system only has 1 adapter, disabling browser service, and re-enabling wins. Both have been performed without shutting down VPN engine. Server now available. Will see how this goes..

-Dan.

[Pascal]

Can you email me a copy of the route tables published across the VPN when you have them connected?

The easiest way to get that would be to take a screenshot of the GateKeeper networking pane with all nodes expanded.

It is possible that when you establish a connection the data is being tunneled across the VPN. (Depending on which routes are published, etc.)

[organekd]

All this happens prior to the VPN connection ever being established. From what Microsoft states, the browser service must be disabled on systems running more than 2 adapters. Disabled the browser service, and the network appears to run fine. I suspect that the VPN software perhaps acts like a virtual network adapter. The unit connecting via VPN happens to "See" everything (minus a print server). Thought you may want to know that it isn't an issue with the VPN software directly. Please let me know though, if you still want that screen shot. I should be on site again during the course of the week.

Thanks,

Dan.

[Pascal]

Can you post a link to the article on Microsoft's site, please?

[organekd]

Here is one of the links. This should "Summarize" the browser issue (Network Browser, not Web) and explain how it works, and some of the issues.. This was my "First" article in reading on this. If you were to go to "Support.microsoft.com" and select NT Server 4.0 as a Server Operating System, querry Browser, you should see quite a bit of what I read about the browser service. Again, here is the link that summarizes everything... Hope this helps...

http://support.microsoft.com/default.as ... -us;191611

Thanks,

Dan.