0

Short Desc: Connecting Rasp pi 3 as client to data center dedicated server for pulling backups over rsync. Getting "ERROR: Cannot ioctl TUNSETIFF tun0: Device or resource busy (errno=16)"

Long Desc: After configuration, I've been trying to use my client to connect to the server, but I am getting the following from my client. I think I may have messed something up setting the before.rules in UFW.

Please note the following:

  • I do not have topology enabled on the server
  • I am using this for rsync only, no internet traffic, etc
  • Not sure why the server tries routing through 10.255.255.1
  • dh /etc/openvpn/dh2048.pem only on server, not on client
Tue May 12 09:54:40 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]Server.IP.address:1194
Tue May 12 09:54:40 2020 Socket Buffers: R=[163840->163840] S=[163840->163840]
Tue May 12 09:54:40 2020 UDP link local: (not bound)
Tue May 12 09:54:40 2020 UDP link remote: [AF_INET]Server.IP.address:1194
Tue May 12 09:55:40 2020 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue May 12 09:55:40 2020 TLS Error: TLS handshake failed

So I checked the openvpn.log and it shows:

Tue May 12 05:40:42 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Tue May 12 05:40:42 2020 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.08
Tue May 12 05:40:42 2020 Diffie-Hellman initialized with 2048 bit key
Tue May 12 05:40:42 2020 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 12 05:40:42 2020 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue May 12 05:40:42 2020 ROUTE_GATEWAY 10.255.255.1
Tue May 12 05:40:42 2020 ERROR: Cannot ioctl TUNSETIFF tun0: Device or resource busy (errno=16)
Tue May 12 05:40:42 2020 Exiting due to fatal error

So here's all the config data.

Server (notice topology is not enabled, didn't think it had to be):

;local a.b.c.d
port 1194
proto udp
dev tun0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key  # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/keys/ta.key 0 # This file is secret
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append  /var/log/openvpn/openvpn.log
verb 3
explicit-exit-notify 1
;dev-node MyTap
;topology subnet
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
;server-bridge
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
;learn-address ./script
;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 208.67.222.222"
;push "dhcp-option DNS 208.67.220.220"
;client-to-client
;duplicate-cn
;log         /var/log/openvpn/openvpn.log
;mute 20
;compress lz4-v2
;push "compress lz4-v2"
;comp-lzo
;max-clients 100

Client:

client
dev tun0
proto udp
remote server.ip.address 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/backupclient.crt
key /etc/openvpn/keys/backupclient.key
remote-cert-tls server
tls-auth /etc/openvpn/keys/ta.key 1
cipher AES-256-CBC
verb 3
;dev-node MyTap
;proto tcp
;http-proxy-retry
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
;remote my-server-2 1194
;remote-random
;mute 20

Server Netstat:

netstat -uapn | grep openvpn
udp   192768      0 0.0.0.0:1194            0.0.0.0:*                           27185/openvpn

/etc/default/ufw

DEFAULT_FORWARD_POLICY=”ACCEPT”

/etc/ufw/before.rules

# START OPENVPN RULES
# NAT table rules
#nat
:POSTROUTING ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# END OPENVPN RULES

ifconfig shows my device is eth0, and here is the tun0 interface that was started

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.255  destination 10.8.0.2
        inet6 fe80::7af3:d22d:86c3:1cd7  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 144 (144.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Here's the openvpn.log file showing a connection attempt, and I have not been able to get this to come up again (perhaps because the ip route changed to 10.8.0.2

Tue May 12 05:24:36 2020 OpenVPN 2.4.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2019
Tue May 12 05:24:36 2020 library versions: OpenSSL 1.1.1  11 Sep 2018, LZO 2.08
Tue May 12 05:24:36 2020 Diffie-Hellman initialized with 2048 bit key
Tue May 12 05:24:36 2020 ROUTE_GATEWAY 10.255.255.1
Tue May 12 05:24:36 2020 TUN/TAP device tun0 opened
Tue May 12 05:24:36 2020 TUN/TAP TX queue length set to 100
Tue May 12 05:24:36 2020 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue May 12 05:24:36 2020 /sbin/ip link set dev tun0 up mtu 1500
Tue May 12 05:24:36 2020 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Tue May 12 05:24:36 2020 /sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Tue May 12 05:24:36 2020 Could not determine IPv4/IPv6 protocol. Using AF_INET
Tue May 12 05:24:36 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Tue May 12 05:24:36 2020 UDPv4 link local (bound): [AF_INET][undef]:1194
Tue May 12 05:24:36 2020 UDPv4 link remote: [AF_UNSPEC]
Tue May 12 05:24:36 2020 GID set to nogroup
Tue May 12 05:24:36 2020 UID set to nobody
Tue May 12 05:24:36 2020 MULTI: multi_init called, r=256 v=256
Tue May 12 05:24:36 2020 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Tue May 12 05:24:36 2020 IFCONFIG POOL LIST
Tue May 12 05:24:38 2020 Client.Ip.Address:42834 TLS: Initial packet from [AF_INET]Client.Ip.Address:42834, sid=3a994a10 3f4eea3d
Tue May 12 05:24:38 2020 Client.Ip.Address:42834 TLS Error: reading acknowledgement record from packet
Tue May 12 05:24:48 2020 Client.Ip.Address:53172 TLS: Initial packet from [AF_INET]Client.Ip.Address:53172, sid=9af273bb 28096ff1
Tue May 12 05:24:48 2020 Client.Ip.Address:53172 TLS Error: reading acknowledgement record from packet
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 TLS: Initial packet from [AF_INET]Client.Ip.Address:46930, sid=26c7325a 33df4e52
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 VERIFY OK: depth=1, C=US, ST=WA, L=City, O=CompanyName, OU=Developer, CN=DS CA, name=EasyRSA, emailAddress=CompanyName@gmail.com
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 VERIFY OK: depth=0, C=US, ST=WA, L=City, O=CompanyName, OU=Developer, CN=backupclient, name=EasyRSA, emailAddress=CompanyName@gmail.com
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_VER=2.4.4
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_PLAT=linux
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_PROTO=2
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_NCP=2
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_LZ4=1
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_LZ4v2=1
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_LZO=1
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_COMP_STUB=1
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_COMP_STUBv2=1
Tue May 12 05:24:49 2020 Client.Ip.Address:46930 peer info: IV_TCPNL=1
Tue May 12 05:24:50 2020 Client.Ip.Address:46930 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
Tue May 12 05:24:50 2020 Client.Ip.Address:46930 [backupclient] Peer Connection Initiated with [AF_INET]Client.Ip.Address:46930
Tue May 12 05:24:50 2020 backupclient/Client.Ip.Address:46930 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Tue May 12 05:24:50 2020 backupclient/Client.Ip.Address:46930 MULTI: Learn: 10.8.0.6 -> backupclient/Client.Ip.Address:46930
Tue May 12 05:24:50 2020 backupclient/Client.Ip.Address:46930 MULTI: primary virtual IP for backupclient/Client.Ip.Address:46930: 10.8.0.6
Tue May 12 05:24:50 2020 Client.Ip.Address:53172 TLS Error: reading acknowledgement record from packet
Tue May 12 05:24:51 2020 backupclient/Client.Ip.Address:46930 PUSH: Received control message: 'PUSH_REQUEST'
Tue May 12 05:24:51 2020 backupclient/Client.Ip.Address:46930 SENT CONTROL [backupclient]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 2,cipher AES-256-GCM' (status=1)
Tue May 12 05:24:51 2020 backupclient/Client.Ip.Address:46930 Data Channel: using negotiated cipher 'AES-256-GCM'
Tue May 12 05:24:51 2020 backupclient/Client.Ip.Address:46930 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue May 12 05:24:51 2020 backupclient/Client.Ip.Address:46930 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue May 12 05:24:54 2020 Client.Ip.Address:42834 TLS Error: reading acknowledgement record from packet
Tue May 12 05:24:54 2020 Client.Ip.Address:53172 TLS Error: reading acknowledgement record from packet
Justin C
  • 103
  • 4

1 Answers1

1

Why do you have dev tun0 instead of dev tun (or even dev tun_a or whatever). I think you should avoid using an enumerated name explicitly. The error seems to indicate you already have some tun0 anyway.

Tom Yan
  • 715
  • 2
  • 9
  • Indeed, I closed this with ifconfig tun0 down, made the changes I needed to the config file, then restarted openvpn and ran a test with openvpn --config /etc/openvpn/server.conf. This solved the problem, thank you! I also changed back to just dev tun, though documentation specifically mentions using enumeration here, but doesn't seem necessary. – Justin C May 13 '20 at 07:32
  • 1
    Just remember that you can use a non-enumerated specific name if you need to have ip / firewall rules matching a specific tunnel interface. (When with `dev-type tun` it can begin with not only "tun" but anything valid for interface name.) – Tom Yan May 13 '20 at 08:06