Can't see net share thru VPN tunnel

[drjohn999]

I'm able to establish the VPN via dialup (wireless disabled) from the client PC (Win XP Pro SP2 laptop) to the host pc (Win 2K SP4 local machine only configuration). The host and client computers' VPN information both show up in both the host and the client's GateKeeper.

I can ping the host LAN's IP addresses (192.168.0.1 and 192.168.1.1 -- there are two local subnets; one wired one wireless). However the host PC is unable to ping the ISP-assigned IP address of the laptop's dialup connection (i.e. 66.238.96.201 for example).

The Gatekeeper VPN panel lists the host computer's name in the host computer's Microsoft Windows Network tree, but the host computer's name does not appear in the client's tree. This is true of both Gatekeeper instances (Host and client).

I have exposed a shared folder on the C: drive of the host but I cannot see it (nor can I see the host itself in NetHood) thru the VPN tunnel. If I disconnect the dialup to the VPN on the laptop and enable a wireless or wired connection from the laptop to the host then I can connect to the shared folder (and other shared resources such as printers on the host as well).

The client is running Norton Internet Security 2005, but disabling NIS makes no difference, nor does explicitly allowing incoming/outgoing UDP and TCP traffic on port 809. Disabling / enabling Wingate's firewall on the client makes no difference either. The host and client firewalls are set for the port 809 holes as automatically configured during installation.

When connected via the wireless connection the Gatekeeper VPN panel on the host reports a routing conflict for the laptop's granted local IP of 192.168.1.4 (for example), and the VPN panel on the client has a similar routing conflict for the hosts' IP address. When connected via the dialup there are no reported routing conflicts.

So, do you have any ideas on how to get the client PC to see the shared folder when connected via dialup alone (or other external internet connection) ?

Thanks,

DrJohn

[Pascal]

That type of setup should be relatively easy - it's reasonably common. From the sound of it port 809 UDP is being lost somewhere along the way. So.

1. How does the host connect to the internet?
2. Can you ping the server's internal IP (192.168.0.1) when the laptop is connected via VPN?

[drjohn999]

1. How does the host connect to the internet?
2. Can you ping the server's internal IP (192.168.0.1) when the laptop is connected via VPN?

1. The host is connected thru a 10/100 wired ethernet card to a cable modem (Comcast). It's IP address may not be entirely fixed, but it has been stable for a few days anyway. The host has 2 fixed-address ethernet cards for the internal LAN. One of the cards is a RealTek, and the RealTek flag is set in Advanced Options. If not then the ISP's internet gateway and external DNS servers cannot be reached.

2. Yes, I can ping both of the internal IP addresses (192.168.0.1 and 192.168.1.1) from the client while connected via dialup to VPN, without the wireless connection to the internal LAN.

-- DJ

[Pascal]

Okay, the fact that you can ping from the client to the server is a very good sign. That means the tunnel is up and active and network traffic can reach both the server and the client. (As responses would have to come back too).

That means it is likely to be one of two things:

1. Networking is not enabled on the client - File and Printer sharing, etc. That might only be active for the wireless adapter. WinGate + NIS will protect you against unwanted traffic from the outside world while you check if that is the case. I'd first try to reach the machine by name from the WinGate server (E.g. \\laptop or whatever it is called)

2. MTU. This is a frequent problem on the forum. Because each VPN packet has a minor overhead you sometimes have to adjust the MTU to ensure that the packets will successfully reach the remote machine. Testing and doing this is described in the setup guide.

[drjohn999]

I've enabled the sharing and m/s net features on the client and also on the host external adapter (which were disabled by my habit when settining up externally connected machines. Not to worry, the firewall did a good job blocking when I ran a test). Anyway, I also uninstalled NIS on the client, and then un and re-installed wingte VPN just to be sure, but no luck.

By way of weirdness, I have to mention this: I happen to have also a corporate VPN connection on the laptop, as a Windows WAN L2TP Miniport. Wingate sees this as another network connection. If I activate this VPN while dialed up and with the Wingate VPN enabled, I can see the VPn information panel refresh on both client and host and the routes change to reflect the new information, and then I can access the shared folder on the host PC! To me, this says that there are no problems with sharing / networking in general between the host and the client but that its a connection / packet / routing problem instead. I can't actually use this dual - VPN configuration because this laptop is just a test case and there are three additional potential client users out there none of whom can access this extra VPN.

The rest of this was done without the extra VPN.

With the Wingate VPN disconnected, pinging the VPN client machine's name gives "Unknown Host..." and pinging its IP address (i.e. 66.238.96.xxx) times out. With the VPN connected, I can ping the same IP address, so the VPN knows its there (would have to in order to make the connection...)

As far as the MTU goes, I loose packets pinging at -l 1422. I tried going up from 32 to 64, 128 etc, and it looses packets consistently at 512 (this is with the MTU on the adapter set to the default 1500). I changed the MTU downward with the adapter's Properties, Advanced dialog under Wingate and found little difference between settings all the way down to 400. I found that it was necessary to stop / start the Wingate engine to see the MTU changes in Wingates' Adapter Details dialog. Is there something else I should do (like reboot)? I note some registry tweaking in other MTU-related threads in this forum... Please advise.

Thanks,

DJ

[Pascal]

Host shouldn't have been required, for the client that would have been useful. The easiest way to adjust MTU is to actually use an application called DrTCP.

You can find that here. It's an offsite link, it's not a Qbik product.

[Pascal]

Also had a quick chat to Genie. Is it possible for you to send (via email) a screen capture of the published routes on either end of the VPN. (Or simply write them down, whichever is easiest).

You can see the published routes on the VPN view in GateKeeper when you have the nodes fully expanded.

[drjohn999]

I ran the laptop on an external WiFi connection today while enjoying a good cup of coffee. Due to a conflict between the WiFi and my own NAT local addresses, I had previously changed mine to 192.168.10.xxx and 192.168.11.xxx from 192.168.0.xxx and 192.168.1.xxx, and all of the related address instances inside my Wingate LAN. The VPN connection hooked up very quickly, but the host PC was still unreachable; I got no response to pinging it at 192.168.10.1. The connection was a little different than going out by phone modem; the WiFi connection passed thru its own NAT on the way. Norton Internet Security is reinstalled (since taking it out made no difference), and I have explicity granted permission for the 192.168.10 and 11 addresses as well as for the external internet IP address of the host PC, plus punched holes thru for TCP/UDP in/out on 809. I also checked that the Wingate firewall is open on those ports too.

The client PC reported the following in the VPN:
----------------------------------------------------
Local Network of Dell-450 (Master):
Microsoft Windows Network
Chromsource
Dell-450 (Not accessible)
Published Routes
167.169.198.144 / 255.255.255.255
192.168.10.1 / 255.255.255.255
192.168.11.1 / 255.255.255.255
Local Network of BahLat610 (local)
Microsoft Windows Network
(nothing else in this node)
Published Routes
Behind NAT/Translated
192.168.0.103 / 255.255.255.255
Tunnels
Tunnel (5) to Local network of Dell-450 -- Active
---------------------------------------------------------------
167.169.198.144 is the external IP address of the host PC.
192.168.10.1 and 192.168.11.1 are the fixed internal IP address of the two internal network adapters on the host PC.
The 192.168.0.103 address is the NAT address of the laptop on the WiFi network. I wasn't at the Host PC to see what it was doing, but its Wingate history shows that it was talking to "199.107.166.62:809 with ID 5 Active and Upated" at that time, which would be the external IP of the WiFi net.

So, what does this look like to you??

Thanks,

DJ

[Pascal]

Was this at your normal home network or at a cyber-cafe or similar? If the latter, it is possible that they were nor forwarding port 809 UDP back to you.

[genie]

Hi,

We've discovered lately one case where a VPN server would not create data channel properly - if you'd like to try the updated driver, I can send it to you (VPN server side update is the most important place) if you tell me what operating system you are running on the server.

[drjohn999]

Yes, that certainly could be the case. But that raises an immediate problem with Wingate VPN while roaming around from one location to another. In this case, there are 3 potential users. One is at a fixed location on broadband but the other two are roaming laptops that connect at Kinko's, coffeshops, or wherever they can.

If it's likely that port 809 will be blocked at such locations then there's no point in continuing with this evaluation.

-- DJ

[genie]

For the client side it is not important whether this port is forwarded or not - the client simply initiates data channel which is ust a UDP traffic which is normally handled fine by any internet cafe - the server side, though, needs to have a hole punched in the upstream firewall to allow data traffic through.

[Pascal]

Most of the time such traffic will not be blocked. However, some overzealous admins might have a clampdown on outgoing traffic. In that case there is not much the software can do.

However, as Genie pointed out - there has been a recently introduced problem for which he has a driver fix. This does not affect all routers, but it is possible that the one you have at the server point might not be affected. If you let him know what OS you have he can send you a new driver for there.

[drjohn999]

The host PC is running Winows2K, SP4 plus all the bizillion security updates. Wingate is 6.0.4.1025. The VPN is 2.0.4.1025. One of the NICs on the host is a RealTek; the one at 192.168.0.1. The external NIC is an Allied Telesyn. No Norton security on this one.

BTW, you did say that the host's external NIC does not need Client for MS Networks enabled, right?

You can email the driver update to me: info@chromsource.com (attachment limit is ~5megs). Otherwise I can pick it up by ftp, if you like.

Thanks,

DJ

[Pascal]

So long as it's enabled on one of the NICs in the machine it's fine. That is only an issue for machines without an external NIC. That Realtek card, it's not based on the 8029 chipset, is it?

[genie]

Ok, the driver is on the way.

[drjohn999]

The Realtek NIC definitely is based on the 8029 chipset. I had quite a time figuring that one out a while back, but so far its worked fine with the Advanced setting enabled for it.

I'll install the drivers (thanks genie!) and get back to you.

--DJ

[drjohn999]

I tried the driver update on the host (Win2K) followed by the client (WinXP SP2), but there was no change. This time I used the dialup for the client, so I can see both computers at the same time.

Again I get an immediate connection on both ends, but no shared resources are visible on either end. At the Client, when I attempt to connect to a shared drive I see the error message, "The drive could not be mapped because no network was found." This is the same message I saw when connected via the external WiFi / NAT provider earlier.

The main difference at a lower level is that I now can ping 192.168.10.1 from the client, whereas from the external WiFi / NAT connection I could not ping it.

Here's route print from the client:

C:\Documents and Settings\Beth>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 12 f0 01 31 2e ...... Intel(R) PRO/Wireless 2200BG Network Connection
- Packet Scheduler Miniport
0x30004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 66.238.97.59 66.238.97.59 1
66.238.97.59 255.255.255.255 127.0.0.1 127.0.0.1 50
66.238.145.162 255.255.255.255 66.238.97.59 66.238.97.59 1
66.255.255.255 255.255.255.255 66.238.97.59 66.238.97.59 50
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 66.238.97.59 66.238.97.59 1
255.255.255.255 255.255.255.255 66.238.97.59 66.238.97.59 1
255.255.255.255 255.255.255.255 66.238.97.59 2 1
Default Gateway: 66.238.97.59
===========================================================================
Persistent Routes:
None
(Sorry about the spacing, but there's no time to fix it up in HTML)

At the time this was captured the wireless radio was turned off. Its interesting that the Wireless adapter is listed but the dialup modem is not. Its IP address is listed however. Is that normal?

So, any additional things to try?

--DJ

[genie]

Ok, it is better now, right? Now you can ping - which means that the data chanel now works properly. The dialup adapter is listed, too - WAN (PPP/SLIP) Interface is the one.

Now, this error message - di you have active directory running?

[genie]

One thought, though - it looks like the NetBT is not configured on your machine - not bound to the dialup adapter - this is the reason it gives you this error.

[drjohn999]

Thank you immensely for all your help. I'm now able to use either laptop on dialup or WiFi to access the shared resources. The NetBios/TCP setting was the key: it was disabled and well hidden (3 sub-dialogs away) in each non-working case.

I'm not sure if the updated drivers did anything -- they're installed on each system and have had no negative impact anyway. I'm not inclined to experiment to find out, either.

I have a couple of additional questions that I"ll post in new threads.

-- DJ