Debugging OpenVPN connection errors

Discussions in English on using Fedora
,
#1

I’m connecting to a VPN using the Network Manager plugin.
It doesn’t work and I see the following error in the logs:

Re-using pre-shared static key
nm-openvpn[19598]: Preserving previous TUN/TAP instance: tun0
nm-openvpn[19598]: /usr/libexec/nm-openvpn-service-openvpn-helper --debug 0 19594 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_15 --tun -- tun0 1500 1546 172.16.0.10 172.16.0.9 restart
dbus-broker[660]: A security policy denied :1.2342 to send method call /org/freedesktop/NetworkManager/VPN/Plugin:org.freedesktop.NetworkManager.VPN.Plugin.SetConfig to :1.2039.

The key is stored here:

$ ls -lZ .local/share/networkmanagement/certificates/vpn.key 
-rw-------. 1 fede fede unconfined_u:object_r:home_cert_t:s0 655  1 ott 10.12 .local/share/networkmanagement/certificates/vpn.key
1 Like
#2

Collect the AVC logs:

2 Likes
#3

In audit.log I found this:

type=AVC msg=audit(1602571477.232:348): avc:  denied  { read } for  pid=723 comm="chronyd" name="wlp1s0.sources" dev="tmpfs" ino=36770 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

So chronyd doesn’t have read access to wlp1s0.sources.
Here’s the file:

# ls -lZ /run/chrony-dhcp/wlp1s0.sources
-rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 28 13 ott 08.41 /run/chrony-dhcp/wlp1s0.sources

I forgot to say that I’m running Fedora 33 (prerelease).

1 Like
#4

That message doesn’t seem to be related to your issue.

Start log monitoring:

journalctl -f -g avc

And try to activate the connection.

#5

I get the same error:

$ journalctl -f -g avc
-- Logs begin at Mon 2020-09-07 12:57:03 CEST. --
ott 13 23:20:56 localhost.localdomain audit[673]: AVC avc:  denied  { read } for  pid=673 comm="chronyd" name="wlp1s0.sources" dev="tmpfs" ino=34495 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0
1 Like
#6

Switch SELinux to permissive mode and check if you can activate the connection:

sudo setenforce 0
#7

Swtching to permissive mode doesn’t help.

Perhaps it’s not a SELinux problem.

TCP connection times out. I wonder if it’s a firewall issue?

1 Like
#8

Yep, we have no proof for this to be a SELinux-related issue.

That’s unlikely as firewall does not limit outgoing connections by default.

Try to connect this way:

sudo openvpn --config profile.ovpn
#9

TCP connection timed out (remote IP amended with x.y.z.k):

Fri Oct 16 21:40:19 2020 TUN/TAP device tun0 opened
Fri Oct 16 21:40:19 2020 /sbin/ip link set dev tun0 up mtu 1500
Fri Oct 16 21:40:19 2020 /sbin/ip addr add dev tun0 local 172.16.0.14 peer 172.16.0.13
Fri Oct 16 21:40:19 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]x.y.z.k:1022
Fri Oct 16 21:40:19 2020 Attempting to establish TCP connection with [AF_INET]x.y.z.k:1022 [nonblock]
Fri Oct 16 21:42:19 2020 TCP: connect to [AF_INET]x.y.z.k:1022 failed: Connection timed out
Fri Oct 16 21:42:19 2020 SIGUSR1[connection failed(soft),init_instance] received, process restarting
1 Like
#10

Make sure the server is listening on the specified port and its firewall is configured properly.

#11

I forgot to say that I used a .ovpn file which is working correctly in a Windows machine. So problems on the server can be excluded.

#12 
ping -w 3 x.y.z.k
nmap -p 1022 x.y.z.k
tracepath -b x.y.z.k
1 Like
#13

This was the most useful debugging command as it said clearly “The host seems down”.

I double-checked the .ovpn file on the Windows machine and… boom! I was using the old IP of the remote server! Stupid me… I’m editing the title of this thread.

1 Like
#14

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.