softether TAP interface on unprivileged container not passing to host

R

rexkani

Active Member
May 4, 2019
21
0
41
38
I'm sorry for posting the same thing on 2 forums, but i just realised this the the part where we talk about networking and maybe this is a more suitable place?

previous post:
https://forum.proxmox.com/threads/s...tainer-not-passing-to-host.54346/#post-251727

Dear all,

I have been trying to follow instructions found on this forum to enable my container to create a TAP device.
i used this on the pve host:

/etc/pve/lxc/102.conf

lxc.cgroup.devices.allow = c 10:200 rwm
lxc.mount.entry = /dev/net/tun dev/net/tun none bind,create=file
Click to expand...
i see the TAP device successfully created by softether:

2: tap_soft: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 5e:11:6f:f3:8f:db brd ff:ff:ff:ff:ff:ff
inet6 fe80::5c11:6fff:fef3:8fdb/64 scope link
valid_lft forever preferred_lft forever
Click to expand...
but when i try to establish a L2TP vpn from a remote host, the remote host traffic cant seem to go to the pve host and DHCP cannot be processed:

2019-05-16 03:03:21.625 On the TCP Listener (Port 0), a Client (IP address xxx.xxx.xxx.xxx, Host name "xxx.xxx.xxx.xxx", Port number 1701) has connected.
2019-05-16 03:03:21.625 For the client (IP address: xxx.xxx.xxx.xxx, host name: "xxx.xxx.xxx.xxx", port number: 1701), connection "CID-1" has been created.
2019-05-16 03:03:21.625 SSL communication for connection "CID-1" has been started. The encryption algorithm name is "(null)".
2019-05-16 03:03:21.625 [HUB "VPN"] The connection "CID-1" (IP address: xxx.xxx.xxx.xxx, Host name: xxx.xxx.xxx.xxx, Port number: 1701, Client name: "L2TP VPN Client", Version: 4.29, Build: 9680) is attempting to connect to the Virtual Hub. The auth type provided is "External server authentication" and the user name is "abc".
2019-05-16 03:03:21.625 [HUB "VPN"] Connection "CID-1": Successfully authenticated as user "abc".
2019-05-16 03:03:21.625 [HUB "VPN"] Connection "CID-1": The new session "SID-abc-[L2TP]-2" has been created. (IP address: xxx.xxx.xxx.xxx, Port number: 1701, Physical underlying protocol: "Legacy VPN - L2TP")
2019-05-16 03:03:21.625 [HUB "VPN"] Session "SID-abc-[L2TP]-2": The parameter has been set. Max number of TCP connections: 1, Use of encryption: Yes, Use of compression: No, Use of Half duplex communication: No, Timeout: 20 seconds.
2019-05-16 03:03:21.625 [HUB "VPN"] Session "SID-abc-[L2TP]-2": VPN Client details: (Client product name: "L2TP VPN Client", Client version: 429, Client build number: 9680, Server product name: "SoftEther VPN Server (64 bit)", Server version: 429, Server build number: 9680, Client OS name: "L2TP VPN Client", Client OS version: "-", Client product ID: "-", Client host name: "anonymous", Client IP address: "xxx.xxx.xxx.xxx", Client port number: 1701, Server host name: "xxx.xxx.xxx.xxx", Server IP address: "xxx.xxx.xxx.xxx", Server port number: 1701, Proxy host name: "", Proxy IP address: "0.0.0.0", Proxy port number: 0, Virtual Hub name: "VPN", Client unique ID: "FC3F68CDF0545A43EC372F364A3BE044")
2019-05-16 03:03:21.685 L2TP PPP Session [xxx.xxx.xxx.xxx:1701]: Trying to request an IP address from the DHCP server.
2019-05-16 03:03:26.687 L2TP PPP Session [xxx.xxx.xxx.xxx:1701]: Acquiring an IP address from the DHCP server failed. To accept a PPP session, you need to have a DHCP server. Make sure that a DHCP server is working normally in the Ethernet segment which the Virtual Hub belongs to. If you do not have a DHCP server, you can use the Virtual DHCP function of the SecureNAT on the Virtual Hub instead.
2019-05-16 03:03:33.368 L2TP PPP Session [xxx.xxx.xxx.xxx:1701]: The VPN Client sent a packet though an IP address of the VPN Client hasn't been determined.
2019-05-16 03:03:33.368 L2TP PPP Session [xxx.xxx.xxx.xxx:1701]: A PPP protocol error occurred, or the PPP session has been disconnected.
Click to expand...


Can anyone please help to solve this problem please?


Futher looking at my host, I'm not seeing any TAP device on the host, is this going to be an issue?
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
5: veth100i0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
12: veth103i0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr103i0 state UP group default qlen 1000
13: fwbr103i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
14: fwpr103p0@fwln103i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
15: fwln103i0@fwpr103p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr103i0 state UP group default qlen 1000
17: veth104i0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr104i0 state UP group default qlen 1000
18: fwbr104i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
19: fwpr104p0@fwln104i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
20: fwln104i0@fwpr104p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr104i0 state UP group default qlen 1000
22: veth105i0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr105i0 state UP group default qlen 1000
23: fwbr105i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
24: fwpr105p0@fwln105i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
25: fwln105i0@fwpr105p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr105i0 state UP group default qlen 1000
27: veth106i0@if26: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr106i0 state UP group default qlen 1000
28: fwbr106i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
29: fwpr106p0@fwln106i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
30: fwln106i0@fwpr106p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr106i0 state UP group default qlen 1000
32: veth108i0@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr108i0 state UP group default qlen 1000
33: fwbr108i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
34: fwpr108p0@fwln108i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
35: fwln108i0@fwpr108p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr108i0 state UP group default qlen 1000
37: veth102i0@if36: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr102i0 state UP group default qlen 1000
38: fwbr102i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
39: fwpr102p0@fwln102i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
40: fwln102i0@fwpr102p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr102i0 state UP group default qlen 1000
42: veth109i0@if41: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr109i0 state UP group default qlen 1000
43: fwbr109i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
44: fwpr109p0@fwln109i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
45: fwln109i0@fwpr109p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr109i0 state UP group default qlen 1000
Click to expand...

Therefore, with this showing in my "ip addr", it looks like it should be working?
2: tap_soft: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 5e:11:6f:f3:8f:db brd ff:ff:ff:ff:ff:ff
inet6 fe80::5c11:6fff:fef3:8fdb/64 scope link
valid_lft forever preferred_lft forever
Click to expand...

is there any other ways i could troubleshoot this issue? i'm kinda stuck on how to further investigate on the issue. i'm not sure where is the problem happening now.

just found this on the softether interface, which shows the mac address learned from the local-bridge, on the local-bridge built on the container's eth0, i can see mac addresses.



but on the local-bridge built on the TAP interface, no mac can be learnt


upload_2019-5-17_11-16-35-png.10303



I have ran tcpdump on the PVE host and i cannot see any DHCP traffic going out of my physical interface. and then i dont know how to further investigate.
 
Hi,

rexkani said:
I have been trying to follow instructions found on this forum to enable my container to create a TAP device.
i used this on the pve host:
Click to expand...

... you speak about TAP, but you create a TUN device:

lxc.mount.entry = /dev/net/tun dev/net/tun none bind,create=file


You can not see a interface for TUN(so you can not add in a bridge), but you can see only in the routing table. TUN is ok only for routing(on Layer 3). TAP is like a phisical interface at Layer 2! So DHCP will not work on any TUN interface, but it will work with TUN!

Good luck!
 
guletz said:
Hi,



... you speak about TAP, but you create a TUN device:

lxc.mount.entry = /dev/net/tun dev/net/tun none bind,create=file


You can not see a interface for TUN(so you can not add in a bridge), but you can see only in the routing table. TUN is ok only for routing(on Layer 3). TAP is like a phisical interface at Layer 2! So DHCP will not work on any TUN interface, but it will work with TUN!

Good luck!
Click to expand...

Hi guletz,

isnt the /dev/net/tun device file a pointer to the tap/tun driver which is neccessary for processes to point to it; and create a tap device from it?

this is what i understand from previous research. and most instructions found on the internet uses this approach.

does creating tap devices use the same device file /dev/net/tun? or does it use another one?

please direct me
 
If you make a TUN (/dev/net/tun) THEN you will get a TUN, not a TAP.

Try yourself:

Code: 
ip tuntap add mode tap dev tap0
ip link set dev tap0 up
ifconfig tap0
ls -l /dev/net/tun

... and you will not see ANY tap0 under /dev/net/tun !

And you can also check this:

Code: 
ethtool tap0

ethtool tun0

and see the difference
 
Last edited:
Oicccccc! I'm outside now, will give these a try when i get back! Thanks!!

So i should bind mount /dev/net/tap instead?
 
guletz said:
If you make a TUN (/dev/net/tun) THEN you will get a TUN, not a TAP.

Try yourself:

Code: 
ip tuntap add mode tap dev tap0
ip link set dev tap0 up
ifconfig tap0
ls -l /dev/net/tun

... and you will not see ANY tap0 under /dev/net/tun !

And you can also check this:

Code: 
ethtool tap0

ethtool tun0

and see the difference
Click to expand...


Hi Guletz,

according to this:

https://www.kernel.org/doc/Documentation/networking/tuntap.txt

In order to use the driver a program has to open /dev/net/tun and issue a
corresponding ioctl() to register a network device with the kernel. A network
device will appear as tunXX or tapXX, depending on the options chosen. When
the program closes the file descriptor, the network device and all
corresponding routes will disappear.

Depending on the type of device chosen the userspace program has to read/write
IP packets (with tun) or ethernet frames (with tap). Which one is being used
depends on the flags given with the ioctl().
Click to expand...

therefore, the /dev/net/tun is the only device file needed for tun/tap? so i bind mount the /dev/net/tun into the container for the creation of the tap device? if not, i cant find what else shall be used for the creation of the TAP interface
 
Hi,

See here if this is OK for you:

https://lists.linuxcontainers.org/pipermail/lxc-users/2015-July/009691.html

But this solve eventualy only the tap interface creation. The next problem is the fact that your vpn client need to create a such TAP interface at runtime. Maybe you can avoid this making a bridge between vpn client interface and the tap interface created before you start the CT!

So any solution it will be very complicated using a CT.
 
Last edited:
guletz said:
Hi,

See here if this is OK for you:

https://lists.linuxcontainers.org/pipermail/lxc-users/2015-July/009691.html

But this solve eventualy only the tap interface creation. The next problem is the fact that your vpn client need to create a such TAP interface at runtime. Maybe you can avoid this making a bridge between vpn client interface and the tap interface created before you start the CT!

So any solution it will be very complicated using a CT.
Click to expand...

This is actually what i did from the first post! and my VPN server did successfully created the TAP device but no traffic is running from the CT to the host.....
 
You must log in or register to reply here.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom