Some small problems with routing and settings.

[pantrax]

I have some small problems understanding the nature of Wingate VPN and it's routing issues.

I had a great deal of problems getting a VPN link to work, due to the shere complexity of my network.

To make things easier to understand I'll supply some basic information.

VPN Server

local ip: 192.168.0.146
Subnet 255.255.255.0 (subnet 255.255.0.0 created a "local conflict" clientside?"
Local network selected in Wingate VPN

There is a network based on 192.168.1.x that are connected to 192.168.0.x by lan and are usually separated. There is however one server on this network that I want to connect to.

VPN Client 192.168.3.100
Subnet 255.255.255.0 (subnet 255.255.0.0 creates a "conflict" clientside
Local Machine Only selected in Wingate VPN

Therefore the only link i'we been cabable to set up and be able to ping is the one mentioned. The link is relying on that I use subnet 255.255.255.0 on both machines.

Now here is my question. How do I access the machines on the server side that are located on 192.168.1.x?

In regular networking one would be doomed at this point, seeing as the link won't let me use any other subnet than the one mentioned.

Other things that could come of importance to some, though I doubt it'll have anything to say. Both connections pass through a internet router (port forwarded on server side). Firewalls and so forth, but it shouldn't have to much to say since I can activate the link and ping "most" of the computers on the 192.168.0.x network.

What settings would give me access to the 192.168.1.x network? If I were to change the subnet on the server to 255.255.0.0 should I be able to connect to the 192.168.1.x network if it was working alright?

There might be a couple of things i missed in the rush of writing this post, if there is more information that you guys need let me know and i'll get back to it. If there are any tips. Please let me know.

Edit: Could it be possible that I might get a link to 192.168.1.x if I edit the route tables on the server side? How would this look?

[Pascal]

Just a quick thought while I'm working through this ...

Conflicts happen when the routing tables of the two ends of the connection cannot make a decision about which end a specific IP should be on.

By specifying 255.255.0.0 as the mask, you're effectively matching 192.168.*.*, which means that the VPN cannot decide if 192.168.1.3 is on the Server side or the Client side.

You can renumber one end of the connection (Client / Server side) to another of the private IP ranges (10.x.x.x, perhaps ?) which will get rid of the conflict, then you should be able to get the rest working in short order.

[pantrax]

Ah! Of course.

I need to start seeing from the easy perspective for starters.

There is however a minus to this setup. I don't want to use the 10.x.x.x network, because of several wireless routers that work on the 192.168.x.x network.

What I did as a workaround was that I added a new route table that went like 192.168.1.0 mask 255.255.255.0 192.168.0.138 (server that is always up and uses subnet 255.255.0.0 and is able to speak to the other subnet without problems). This was done on the machine that hosted the vpn and this actually worked.

Well it did work. I used this setup for two whole days and i figured it was time to move it from the test bench the another machine. Guess what, it didn't work. I never got the machines to talk again (the ones with subnet 255.255.255.0).

Now, I don't quite understand why, even the setup machine wouldn't work (i deleted the settings and tried them again). I must be missing something vital here. Any ideas?

The machine that I want to connect to is setup like this 192.168.1.101 subnet 255.255.0.0 gateway 192.168.0.138 (pingable). I'we also tried setting up a route table for this 192.168.0.0 255.255.255.0 192.168.0.138

It did work once, but it won't anymore. This beats me.

[adrien]

Hi

What other routers do you have on your internal network? Normally if you need to use a class B subnet to get to all your different subnets (such as 192.168.0.X, 192.168.1.X and 192.168.3.X) then there is a router/gateway somewhere joining these networks together.

If you had this working on a previous test setup, does this mean that your other routers on your network had learned that the local VPN machine was the gateway to the rest of the VPN? Are they running RIP listeners on these gateways?

Adrien

[pantrax]

We have one internal router which supervises all traffic. This one is setup to run on all subnet setups on 192.168.x.x

When I get into trouble setting up some new systems I usually read some information, not that thourough. Then I try to set it up again, the way I think It would work, meaning usually a workaround.

So what I did was setup a machine that already had connection to vpn server (pingable) work as a gateway for the 192.168.2.0 network. I then added the routes which were needed for this to work on the machines on 192.168.2.x using the machine previously mentioned as gateway.

This worked like a charm, but when I decided to move it from my testbench to the actual to be finished setup i ran into problems. It wouldn't work again.

So I figured I should move it back to my testbench again to see that everything was ok, but it wouldn't even work there. This puzzled me, since I did everything as I did the first time around.

I never used rip listeners instead i used static routes.