Routed LAN setup - connections from OpenVPN client to server

ste123

Hi,

I have a working routed OpenVPN setup as depicted by the following network diagram.

OpenVPN Server LAN: 192.168.1.0/24
OpenVPN Client LAN: 192.168.2.0/24

Below are my server and client configurations:

SERVER

local 192.168.1.10
dev tun
proto udp
port 11994

ca /etc/openvpn/ca-server01-ca.crt
cert /etc/openvpn/server01.crt
key /etc/openvpn/server01.key

dh /etc/openvpn/dh2048.pem

server 172.29.29.0 255.255.255.0

ifconfig-pool-persist /etc/openvpn/ipp.txt

route 192.168.2.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

client-config-dir /etc/openvpn/ccd

tls-auth /etc/openvpn/ta.key 0

keepalive 15 120

cipher AES-256-CBC
auth SHA512
tls-cipher DHE-RSA-AES256-SHA

comp-lzo

max-clients 10

persist-key
persist-tun

log-append /var/log/openvpn.log
verb 3

management 127.0.0.1 11995

client-to-client

SERVER CCD (client01)

iroute 192.168.2.0 255.255.255.0

CLIENT

client

dev tun
proto udp
remote x.x.x.x 11994
nobind

persist-key
persist-tun

ca /etc/openvpn/ca-server01-ca.crt
cert /etc/openvpn/client01.crt
key /etc/openvpn/client01.key

dh /etc/openvpn/dh2048.pem

ns-cert-type server

tls-auth /etc/openvpn/ta.key 1

tls-remote server01

cipher AES-256-CBC
auth SHA512
tls-cipher DHE-RSA-AES256-SHA

comp-lzo

log-append /var/log/openvpn.log
verb 3

management 127.0.0.1 11995

The only "issue" I have is when new connectinos destined for the Server LAN originate directly from the OpenVPN Client. Instead of those connections originating from
its IP address (192.168.2.254), they originate from its TUN adapter's IP address (172.29.29.6). Because the OpenVPN Client server is also acting as a DNS server for
the LAN, this caused some grief when DNS broke when forwarding requests to the 192.168.1.0/24 network.

root@client01:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.252   0.0.0.0         UG    100    0        0 eth1
172.29.29.0     172.29.29.5     255.255.255.0   UG    0      0        0 tun0
172.29.29.5     *               255.255.255.255 UH    0      0        0 tun0
192.168.1.0     172.29.29.5     255.255.255.0   UG    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

root@client01:~# ip route get 192.168.1.2
192.168.1.2 via 172.29.29.5 dev tun0  src 172.29.29.6
    cache

I have implemented a workaround by adding static routes to both gw01 and gw02 for 172.29.29.0/24 to be routed via the respective OpenVPN instance, however I would
rather not use routes to accomplish it. I would prefer the non-TUN IP address be used for all requests.

I have manually done this by manually deleting the route (that gets pushed after connect), and replacing it with one that specifies the source address to use.

root@client01:~# ip route del 192.168.1.0/24 dev tun0 ; ip route add 192.168.1.0/24 via 172.29.29.5 dev tun0 src 192.168.2.254

root@client01:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.2.252   0.0.0.0         UG    100    0        0 eth1
172.29.29.0     172.29.29.5     255.255.255.0   UG    0      0        0 tun0
172.29.29.5     *               255.255.255.255 UH    0      0        0 tun0
192.168.1.0     172.29.29.5     255.255.255.0   UG    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

root@client01:~# ip route get 192.168.1.2
192.168.1.2 via 172.29.29.5 dev tun0  src 192.168.2.254
    cache

Now, the routing table is identical, just the IP address used for outbound connections destined for 192.168.1.0/24 is NOT the TUN interface IP address.

This appears to work as I expect, even after deleting the recently added routes for 172.29.29.0/24.

That brings me to my question: Is there a way to achieve this directly via OpenVPN's --route (or similar) command? Or will it have to be done manually via running a
custom command via --up or --route-up? I don't care if it can be pushed or it needs to be set in the local config file.

Thanks.

Traffic

As both your VPN server & client are ubuntu, you could use iptables NAT to hide the tunnel IPs completely.

ste123

Thanks for the reply. Do you have an example on how to achieve this?

To me using NAT sounds like overkill when no additional routes are required, but I'm happy with whatever works 100% with minimal fuss. In the meantime I've created a script to add the routes with the desired source IP address set. The below is currently set up on the OpenVPN Client.

/etc/openvpn/client01-route-up.sh

#!/bin/bash

# https://forums.gentoo.org/viewtopic-p-6771484.html#6771484
mask2cdr ()
{
   # Assumes there's no "255." after a non-255 byte in the mask
   local x=${1##*255.}
   set -- 0^^^128^192^224^240^248^252^254^ $(( (${#1} - ${#x})*2 )) ${x%%.*}
   x=${1%%$3*}
   echo $(( $2 + (${#x}/4) ))
}

SRCIP=192.168.2.254
IPCMD=/sbin/ip

for i in {1..50}; do
        eval "LOOPNETWORK=\${route_network_$i}"
        eval "LOOPNETMASK=\${route_netmask_$i}"
        eval "LOOPGATEWAY=\${route_gateway_$i}"
        eval "LOOPMETRIC=\${route_metric_$i}"
        if [ -z "${LOOPNETWORK}" -o -z "${LOOPNETMASK}" -o -z "${LOOPGATEWAY}" ]; then
                continue
        fi
        if [ -z "${LOOPMETRIC}" ]; then
                LOOPMETRIC=0
        fi
        LOOPNETMASKCDR=`mask2cdr ${LOOPNETMASK}`
        echo "[${i}] ${IPCMD} route add ${LOOPNETWORK}/${LOOPNETMASKCDR} via ${LOOPGATEWAY} dev ${dev} src ${SRCIP} metric ${LOOPMETRIC}"
        ${IPCMD} route add ${LOOPNETWORK}/${LOOPNETMASKCDR} via ${LOOPGATEWAY} dev ${dev} src ${SRCIP} metric ${LOOPMETRIC}
done

Set required variables:

SRCIP = IP address of local LAN interface
IPCMD = location of ip command (determine by executing which ip on the same machine).

Remember to mark the script as executable.
The echo command can be deleted if you don't want its output in the OpenVPN log.

Append to OpenVPN conf:

route-noexec
route-up /etc/openvpn/client01-route-up.sh

On teardown of the tun device, it removes the routes so no down script should be required.
(As I'm on OpenVPN 2.2.1, I don't have a route-pre-down option, otherwise I would've used it)

The resulting log looks like this:

...
Mon Nov  9 07:21:40 2015 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 172.29.29.0 255.255.255.0,topology net30,ping 15,ping-restart 120,ifconfig 172.29.29.6 172.29.29.5'
Mon Nov  9 07:21:40 2015 OPTIONS IMPORT: timers and/or timeouts modified
Mon Nov  9 07:21:40 2015 OPTIONS IMPORT: --ifconfig/up options modified
Mon Nov  9 07:21:40 2015 OPTIONS IMPORT: route options modified
Mon Nov  9 07:21:40 2015 ROUTE default_gateway=192.168.2.252
Mon Nov  9 07:21:40 2015 TUN/TAP device tun0 opened
Mon Nov  9 07:21:40 2015 TUN/TAP TX queue length set to 100
Mon Nov  9 07:21:40 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Mon Nov  9 07:21:40 2015 /sbin/ifconfig tun0 172.29.29.6 pointopoint 172.29.29.5 mtu 1500
[1] /sbin/ip route add 192.168.1.0/24 via 172.29.29.5 dev tun0 src 192.168.2.254 metric 0
[2] /sbin/ip route add 172.29.29.0/24 via 172.29.29.5 dev tun0 src 192.168.2.254 metric 0
Mon Nov  9 07:21:40 2015 Initialization Sequence Completed

The route is as expected:

root@client01:~# ip route get 192.168.1.2
192.168.1.2 via 172.29.29.5 dev tun0  src 192.168.2.254
    cache

Traffic

ste123 wrote Do you have an example

yes

iptables -t nat POSTROUTING -s {source} -o {preferred-source} -j MASQUERADE

ste123

Thanks for the example. I'll have a play with it within the next 48 hours, as I need to wait for a quiet period to test.

ste123

I can confirm that NAT works as expected.

On server01 (single LAN interface, eth0):

iptables -t nat -I POSTROUTING -s 172.29.29.0/24 -o eth0 -j MASQUERADE

On client01 (single LAN interface, eth1):

iptables -t nat -I POSTROUTING -s 172.29.29.0/24 -o eth1 -j MASQUERADE

Although it works, because it is using NAT we cannot see the true source IP address on the remote LAN, which makes it impossible to selectively filter in/out or report against.

As there is no immediate need for filtering or reporting from the remote LAN, I will trial the NAT setup for a few days and confirm it doesn't introduce unexpected issues. But for the reasons above I will probably switch to the routed setup which was also working but presents the true source IP address.

Thanks.

Traffic

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

ste123

Traffic wroteNAT was just a suggestion .. you don't need it.

I know I don't need it. I'm just trying to find the best fit for what we need, and I'm grateful for the suggestions. As I stated it does work, but going forward its practicality in my environment comes in to question. However it does highlight there's many ways to skin a cat...

Traffic wroteHere is something else you could try:
http://backreference.org/2010/06/18/openvpns-built-in-packet-filter/

but you don't need that either :mrgreen:

I agree, I don't think I need that either... :lol:

Thanks again.