Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Routing question

Status
Not open for further replies.

sos

IS-IT--Management
Apr 10, 2000
53
CA
I have set up a vpn using Openvpn on a windows2000 pro machine. We have linux box running Shorewall firewall. The vpn part works great I can connect clients fine.

The vpn is setup on 10.8.0.x and the lan is 192.168.1.x

My problem is that I need clients to be able to ping(access) the rest of my 192.168.1.x network. Right now I can ping and access shares on the openvpn server but thats it. Anything behind it is inaccessible.

So... I need a route on the LAN gateway(linux) to route the VPN client subnet (10.8.0.0/24) to the server at 192.168.1.178. How do I accomplish this?
I think I need to use the "route add" command and I have fiddled around trying different things but nothing has worked.

btw I do have the "IPEnableRouter" set to 1 in the registry on the 2000 machine.

Thanks
 
Can you confirm what device is the default gateway for the LAN clients on 192.168.1.x?

 
The default gateway is 192.168.1.1
 
Oh sorry I mean what device is your default gateway? Is it a router, is it the Linux gateway?
 
sorry on eth1...the def gateway is 192.168.1.1 on eth1
 
Yes it is. My linux box running shorewall is the default gateway
 
If that's the case the Linux box shouldn't need a route to get to 192.168.1.0 as it itself already resides on the network.

Presumably from the Linux box you can ping hosts on both the 10.8.0.x and 192.168.1.x networks?
 
I cannot ping 10.8.0.x from the linux box(router/firewall) which serves ip's in the 192.168.1.x range. The firewall resides on another computer than the Openvpn server which hands out the 10.8.0.x ip's to vpn clients.

Here is a diagram:
_______________
linux firewall | port 1194 forwarded to vpn
_______________|-------------------|
| | |
eth0 eth1 |
| \ |
| \ |
68.x.x.x \ |
(internet) \ 10.8.0.1
\ _____|_________
192.168.1.1 |Openvpn server|
\ ---------------
\ |
\-----------192.168.1.178


I hope this makes sense! :)
 
Yes I think I get it now.

I guess as you've already said you need a route added to the Linux gateway for 10.8.0.x.

Something like: route add -net 10.8.0.0 netmask 255.255.255.0 dev eth1

(I think eth1 is the 192.168.1.0 network - not sure from the digram)
 
Thanx for your help KiscoKid and sorry about the diagram it got messed up when I submitted my post.

Yes you are right eth1 is the 192.168.1.0 network. After doing

route add -net 10.8.0.0 netmask 255.255.255.0 dev eth1

My routing table on the linux box looks like:
Kernel IP routing table
Destination Gateway Genmask Iface
10.8.0.0 * 255.255.255.0 eth1
192.168.1.0 * 255.255.255.0 eth1
68.x.x.x * 255.255.252.0 eth0
default 68.x.x.1 0.0.0.0 eth0

If I ping 10.8.0.1(ip of Openvpn server) I get no reply. Also according to Ethereal the packets are not arriving at the 10.8.0.1 interface.

If I ping something on the 192.168.1.x from a vpn client the pings get to the vpn server's 192.168.1.178 interface but thats as far as they go.
 
Actually I'm having a braincramp, instead can you try:

route add -net 10.8.0.0 netmask 255.255.255.0 gw 192.168.1.178.

 
ok after doing that when i ping 10.8.0.1 from the linux box
I get no reply but if i monitor the 192.168.1.178 adapter on the openvpn server i see that the ping requests are at least getting there.
 
Excellent some progress made!

Now presumably 192.168.1.178 can ping anything on 10.8.0.0. If so, good. What I suspect may be happening now is that the client machine on at 10.8.0.1 doesn't know how to get back to 192.168.1.0.

I think one of two approaches may work here.

(1) If the 10.8.0.1 has a default gateway of the openvpn server (its 10.8.x.x address). This may not be feasible however as this could disrupt its non-vpn traffic.

(2) Add a route to each 10.8.0.0 client telling it how to get to 192.168.1.0. For Windows PC, something like:

route add 192.168.1.0 mask 255.255.255.0 10.8.0.x

where 10.8.0.x is the 10.8.0.x address of the openvpn server.


 
After trying route add 192.168.1.0 mask 255.255.255.0 10.8.0.x
I get an error:

The route addition failed: Either the interface index is wrong or the gateway does not lie on the same interface as the network.

So I looked at the route table for the client and found this:

Destination Netmask Gateway Interface
192.168.1.0 255.255.255.0 10.8.0.5 10.8.0.6

The client ip is 10.8.0.6

This route is being "pushed" to the client by the openvpn server via the servers config file. I commented that part out of the config file so that that route wasn't sent to the client and tried manually setting the route
per your suggestion. Same error.

The weird thing is that 10.8.0.5 doesn't exist on any interfaces that I have. The openvpn servers ip is 10.8.0.1. I think it has something to do with Openvpn's implemenation.

route add 192.168.1.0 mask 255.255.255.0 10.8.0.1 gives
the error.

route add 192.168.1.0 mask 255.255.255.0 10.8.0.5 works.
 
Ah it would be better to automatically push the routes for 192.168.1.0 to the VPN client. However if you are not sure what the 10.8.0.5 address is, I would ascertain this is the reason why end to end routing is breaking down.

I think the best approach, as previously mentioned, is to push the route. However I suspect there must be something awry in the VPN configuration as the clients are picking up the incorrect gateway address.

An incorrect gateway address will still allow the clients to talk to any device on the same subnet however it will mean no communications will be possible with devices on different subnets - which is exactly the issue you have.

There is another option but it's a much bigger administration overhead. That is to stop pushing the route to clients, verify that none of the VPN clients are picking up a route for 192.168.1.0 (if they are delete it) and add a route for 192.168.1.0 on each client with the right default gateway.

I'm fairly confident that once you get the right gateway on the clients, it will all work!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top