OpenVPN Tap deployment on Ubuntu 18.04 LXC

abbynormal

Member
Oct 18, 2018
9
1
23
35
I hope this isn't too far outside of the scope of discussion here but I'm pulling at strings trying to solve this.

I have a Ubuntu 18.04 container that I've been trying to install an OpenVPN server to in tap mode (bridged), with no dice. After attempting to activate the service, I'm left continually looking at:

Code:
root@vpnPublic:~# systemctl is-active openvpn@server
activating

Since attempting this, I've been through many iterations of containers and troubleshooting. In the process I found that no matter what I do, and unprivileged LXC will not work (even for standard non-bridged deployment). This is with the inclusion of " lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file" in the /etc/pve/lxc/x.confg.

I only noticed this when sanity checking a standard non-bridge deployment. The only difference I see is with permissions of that directory:

Unprivleged:
Code:
root@vpnPublic:~# systemctl is-active openvpn@server
activating

root@vpnPublic:~# ls -l /dev/net/tun
crw-rw-rw- 1 nobody nogroup 10, 200 Sep 15 17:02 /dev/net/tun

Privleaged:
Code:
root@vpnPublic:~# ls -l /dev/net/tun
crw-rw-rw- 1 root root 10, 200 Sep 15 18:01 /dev/net/tun

root@vpnPublic:~# systemctl is-active openvpn@server
active

What's further interesting is that I still have to prime the LXC privleaged LXC with the "lxc.mount.entry" command, other wise /dev/net/tun won't appear in the container at all.

Anyways, I've gotten to a point where I at least know the standardized deployment works. Now I'm trying to fight through any possible caveats on the Proxmox side for such a bridged deployment.

I just installed "bridge-utils" and then pushed the config over via netplan in the LXC, as seen below:

Code:
root@vpnPublic:~# apt install bridge-utils


~                                                                                                                                         
~                                                                                                                                         
  GNU nano 2.9.3                                                    01-netcfg.yaml                                                       

network:
  version: 2
  renderer: networkd

  ethernets:
    eth0:
      dhcp4: false
      dhcp6: false
      #addresses: [192.168.1.239/24]
      #gateway4: 192.168.1.1
      #mtu: 1500
      #nameservers:
      #  addresses: [8.8.8.8]

  bridges:
    tap0:
      interfaces: [eth0]
      addresses: [10.5.5.5/24]
      gateway4: 10.5.5.1
      mtu: 1500
      nameservers:
        addresses: [8.8.8.8]
      parameters:
        stp: true
        forward-delay: 4
      dhcp4: no
      dhcp6: no


And confirm in ifconfig that this is seen:

Code:
root@vpnPublic:/etc/netplan# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether XX.XX.XX.XX  txqueuelen 1000  (Ethernet)
        RX packets 35  bytes 36239 (36.2 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 43  bytes 4050 (4.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tap0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 10.5.5.5  netmask 255.255.255.0  broadcast 10.5.5.255
        ether XX.XX.XX.XX txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


I've also verified general network connectivity still works via eth0 to the tap0 IP. However the openvpn@server service is still stuck in "activating" at this piont.

Any other possible "gotchas" on the Proxmox side that I'm missing for this deployment. For reference, my openvpn server.conf can be seen here. The LXC config is as follows:

Code:
arch: amd64
cores: 2
hostname: vpnPublic
memory: 2048
nameserver: 208.67.222.222
net0: name=eth0,bridge=vmbr1,firewall=1,gw=10.5.5.1,hwaddr=XX:XX:XX:XX:XX:XX,ip=10.5.5.5/24,tag=300,type=veth
ostype: ubuntu
rootfs: local-lvm:vm-112-disk-0,size=8G
swap: 0
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file
 
Last edited:
I only noticed this when sanity checking a standard non-bridge deployment. The only difference I see is with permissions of that directory:

Unprivleged:
Code:
root@vpnPublic:~# systemctl is-active openvpn@server
activating

root@vpnPublic:~# ls -l /dev/net/tun
crw-rw-rw- 1 nobody nogroup 10, 200 Sep 15 17:02 /dev/net/tun

Privleaged:
Code:
root@vpnPublic:~# ls -l /dev/net/tun
crw-rw-rw- 1 root root 10, 200 Sep 15 18:01 /dev/net/tun

root@vpnPublic:~# systemctl is-active openvpn@server
active

What's further interesting is that I still have to prime the LXC privleaged LXC with the "lxc.mount.entry" command, other wise /dev/net/tun won't appear in the container at all.
I'm not sure if this will help, but maybe create a separate tun device node with the correct permissions for an unprivileged container like this?
 
I'm not sure if this will help, but maybe create a separate tun device node with the correct permissions for an unprivileged container like this?

Hmm that's a good thought once I appropriately get it functioning in a privileged container. However that's a step beyond where I sit now, given privileged containers still do not function when attempting tap mode against bridge interfaces.

Either my deployment of bridge interfaces in Ubuntu for tap mode is incorrect, or I'm missing something that explicitly needs to be configured for a deployment in the LXC config. Assuming my server.conf file is correct as well. I'll try to concentrate on the "activating" state and see if I can find any pointers in what specifically is hanging this process.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!