How to create tun device for OpenVPN in (B)LFS 9.0 System V?
Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How to create tun device for OpenVPN in (B)LFS 9.0 System V?
Hey guys
I've been trying for a while to get a working VPN in my LFS build. I've installed bridge-utils (although not sure if needed or how to use it), IProute2 and Openvpn. I've enabled the universal tun/tap driver in the kernel with (*) not (m) if that's relevant info.
I've read various info on the web and tried the following:
I've been trying for a while to get a working VPN in my LFS build. I've installed bridge-utils (although not sure if needed or how to use it), IProute2 and Openvpn. I've enabled the universal tun/tap driver in the kernel with (*) not (m) if that's relevant info.
I've read various info on the web and tried the following:
Thanks. I tried adding the rule as you said to "/etc/udev/rules.d/70-persistent-net.rules" but it didn't seem to change much. Still get the same result. Should I try enabling the driver as a module instead of built in by the kernel?
I recompiled the kernel to use the tun driver as a module, which I guess makes much more sense as the driver won't actually load until there is something to load, and this seems to have worked. Running "modinfo tun" now after the other commands posted above reveals the driver is now running
However, when starting openvpn or adding the tun device with "ip tuntap add mode tun tun0" the console now freezes. It won't react to any commands such as ctrl-c or ctrl-z. I found out that doing this crashes network manager. Even restarting won't work and I have to use the power button.
At least now I'm closer to a solution, but I wonder why it crashes. I'll try and check /var/log/sys.log, but I'm not entirely sure what to look for and that file is huge by now.
I've rebuilt my entire system most everything seems to work better now. The kernel no longer panicks when adding a tun device and openvpn actually seems to be able to create one by itself without me having to do it manually.
So good progress then, but, openvpn now gets stuck when trying to add routes. Some googling reveals many have had similar issues and I've tried some of the suggested fixes but no luck.
This is the output openvpn now gives:
Quote:
Thu Dec 19 15:37:35 2019 WARNING: --ping should normally be used with --ping-restart or --ping-exit
Thu Dec 19 15:37:35 2019 NOTE: --fast-io is disabled since we are not using UDP
Thu Dec 19 15:37:35 2019 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Dec 19 15:37:35 2019 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Dec 19 15:37:35 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]95.174.66.187:443
Thu Dec 19 15:37:35 2019 Socket Buffers: R=[131072->131072] S=[16384->16384]
Thu Dec 19 15:37:35 2019 Attempting to establish TCP connection with [AF_INET]95.174.66.187:443 [nonblock]
Thu Dec 19 15:37:36 2019 TCP connection established with [AF_INET]95.174.66.187:443
Thu Dec 19 15:37:36 2019 TCP_CLIENT link local: (not bound)
Thu Dec 19 15:37:36 2019 TCP_CLIENT link remote: [AF_INET]95.174.66.187:443
Thu Dec 19 15:37:36 2019 TLS: Initial packet from [AF_INET]95.174.66.187:443, sid=94991d5b fd9a8265
Thu Dec 19 15:37:36 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Dec 19 15:37:36 2019 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
Thu Dec 19 15:37:36 2019 VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA4
Thu Dec 19 15:37:36 2019 VERIFY KU OK
Thu Dec 19 15:37:36 2019 Validating certificate extended key usage
Thu Dec 19 15:37:36 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Dec 19 15:37:36 2019 VERIFY EKU OK
Thu Dec 19 15:37:36 2019 VERIFY OK: depth=0, CN=no81.nordvpn.com
Thu Dec 19 15:37:36 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Thu Dec 19 15:37:36 2019 [no81.nordvpn.com] Peer Connection Initiated with [AF_INET]95.174.66.187:443
Thu Dec 19 15:37:38 2019 SENT CONTROL [no81.nordvpn.com]: 'PUSH_REQUEST' (status=1)
Thu Dec 19 15:37:38 2019 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway 10.7.2.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.7.2.6 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: timers and/or timeouts modified
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: compression parms modified
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: --sndbuf/--rcvbuf options modified
Thu Dec 19 15:37:38 2019 Socket Buffers: R=[131072->425984] S=[87040->425984]
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: --ifconfig/up options modified
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: route options modified
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: route-related options modified
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: peer-id set
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: adjusting link_mtu to 1659
Thu Dec 19 15:37:38 2019 OPTIONS IMPORT: data channel crypto options modified
Thu Dec 19 15:37:38 2019 Data Channel: using negotiated cipher 'AES-256-GCM'
Thu Dec 19 15:37:38 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Dec 19 15:37:38 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Dec 19 15:37:38 2019 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlan0 HWADDR=60:67:20:6a:22:66
Thu Dec 19 15:37:38 2019 TUN/TAP device tun1 opened
Thu Dec 19 15:37:38 2019 TUN/TAP TX queue length set to 100
Thu Dec 19 15:37:38 2019 /sbin/ifconfig tun1 10.7.2.6 netmask 255.255.255.0 mtu 1500 broadcast 10.7.2.255
Thu Dec 19 15:37:38 2019 /sbin/route add -net 95.174.66.187 netmask 255.255.255.255 gw 192.168.1.1
Thu Dec 19 15:37:38 2019 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.7.2.1
SIOCADDRT: Network is unreachable
Thu Dec 19 15:37:38 2019 ERROR: Linux route add command failed: external program exited with error status: 7
Thu Dec 19 15:37:38 2019 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.7.2.1
SIOCADDRT: Network is unreachable
Thu Dec 19 15:37:38 2019 ERROR: Linux route add command failed: external program exited with error status: 7
Thu Dec 19 15:37:38 2019 Initialization Sequence Completed
Edit:
I somehow managed to get it to work, problem is I was just experimenting and shooting in the dark, but what I (think I) did was to put the tun device up manually before running opevpn with this command:
Code:
ip link set dev tun0 up mtu 1500
Then I checked the routes which looked like this:
Code:
root [ /home/bio ]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 600 0 0 wlan0
10.7.3.0 * 255.255.255.0 U 0 0 0 tun1
95.174.66.187 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
192.168.1.0 * 255.255.255.0 U 304 0 0 wlan0
192.168.1.0 * 255.255.255.0 U 600 0 0 wlan0
But my traffic still seemed to not through the vpn, which is probably obvious to someone who understands this by looking at the table.
I then manually ran the route commands which openvpn claims to have done (which it did without any without any errors):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.7.3.1 128.0.0.0 UG 0 0 0 tun1
default 192.168.1.1 0.0.0.0 UG 600 0 0 wlan0
10.7.3.0 * 255.255.255.0 U 0 0 0 tun1
95.174.66.187 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
128.0.0.0 10.7.3.1 128.0.0.0 UG 0 0 0 tun1
192.168.1.0 * 255.255.255.0 U 304 0 0 wlan0
192.168.1.0 * 255.255.255.0 U 600 0 0 wlan0
At which point everything seems to work. Problem is although I'll probably manage to reproduce this with some fiddling, I need to understand exactly what's going on. I also did some "ifconfig tun0 up" which may or may not have contributed to this result, but it's all a bit chaotic at this point.
Sorry for the spamming, but I sort of have a way of getting it to work now. First I start the openvpn client with
Quote:
openvpn --config <config file>
Which will open the connection to the server, but fail with the route commands. Then I type
Quote:
ifconfig tun1 up
[the two route commands that fails when openvpn tries itself]
This works, but it would be better if I understood why it fails when the openvpn software tries to do it itself and what the procedure should actually be. There also seems to be a tun0 device there already from boot, but which openvpn doesn't try to use, even when I pass the "--dev tun0" argument to it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
