0

I've setup a OpenVPN server using tun and udp and enabled the options for redirecting all internet traffic and pushing lan to clients.

In the HOST NETWORK The OpenVPN Server is configured to dish out 10.8.0.x network addresses for OpenVPN clients where as the LAN clients are in the 192.168.x network.

It looks something like this.

-----------------------------------------
|            HOST NETWORK               |
|     LAN Clients    +  OpenVPN Server  |
|     192.168.1.x          10.8.0.x     |
-----------------------------------------
                     |
            -------------------
            |     INTERNET     |
            -------------------
                     |
 ----------------------------------------
 |           REMOTE NETWORK             |
 |          OpenVPN Clients             |
 |      Local Network 192.168.1.x       |
 ----------------------------------------

The problem is when the REMOTE NETWORK OpenVPN client are connecting from a remote network but they themselves have a local address range of 192.168.1.x

In this scenario not all packets are sent over the tunnel. e.g. If the REMOTE NETWORK has a machine at 192.168.1.1 and after establishing the OpenVPN tunnel the remote OpenVPN client tries to access 192.168.1.1 it goes to the REMOTE NETWORK's machine rather than the HOST NETWORK's machine.

How do I tell/configure the remote OpenVPN client to send ALL traffic over the tunnel ignoring whatever the local network routes/addresses are?

I've searched all over and tried the remote-gateway def1/autolocal options but nothing seems to work, it's always sending the 192.168.1.1 packets to the REMOTE NETWORK machine instead of the HOST NETWORK machine.

This is my client config:

client
dev tun
proto udp
remote hostnetwork.com 1194
float
ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
cipher AES-128-CBC
comp-lzo adaptive
keepalive 15 60
auth-user-pass
remote-cert-tls server
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
resolv-retry infinite
nobind
redirect-gateway autolocal
rboy
  • 101
  • 1
  • 3
    You learned an important lesson on the reason to never use common private `/24s` that consumer equipment uses on the remote side – Mike Sep 12 '17 at 22:32
  • 1
    see the following https://serverfault.com/questions/548888/connecting-to-a-remote-server-through-a-vpn-when-the-local-network-subnet-addres – Mike Sep 12 '17 at 22:33
  • 3
    This is simply not a problem with **openvpn**. It must be solved by re-numbering, or as the linked question mentions, some really ugly NAT hacks. – Zoredache Sep 12 '17 at 22:58
  • Not possible. It's a routing issue, not an OpenVPN issue. – Appleoddity Sep 12 '17 at 23:22

0 Answers0