Cannot access host and remote network shares

[Wabiloo]

Hi!

I've been searching for the solution to this problem, and there seems to be quite a few people with it, but I couldn't find the solution in the previous posts, so here is mine:

My laptop (the client) is connected to a network (receives address 128.232.x.x via DHCP), and uses a VPN connection to connect to a second network (with ppp server which gives me access to the internet, with public address 128.232.y.y). I installed WinGate 6.0.3 (trial) on this laptop.
At home, I have a network behind a D-Link router/NAT/firewall. It is configured to send most WAN calls to one machine (called Euterpe) on this network. On this machine, WinGate VPN is running. Another machine (called Calliope) is also on this network. The router public IP is 131.111.z.z and the local network addresses are in the range 192.168.0.x.

Now, what I'm trying to do is to connect the laptop to Euterpe (via the existing VPN and through a WinGate one) and access the local network (= Euterpe + Calliope shares).

The VPN connection works, and the "Remote Networks (VPN)" window in Gatekeeper shows "Connected: SSL control channel negotiaced", and below it, the "Local Network (Euterpe)". Inside it, "Microsoft Windows Network" contains the two computers Euterpe and Calliope as "not accessible" (it does so after spending a few seconds showing "Testing..."). The "Published Routes" contain three entries: "Behind NAT/Translated", "255.255.255.0/192.168.0.0" and "255.255.255.255/192.168.0.10".

No matter how I fiddle with all this, I cannot access the two computers (not even Euterpe, though it is the WinGate VPN server).

I could use some help... Cheers,

[adrien]

Hi

Those remote machines that you are trying to access need to know that to get back to your IP address, they go through their local VPN gateway (i.e. WinGate VPN).

If they don't have specific routes configured for your IP (either manually entered, or automatically created by RIP) then they would rely on their default gateway to send packets back. If their default gateway is not the local WinGate VPN gateway, then the return packets won't come back across the VPN.

So normally we recommend either of

1. enable RIP v2 listening on your main gateway.
2. install our RIP v2 client on the remote machines you wish to access
3. manually configure routes on your main gateway or individual machines to access the VPN through their local VPN gateway.

Adrien

[imasterxx]

in your 3rd option you recommend to...
"3. manually configure routes on your main gateway or individual machines to access the VPN through their local VPN gateway. "

what are the steps to manually configure routes? When I connect I can see the tunnels and the routes in Wingate but I cannot add or change them.

[adrien]

To change the route table on a machine, you need to log into the machine, go to the command prompt, and use the route command.

this is normally of the form

route add -p [NETWORK] MASK [mask] GATEWAY

e.g.

route add -p 192.168.1.0 MASK 255.255.255.0 192.168.0.1

would tell your system that the IP addresses 192.168.1.0 - 192.168.1.255 are available through gateway at 192.168.0.1

Adrien

[The Ricster]

When you say "enable RIP v2 on the gateway, do you mean that you should run the RIP applet on the VPN Server machine? and that will take care of the other machines on the LAN?

[adrien]

The WinGate VPN server already takes care of the routing on itself. What I meant was, that if you have another machine acting as the main gateway on that network, i.e. some sort of router/ADSL/NAT whatever, then most of these come with support for a RIP listener built in, but it is normally turned off by default.

Turning it on means it can learn the VPN routes, and then forward packets from your LAN machines through to the WinGate VPN server, rather than thinking there is no path for the packets, or trying to send them directly out onto the internet.