# Route Add Fail =/



## Eam404 (Feb 24, 2010)

Hi all!

So heres the gist - I have setup a OpenVPN server on a FreeBSD VM.  Everything works nicely, I can ping all machines from my client, can get to all my network resources.  The client is sitting on a remote network and is currently a windows machine.  My reason for this was just to test my client config to make sure it worked.  The gateway for the remote site is a FreeBSD router w/ pf.  I wanted all the other clients (at the remote site) to be able to route through the vpn; so I went to add the vpn subnet to the route table on the router.


```
route add 10.8.0.0 255.255.255.0 10.1.10.12
route: writing to routing socket: Network is unreachable
add net 10.8.0.0: gateway 255.255.255.0: Network is unreachable
```

I had to add the vpn subnet to my server side network via my AdTran core switch.  It took the route without issue.  So I simply went to do the same thing on the BSD gateway.  I suppose it makes sense that it wont add unreachable networks, but a static route is a pretty basic thing...

Am I missing something or is this strange to anyone else?


On a side note I do not want to install OpenVPN on the remote gateway because the end solution for my project will call for the openvpn client box to sit on another server and not the gateway.


----------



## SirDice (Feb 24, 2010)

10.1.10.12 needs to be accessible from that host in order to be usable as a gateway.



> I suppose it makes sense that it wont add unreachable networks, but a static route is a pretty basic thing...


It's not the network it's complaining about. It's not being able to reach the gateway pointing to that network that's the problem.

Most likely cause is that 10.1.10.12 is not on the same subnet as one of the interfaces of that host.


----------



## Eam404 (Feb 24, 2010)

Thank you for the response - that makes sense... so other then installing openvpn on the gateway it self; how can I allow my other clients to route through the client.

I think I confused my self


----------



## SirDice (Feb 24, 2010)

What does the current routing table look like on that box?

[cmd=]netstat -rn[/cmd]

Just follow the route. Make sure traffic ends up on the correct hop. Also make sure the return packets are also routed correctly. It usually isn't all that difficult.


----------



## Alt (Feb 24, 2010)

From man route

```
The other commands have the following syntax:

           route [-n] command [-net | -host] destination gateway [netmask]
```


----------



## Eam404 (Feb 24, 2010)

```
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            216.230.235.193    UGS         0      528    vr0
10.0.0.0/24        link#2             U           1      711    vr1
10.0.0.1           link#2             UHS         0       17    lo0
10.0.0.8           link#2             UHS         0        0    lo0
10.0.0.9           link#2             UHS         0       17    lo0
10.0.0.10          link#2             UHS         0        0    lo0
127.0.0.1          link#4             UH          0        0    lo0
216.230.235.192/26 link#1             U           0        0    vr0
216.230.235.212    link#1             UHS         0        0    lo0
```

VPN Client = 10.0.0.23
VPN Server (sitting in server VLAN at HQ) 10.1.10.12
VPN Client Pool 10.8.0.0/24


----------



## SirDice (Feb 24, 2010)

Ok. The routing table is clear. However, the vpn client pool is 10.8.0.0/24 so a vpn client cannot have 10.0.0.23 as it's IP address. It should be in the 10.8.0.0/24 range. A typo perhaps?

Which device takes care of the routing between the server VLAN and this box? There must be something in the 10.0.0.0/24 range that does the routing.


----------



## Eam404 (Feb 24, 2010)

Let me give you some more information.

On the server side, I have a core switch with 10ish VLAN's.   Im using a routed VPN (tun)- all the routing server side is handled by the core switch.  In the openvpn config, when doing a routed vpn you have to specify a range that the server will assign clients.  In this case I left the default of 10.8.0.0/24.  I then went ahead and added a route on my core 10.8.0.0  255.255.255.0  10.1.10.12.

The 10.0.0.23 address is the LOCAL address of the VPN client box.  When the client connects its assigned 10.8.0.6. I have tired a verity of adding routes for the 10.8.0.0 network to both the 10.0.0.23 ip and the "virtual gateway" of 10.8.0.5.  After that I'd try adding the 10.1.10.0/24 10.8.0.6 - since i added the previous route it let me add the second route.  That didnt seem to work.  Sorry if I'm jumping around - hope that helps.

The goal here is to form a site to site vpn - where openvpn DOES NOT reside on the gateways.



Edit: I should mention that both HQ network and the remote site run on the same network 10.0.0.0/24 - while this is not IDEAL it does work and since the client will only be accessing the 10.1.10.0/24 and 10.1.12.0/24 networks I dont think this will be a problem.


----------



## Eam404 (Feb 24, 2010)

I just dawned on me... I'm using Windows as a test client yet WINDOWS DOESN'T ROUTE!  I switched the client to a BSD vm and i am able to connect. I added the route 10.1.10.0/24 10.0.0.23 to the bsd router as this should be the only thing i have to do - still cant ping machines from the router or other clients then the vpn box.  So i am close...


----------



## Eam404 (Feb 26, 2010)

Well after hours of battle it turns out I won - slightly bloody but I ended up wining!

I had everything right expect one stupid mistake.  On the server side I added the correct routes for the home network, I assumed the OpenVPN server's route table would get updated by my core switch.  As it turns out it didnt - so this whole time the Openvpn server box was missing the route back to the remote network.  Both ends can ping all machines on each network. 

If anyone has questions about doing a site to site w/ openvpn where openvpn is NOT ON THE GATEWAY devices - please feel free to ask.


----------

