Home / server / Questions / 1010526
In Process
Sören Kuklau
Asked: 2020-04-03 00:49:30 +0800 CST

OpenVPN: can't seem to route additional traffic through VLAN

  • 772

Here's our network:

  • we have various clients working from home with dynamic IP addresses, so they're impossible to create firewall rules for
  • we have a number of servers at the same hosting provider
  • that hosting provider offers a VLAN feature so the servers can reach each other internally
  • we also have a different VPN that does accomplish this goal, but uses OpenVPN with a proprietary front-end, so I can't easily reverse-engineer how it does it

In this example, we have:

  • el-1, which runs an OpenVPN server, providing the network 10.26/24 (and acting as a gateway at 10.26.0.1). In the VLAN, it also has the address 192.168.50.51.
  • master, which is more heavily firewalled. In the VLAN, it has 192.168.50.41.

I've already accomplished setting up an OpenVPN server, and those clients can connect and reach (otherwise firewalled) ports on el-1 itself. Now I want those clients to somehow also access master through the same VPN, probably using the VLAN.

If I RDP into el-1, I can use the VLAN address of 192.168.50.41 to reach ports on master that aren't publicly open. So the VLAN does appear to work, and the firewall doesn't appear to be a problem at that stage.

Just for the sake of it, a client config:

client

dev tun

proto udp
remote (the server) 11194

resolv-retry infinite

nobind

persist-key
persist-tun

ca ca.crt
cert someUsername.crt
key someUsername.key

ns-cert-type server

cipher AES-256-CBC

comp-lzo

verb 3

Here's what the server config used to look like:

local 0.0.0.0

#we use a non-default port 11194
port 11194

proto udp

dev tun

client-config-dir ccd
ccd-exclusive

ca ..//easy-rsa//keys//ca.crt
cert ..//easy-rsa//keys//server.crt
key ..//easy-rsa//keys//server.key
dh ..//easy-rsa//keys//dh2048.pem

server 10.26.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

keepalive 10 60

cipher AES-256-CBC

comp-lzo

max-clients 20

persist-key
persist-tun

status ..//log//openvpn-status.log
verb 3

(I know comp-lzo and ns-cert-type are deprecated; that's a different matter.)

I then basically figured from the docs that server is a shorthand that may not accomplish this more complex scenario? So I broke that up as follows:

local 0.0.0.0

#we use a non-default port 11194
port 11194

proto udp

dev tun

client-config-dir ccd
ccd-exclusive

ca ..//easy-rsa//keys//ca.crt
cert ..//easy-rsa//keys//server.crt
key ..//easy-rsa//keys//server.key
dh ..//easy-rsa//keys//dh2048.pem

mode server
tls-server

ifconfig-pool-persist ipp.txt

keepalive 10 60

cipher AES-256-CBC

comp-lzo

max-clients 20

persist-key
persist-tun

status ..//log//openvpn-status.log
verb 3

# formerly the server directive
topology subnet
push "topology subnet"
ifconfig 10.26.0.1 255.255.255.0
ifconfig-pool 10.26.0.2 10.26.0.253
push "route-gateway 10.26.0.1"

I think that's supposed to be roughly equivalent, except now the topology is subnet, when it was net30 before). I then added the following:

# VLAN
push "route 192.168.50.0 255.255.255.0 10.26.0.1 1"

And the result looks right on the client! From the client-side OpenVPN log:

2020-04-02 10:39:27.067370 MANAGEMENT: >STATE:1585816767,ASSIGN_IP,,10.26.0.16,,,,
2020-04-02 10:39:27.067396 /sbin/ifconfig utun7 delete
                           ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2020-04-02 10:39:27.072671 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2020-04-02 10:39:27.072721 /sbin/ifconfig utun7 10.26.0.16 10.26.0.16 netmask 255.255.255.0 mtu 1500 up
2020-04-02 10:39:27.076570 /sbin/route add -net 10.26.0.0 10.26.0.16 255.255.255.0
                           add net 10.26.0.0: gateway 10.26.0.16
2020-04-02 10:39:27.082300 MANAGEMENT: >STATE:1585816767,ADD_ROUTES,,,,,,
2020-04-02 10:39:27.082345 /sbin/route add -net 192.168.50.0 10.26.0.1 255.255.255.0
                           add net 192.168.50.0: gateway 10.26.0.1

And the routes:

~> netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags        Netif Expire
default            192.168.2.234      UGSc           en0       
10.26/24           10.26.0.16         UGSc         utun7       
10.26.0.16         10.26.0.16         UH           utun7       
127                127.0.0.1          UCS            lo0       
127.0.0.1          127.0.0.1          UH             lo0       
169.254            link#4             UCS            en0      !
[..]
192.168.50         10.26.0.1          UGSc         utun7       
224.0.0/4          link#4             UmCS           en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI         en0       
255.255.255.255/32 link#4             UCS            en0      !

So that looks exactly correct, right? I should now be able to reach a port on 192.168.50.41 through the VPN at 10.26.0.1 (on utun7).

But it's filtered. I've temporarily disabled firewalls on both servers (which shouldn't be the reason); still filtered.

So,

  • how do I verify that the correct route is used? traceroute just gets stuck:

    ~> traceroute -n 192.168.50.41
    traceroute to 192.168.50.41 (192.168.50.41), 64 hops max, 52 byte packets
     1  * * *
     2  * * *
     3  * * *
  • am I mostly correct about my config? Do I need bridging? Is there something very basic I'm missing?
routing openvpn

1 Answers

  1. A few tips: route -n will return output similar to netstat -nr but will show route priorities (metric).

    Does 10.26/24 mean 10.26.0.0/24 ? Then it seems to overlap with 10.26.0.16 and there is some route duplication.

    Question:

    how do I verify that the correct route is used? traceroute just gets stuck:

    Use the ip route command to obtain the route for a given IP address eg:

    ip route get 192.168.50.41

    This alone should help you a lot with debugging.

    I would check the OpenVPN configuration file carefully, I don't think you really need this:

    ifconfig 10.26.0.1 255.255.255.0

    If your server is indeed 10.26.0.1, the client should take care of that and add the route on the fly. But maybe I am missing something, I cannot picture your network setup 100% right now.

    I suggest that you collect the output of route -n on the client before and after running OpenVPN, and compare results so you can see which routes were added from your configuration directives.

    (disclaimer: the next section that follows is speculative, I invite you to double-check and research the idea)

    Assuming that the VPN link otherwise works between client and server and that you have iptables on your server, you may need to add a rule so that clients are able to reach your local range 192.168.*

    To give you an idea, here is a configuration I once did on a Raspberry PI to forward traffic between interfaces eth0 & wlan0:

    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

    So maybe this type of rule could do the job and allow the VPN clients to transparently access the private range 192.168.*. You have to devise the exact rule depending on your network configuration but I don't know if this is going to be optimal from a security point of view, how your VLAN is set up etc. I lack some insight and I am not an iptables guru.

    Hopefully someone else who is more experienced can chime in here. There must be more than one way to accomplish that.

    I suppose that IP forwarding is already enabled on your server eg:

    echo 1 > /proc/sys/net/ipv4/ip_forward

    Note that we are just talking about IPv4 here but if your server is IPv6-capable and has IPv6 addresses configured you'll need to take care of that too.

    • 0