OpenVPN / NordVPN tunnels TUN (solved) and not resolved for LXC privileged containers

[Rikard]

Hi,

Solved: To get NordVPN and OpenVPN to run
Unsolved: To access the LXC privileged from another server in the same LAN.

I tried to install OpenVPN and ran into the TUN issue like most people. I noticed NordVPN who I use have their own app as well as support for OpenVPN.

The simple fix to get NordVPN to run is to:
append this at the end of /etc/pve/lxc/your_lxc_number.config:
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file
(In my case the file was /etc/pve/lxc/101.conf )

Secondly, in the LXC running Ubuntu latest:
crontab -e
add this line at the end:
@reboot mkdir -p /dev/net && mknod /dev/net/tun c 10 200

now, after a reboot, the nordvpn can be installed as in their lazy tutorial.

Unresolved
I have done the above. NordVPN works great running over systemd
I can't access my server LXC in the local LAN. I just spoke with NordVPN support and they said there are no ways to do port forwarding to access their VPN from the outside.
Well, what about the inside? iptables? UFW is completely disabled when nordvpnd is run.
Any suggestions?

 

[Stefan_R]

I can't access my server LXC in the local LAN.

Do you mean the container itself is not reachable (i.e. via SSH) or do you want to use it as a gateway to the OpenVPN tunnel for other machines in your network?

It the latter is the case, you need to configure IP forwarding and Masquerading (NAT) with something like:

# run this at startup somehow (e.g. crontab with @reboot or hook into your OpenVPN start)
sysctl net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <your-tun-interface> -j MASQUERADE

Then other computers in your LAN should be able to use your container's internal IP as a gateway (ip route add default via <container ip> metric 1) and have their traffic routed through the VPN.

 

[Rikard]

Do you mean the container itself is not reachable (i.e. via SSH) or do you want to use it as a gateway to the OpenVPN tunnel for other machines in your network?

It the latter is the case, you need to configure IP forwarding and Masquerading (NAT) with something like:

# run this at startup somehow (e.g. crontab with @reboot or hook into your OpenVPN start)
sysctl net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <your-tun-interface> -j MASQUERADE

Then other computers in your LAN should be able to use your container's internal IP as a gateway (ip route add default via <container ip> metric 1) and have their traffic routed through the VPN.

The container is not reachable from the same LAN. For example if the container runs on 192.168.1.140, then I can't access it from 192.168.1.150 (same LAN, same subnet). I do not use it as a gateway for other machines in my network. So for the case where I don't want the container to act as gateway, I should just use:

# run this at startup somehow (e.g. crontab with @reboot or hook into your OpenVPN start)
sysctl net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <your-tun-interface> -j MASQUERADE

?

I also found this on the internet, which is a bit confusing. Will it solve the same problem?

-A PREROUTING -i vmbr1 -p tcp -m tcp --dport 53 -j DNAT --to-destination 192.168.100.2:53
-A PREROUTING -i vmbr1 -p udp -m udp --dport 1194 -j DNAT --to-destination 192.168.100.2:1194
-A PREROUTING -i vmbr1 -p tcp -m tcp --dport 1194 -j DNAT --to-destination 192.168.100.2:1194

The two ports 53 and 1194 are the ports the VPN is using...

 

[Stefan_R]

So for the case where I don't want the container to act as gateway, I should just use:

No, this is for the case you want to use the host as a gateway.

The container not being reachable from the local network is a seperate issue from any VPNs. Does this occur only when the VPN is running or could you never access the container from LAN?

I would recommend checking for any firewalls in the container, or on the host (PVE offers an integrated firewall, but it should be disabled by default). Could you post your '/etc/pve/lxc/<vmid>.conf' and your '/etc/network/interfaces' files?

I also found this on the internet, which is a bit confusing. Will it solve the same problem?

The code you posted seems to be for forwarding VPN traffic to a different local address, which seems unrelated?

 

[Rikard]

No, this is for the case you want to use the host as a gateway.

The container not being reachable from the local network is a seperate issue from any VPNs. Does this occur only when the VPN is running or could you never access the container from LAN?

I would recommend checking for any firewalls in the container, or on the host (PVE offers an integrated firewall, but it should be disabled by default). Could you post your '/etc/pve/lxc/<vmid>.conf' and your '/etc/network/interfaces' files?


The code you posted seems to be for forwarding VPN traffic to a different local address, which seems unrelated?

The PVE firewall was/is disabled.
I can access the container from the LAN when the VPN is off. When it is on, i can't connect to the container any longer.
Here's the /etc/pve/lxc/100.conf at the host:

root@riliprox:~# more /etc/pve/lxc/100.conf
arch: amd64
cores: 4
hostname: rtorrent
memory: 32768
mp0: /mnt/pve/scratch/data,mp=/mnt/download,ro=0
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.1,hwaddr=02:E1:77:ED:C3:C5,ip=192.168.1.147/24,type=veth
ostype: debian
rootfs: containers:subvol-100-disk-0,replicate=0,size=60G
swap: 512
features: nesting=1
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

Here are the interfaces (which looks identical after the VPN goes online inside the container) from /etc/network/interfaces at the host:

root@riliprox:/etc/network# more interfaces
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.146
        netmask 255.255.255.0
        gateway 192.168.1.1
        bridge_ports eno1
        bridge_stp off
        bridge_fd 0

iface eno2 inet manual

iface enp216s0f4 inet manual

iface enp216s0f4d1 inet manual

Here's the ip a command before the vpn goes on inside the container:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen
1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
47: eth0@if48: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group
default qlen 1000
    link/ether 02:e1:77:ed:c3:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.147/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::e1:77ff:feed:c3c5/64 scope link
       valid_lft forever preferred_lft forever

Here's the ip a command after the vpn goes online -making the container inaccessible from the LAN:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen
1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq state UNKNOWN gro
up default qlen 100
    link/none
    inet 10.8.3.15/24 brd 10.8.3.255 scope global tun0
       valid_lft forever preferred_lft forever
47: eth0@if48: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group
default qlen 1000
    link/ether 02:e1:77:ed:c3:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.1.147/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever

Here's iptables -S in the container before the VPN is online:

root@rtorrent:~# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

This is iptables -S in the container after the VPN is online:

root@rtorrent:~# iptables -S
-P INPUT DROP
-P FORWARD ACCEPT
-P OUTPUT DROP
-A INPUT -i tun0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 185.236.42.74/32 -i lo -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 127.0.0.0/8 -i lo -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 185.236.42.74/32 -i tun0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 10.8.3.0/24 -i tun0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 185.236.42.74/32 -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.1.0/24 -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A OUTPUT -d 103.86.96.100/32 -o lo -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -d 103.86.99.100/32 -o lo -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -d 103.86.96.100/32 -o tun0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -d 103.86.99.100/32 -o tun0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -d 185.236.42.74/32 -o lo -j ACCEPT
-A OUTPUT -d 127.0.0.0/8 -o lo -j ACCEPT
-A OUTPUT -d 185.236.42.74/32 -o tun0 -j ACCEPT
-A OUTPUT -d 10.8.3.0/24 -o tun0 -j ACCEPT
-A OUTPUT -d 185.236.42.74/32 -o eth0 -j ACCEPT
-A OUTPUT -d 192.168.1.0/24 -o eth0 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

 

[Rikard]

[SOLVED] With the ugliest solution there is.
The VPN leverage iptables quite strictly. Apparently I couldn't connect to my container from a different LAN computer.
My quick and dirty solution is simply to start the VPN and then type:
iptables -I INPUT -j ACCEPT
By doing so, the container accepts traffic from anywhere outside. Ideally, it should be restricted further to only allow traffic from my other LAN computer that needs to access the machine. I haven't found out a way how to change the command line iptables -I INPUT -j ACCEPT ,into allowing incoming traffic from only a single IP. I guess it is outside the scope of this forum...

At least some traffic is going over the VPN after my dirty fix, and the connection is being proxied by the VPN.
root@rtorrent:~# host myip.opendns.com resolver1.opendns.com | grep "myip.opendns.com has" | awk '{print $4}'
45.12.220.76 <-- VPN public IP

root@rtorrent:~# nordvpn disconnect
You are disconnected from NordVPN.
How would you rate your connection quality on a scale from 1 (poor) to 5 (excellent)? Type 'nordvpn rate [1-5]'.
root@rtorrent:~# host myip.opendns.com resolver1.opendns.com | grep "myip.opendns.com has" | awk '{print $4}'
***.***.***.*** <-- My public IP from my ISP (masked in this post)

 

[Stefan_R]

This probably is outside the scope of the forum, but I took a look anyway, and it seems a potential fix would be to run

nordvpn set killswitch off
# or
nordvpn whitelist add port 22

according to the nordvpn docs.

The correct iptables command you wanted would be:

iptables -I INPUT -s <source ip> -j ACCEPT

I suggest the iptables man page, it explains the concept of iptables well.

 

[Rikard]

@Stefan_R You are awesome!
It all make sense, and I'll update the configuration to reflect what you suggest. My solution was indeed dirty but at least I could figure out what went wrong. Thank you so much for your expertise!!