# OpenVPN; Route LAN from behind client

## eldiablo

Hi!

I have an OpenVPN server at point A. 

At point B i have an client which also resides on a LAN 192.168.1.0/24.

I want client C to access the 192.168.1.0/24 net.

I have tried some basic route and push commands from the server, but i really cant get it to work.

----------

## Hu

Where is C, relative to A and B?  Is B the gateway for its LAN subnet?  Please post the output of ip addr ; ip route ; iptables-save -c as run from both A and B.

----------

## Simba7

Sounds like something I was doing in another post. https://forums.gentoo.org/viewtopic-t-714510.html

Are you trying to:

OpenVPN Server is on Network A. The Clients are on Network B and Network C.

Network B and C and access all of Network A just fine, but Network A can't access all of B and C due to 10.10.20.x and 10.10.30.x not being there on the server.

Is this about right?

----------

## manaka

Have a look at --iroute option and client-specific contexts (--client-config-dir option).

----------

## rburcham

I'm afraid I need to get in on this. I believe I am trying to accomplish the same sort of config, and I am "almost there..."

Server - Machine at home.  Has 1 routable, external interface.  (Also has 1 non-routable internal interface (192.168.0.1) acting as a gw for a LAN (192.168.0.0/24) via iptables/NAT.)

Client1 - Laptop, often behind a firewall

Client2 - Desktop machine, fixed non-routable network, behind firewall, can access other non-routable subnets behind the firewall (e.g. 10.65.0.0/24).  Think "box on the 'work' network."

I have configured a VPN (10.8.0.0/24) such that Client1 and Client2 can both ping each other on their tun0 interfaces.  I would like Client1 to be able to access all of the ''work' subnets naturally accessible by Client2.

I have set up the Server with a client-config-dir "ccd" and have experimented with directives for the two clients:

```
ccd/client2:

iroute 10.65.0.0 255.255.0.0
```

This supposedly informs the Server that the 10.65.0.0/24 network is behind client2.  I can't confirm this is working.

```
ccd/client1:

push "route 10.65.0.0 255.255.0.0"
```

This pushes a route directive to client1 telling it to send 10.65.0.0/24 traffic to the VPN.  I can confirm this is "almost" working, however the Server drops the packets complaining that they are sourced from the eth0 interface on client1 instead of the tun0 interface on client 1:

```
Tue Dec 30 14:16:42 2008 client1/10.65.191.58:30865 MULTI: bad source address from client [192.168.5.27], packet dropped
```

Additionally I have tried to configure client1 to route "all" traffic over the VPN:

```
ccd/client1:

push "redirect-gateway def1"
```

This also seems to "almost" work... I can confirm that DNS requests and so forth are routing through the VPN and out the external interface on the Server for example.  However traffic sent from client1 directly to a host behind client2 is dropped.

Do I have to set up iptables/NAT on client2 to masquerade the traffic sourced from 10.8.0.0/24 inbound on the tun0 interface?  Or should ipv4_forwarding be enough?  Or does it take something more than just the iroute directive in ccd/client2 to instruct the Server to route 10.65.0.0/24 traffic to client2?

Has anyone managed to trick openvpn into doing this?

----------

## Hu

If machines on 10.65.0.0/24 do not have the correct route to the VPN IP address issued to client1, then they will be unable to properly return traffic to it.  Most likely, they are trying to route their responses via their default gateway, which does not understand how to return the traffic over the VPN.  The simplest solution would be to have client2 NAT such traffic, such that the recipients see the traffic as coming from client2 and address their responses to it.  When the traffic returns to client2, it will restore the proper address, and then route the traffic back over the VPN.  You will need IP forwarding enabled for this to work.

You could avoid NAT if you add the appropriate route on the other machines on 10.65.0.0/24.

----------

## rburcham

This was my suspicion as well, and I have been experimenting with iptables/NAT on client2 to facilitate what you describe.  Still no joy though, and my current theory is that the iptables config on the Server is interfering with the forwarding of 10.65.0.0/24 traffic sourced from client1 over to client2, even BEFORE client2 can have a chance to NAT and forward it.

My current ccd situation is this:

```
ccd/client2:

iroute 10.65.0.0 255.255.0.0

ccd/client1:

push "redirect-gateway def1"

```

Can you confirm that this setup should be sufficient for the openvpn piece of the puzzle?  If so then I can focus on distilling my iptables rules on the Server (I think I'll just disable/clear them out for the time being) and on client2.

----------

## Hu

I have not used OpenVPN in this way, so I cannot confirm or deny that your configuration is right.

You can use net-analyzer/tcpdump to monitor traffic on the virtual TAP interfaces to see if the data is making it to the VPN and, if so, whether it reaches client2.  The traffic is captured before iptables rules are applied, so if tcpdump shows traffic coming in to client2, and you see no evidence that it is leaving client2, then I would suspect iptables.  If you want, post the output of iptables-save -c from the VPN endpoints and we can check for any rules that might break things.

----------

## rburcham

I got it working.  The VPN server needed to be made aware of the proper routing for 10.65.0.0/24 (it had been trying to forward it via default route):

```
server.conf:

client-config-dir ccd

route 10.65.0.0 255.255.255.0
```

This coupled with the ccd configs for clients 1 and 2 described above got me going.  Just make client 2 NAT for trafic inbound on its tun0 interface and it works.

*EDIT* fixed netmask in the snippet above.Last edited by rburcham on Sun Jan 04, 2009 3:11 am; edited 1 time in total

----------

## Hu

Good to see that you got it working.

 *rburcham wrote:*   

> The VPN server needed to be made aware of the proper routing for 10.65.0.0/24 (it had been trying to forward it via default route):
> 
> ```
> server.conf:
> 
> ...

 

There is an inconsistency here.  In your message, you indicate that 10.65.0.0 is a 24-bit netmask, but in the configuration file, you set it to a 16-bit netmask.

----------

## rburcham

 *Hu wrote:*   

> Good to see that you got it working.
> 
>  *rburcham wrote:*   The VPN server needed to be made aware of the proper routing for 10.65.0.0/24 (it had been trying to forward it via default route):
> 
> ```
> ...

 

Sorry, happy fingers = typo.  I fixed it above.

----------

