Hi Theunis,

Thanks for sharing! Glad you finally had it working.

silly me, as you said - The tun device must be owned by the user (resp. local and remote) or the group to which the user belongs

my permissions on both machines was:

$ ls -la /dev/net/tun
crw-rw---- 1 root vpn 10, 200 Jun 5 09:25 /dev/net/tun

when I created the tun0 device using tunctl I did this:

tunctl -n -u root -g vpn -t tun0

This seemed to have caused the problem. Because I for some reason specified that I had to set the user to be root too, thinking it had to be exactly the same as the permissions on /dev/net/tun. Instead of only setting group id to vpn. So it appears that I masked it to that specific user + group. DOH!

when I ran tunctl -d tun0 as root to remove the tun0 device and ran it with:

tunctl -n -g vpn -t tun0 on both the client and server, and it worked as an ordinary user. how strange... by leaving out -u username

I also got it working by doing the following on both machines:

as root:

tunctl -d tun0
chown username:vpn /dev/net/tun
tunctl -n -u username -g vpn -t tun0

this then makes it specific for that only

then logging on as ordinary user to remote machine as ordinary user works too.

FYI for those that have been knocking their head against the wall like I did :)

iproute2 tool ip
remote: iproute2-ss080725
client: iproute2-ss091226

remote machine also contains PermitTunnel yes in /etc/ssh/sshd_config, sshd was restarted too.

tun device driver part of the kernel (remote)
tun device was inserted using modprobe tun (client)

ownership was adapted on both client and server
chown root:vpn /dev/net/tun

crw-rw---- 1 root vpn 10, 200 Nov 8 09:30 /dev/net/tun

users on both client and server belongs to the group: vpn

my iproute2 package does not seem to support creating tuntap devices on both client and server

I used tunctl (tunctl-1.5) command with tunctl -n -u root -g vpn -t tun0 on both machines and added ips like mentioned in your post above. This does work when I run as root on the client and ssh root@remote-server -w 0:0, but not as ordinary user that belongs to the vpn group. Even if the devices are up and configured.

What version of iproute2 do you have and what is your kernel version and what openssh server version do you have?

I also added this to my udev rules to make the permissions persistent:

# cat /etc/udev/rules.d/50-udev.rules
KERNEL=="tun", NAME="net/%k", GROUP="vpn", MODE="0660"

So far I only noticed your ip command could create tuntap devices + your permissions seems to be 0666 where as mine is 0660

output when using (root) client : ssh root@remote -w 0:0

$ ssh remote-server -C -w 0:0
Password:
Last login: Mon Nov 8 09:57:31 SAST 2010 from client on pts/1
# ping 10.0.0.1 -c 1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=183 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 183.090/183.090/183.090/0.000 ms
# exit

Now for ordinary user (client) to ordinary user on (remote)
devices still exist and configured on client and server.

$ ssh remote-server -C -w 0:0 (using a key)
Tunnel device open failed.
Could not request tunnel forwarding.

$ ping 10.0.0.1 -c 1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

$ ping 10.0.0.2 -c 1
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.104 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.104/0.104/0.104/0.000 ms

$ exit

So it appears I can only ping the ip on the remote machine when I'm logged onto the remote machine as the ordinary user.

here is what happens when I run ssh as root on the client machine and connect to remote as ordinary user

# ssh username@remote-machine -C -o Tunnel=point-to-point -w 0:0
Password:
channel 0: open failed: administratively prohibited: open failed
Last login: Mon Nov 8 10:14:43 SAST 2010 from client on pts/1

output of when I run as ordinary user on local and connect to root at remote machine:

$ ssh root@remote-machine -C -w 0:0
Password:
Tunnel device open failed.
Could not request tunnel forwarding.
Last login: Mon Nov 8 10:09:53 SAST 2010 from client on pts/1

Hope this does give some insight. into my problem. My client however does not have PermitTunnel yes in /etc/sshd/sshd_config.

Again just stressing, it all works when running as root@client to root@remote

both machines are restarted since added to vpn group, by typing in groups on both machines it confirms that the ordinary users are part of the vpn group.

There are quite a few conditions that have to be true for normal users to be able to use the tunnel:

- The remote server must have PermitTunnel yes in /etc/ssh/sshd_config (this is true regardless of the user)
- The tun/tap devices must already exist
- The local user must have write permission on /dev/net/tun on the local machine, and the remote user must have write permission on /dev/net/tun on the remote machine
- The tun device must be owned by the user (resp. local and remote) or the group to which the user belongs

And of course, even if the above conditions are met, a normal user still can't add IP addresses to the tun/tap device. So I would add a fourth condition if IP addresses are wanted:

- IP addresses must be preconfigured on the local and remote tun/tap interfaces.

The following works for me (note that my local normal user is member of the group "users" on both machines):

root@local # chown :users /dev/net/tun && chmod o-rw /dev/net/tun
root@local # ls -l /dev/net/tun
crw-rw---- 1 root users 10, 200 Nov 5 22:27 /dev/net/tun
root@local # ip tuntap add dev tun7 mode tun group users && ip link set tun7 up

root@remote # chown :users /dev/net/tun && chmod o-rw /dev/net/tun
root@remote # ls -l /dev/net/tun
crw-rw---- 1 root users 10, 200 Nov 5 22:29 /dev/net/tun
root@remote # ip tuntap add dev tun7 mode tun group users && ip link set tun7 up

waldner@local $ ssh -w 7:7 waldner@remote
Last login: Sat Nov 6 00:52:21 GMT 2010 from 10.8.0.210 on pts/8

As said, to use the tunnel at the IP level, you also need to assign IP addresses to the two interfaces as part of the preparation (not shown above).