connecting to OpenVPN server: why NetworkManager nm-openvpn gererates curious, pointless random hostnames?
I'm trying to configure OpenVPN connection in Fedora 37 NetworkManager. The configuration was created by importing the .ovpn file and subsequent its result correction. But connection is not working, and it seems it is because MetwokManage/nm-openvpn prepend OpenVPN server name with random string - which, of course, isn't resolvable to IP (v4) address.
My configuration file is: # cat /etc/NetworkManager/system-connections/lada.nmconnection [connection] id=mojevpn uuid=523155d8-ce42-499f-9b65-371733cd420c type=vpn autoconnect=false
[vpn] ca=/etc/pki/vpnky/mojevpn/mojevpn-ca.pem cert=/etc/pki/vpnky/mojevpn/mojevpn-cert.pem cert-pass-flags=4 cipher=AES-128-GCM connection-type=password-tls dev=tun dev-type=tun key=/etc/pki/vpnky/mojevpn/mojevpn-key.pem password-flags=2 remote=gw.mujsrv.org remote-cert-tls=server remote-random-hostname=yes ta=/etc/pki/vpnky/mojevpn/mojevpn-tls-auth.pem ta-dir=0 username=lada service-type=org.freedesktop.NetworkManager.openvpn
[ipv4] method=auto
[ipv6] addr-gen-mode=stable-privacy method=disabled
[proxy]
# nmcli connection up --ask mojevpn You need to authenticate to access the Virtual Private Network “mojevpn”. Password (vpn.secrets.password): •••••••••• Error: Connection activation failed: The connection attempt timed out
And what is listen with tcpdump and in syslog:
# tcpdump -i any -B 64000 -nn port 53 or port 1194 20:27:55.403571 enp4s0 Out IP 172.31.48.127.44308 > 172.31.48.254.53: 3278+ [1au] A? 7cf36e0b3a88.gw.mujsrv.org. (53) 20:27:55.403711 enp4s0 Out IP 172.31.48.127.36822 > 172.31.48.254.53: 58603+ [1au] AAAA? 7cf36e0b3a88.gw.mujsrv.org. (53) 20:27:55.545573 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.36822: 58603 NXDomain 0/1/1 (138) 20:27:55.545752 enp4s0 Out IP 172.31.48.127.36822 > 172.31.48.254.53: 58603+ AAAA? 7cf36e0b3a88.gw.mujsrv.org. (42) 20:27:55.546081 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.36822: 58603 NXDomain 0/1/0 (127) 20:27:55.548708 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.44308: 3278 NXDomain 0/1/1 (138) 20:27:55.549710 enp4s0 Out IP 172.31.48.127.60509 > 172.31.48.254.53: 41153+ [1au] A? bd30780f6ca9.gw.mujsrv.org. (53) 20:27:55.549819 enp4s0 Out IP 172.31.48.127.35849 > 172.31.48.254.53: 43141+ [1au] AAAA? bd30780f6ca9.gw.mujsrv.org. (53) 20:27:55.610201 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.60509: 41153 NXDomain 0/1/1 (138) 20:27:55.610256 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.35849: 43141 NXDomain 0/1/1 (138) 20:27:55.610349 enp4s0 Out IP 172.31.48.127.60509 > 172.31.48.254.53: 41153+ A? bd30780f6ca9.gw.mujsrv.org. (42) 20:27:55.610427 enp4s0 Out IP 172.31.48.127.35849 > 172.31.48.254.53: 43141+ AAAA? bd30780f6ca9.gw.mujsrv.org. (42) 20:27:55.610635 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.60509: 41153 NXDomain 0/1/0 (127) 20:27:55.610677 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.35849: 43141 NXDomain 0/1/0 (127) 20:28:15.631685 enp4s0 Out IP 172.31.48.127.46400 > 172.31.48.254.53: 33469+ [1au] A? 041d1d870348.gw.mujsrv.org. (53) 20:28:15.631799 enp4s0 Out IP 172.31.48.127.38725 > 172.31.48.254.53: 21530+ [1au] AAAA? 041d1d870348.gw.mujsrv.org. (53) 20:28:15.776090 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.46400: 33469 NXDomain 0/1/1 (138) 20:28:15.776145 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.38725: 21530 NXDomain 0/1/1 (138) 20:28:15.776247 enp4s0 Out IP 172.31.48.127.46400 > 172.31.48.254.53: 33469+ A? 041d1d870348.gw.mujsrv.org. (42) 20:28:15.776330 enp4s0 Out IP 172.31.48.127.38725 > 172.31.48.254.53: 21530+ AAAA? 041d1d870348.gw.mujsrv.org. (42) 20:28:15.776663 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.46400: 33469 NXDomain 0/1/0 (127) 20:28:15.776711 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.38725: 21530 NXDomain 0/1/0 (127) 20:28:15.777705 enp4s0 Out IP 172.31.48.127.40721 > 172.31.48.254.53: 22744+ [1au] A? 3f9917dadb55.gw.mujsrv.org. (53) 20:28:15.777813 enp4s0 Out IP 172.31.48.127.57177 > 172.31.48.254.53: 3045+ [1au] AAAA? 3f9917dadb55.gw.mujsrv.org. (53) 20:28:15.817539 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.57177: 3045 NXDomain 0/1/1 (138) 20:28:15.817593 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.40721: 22744 NXDomain 0/1/1 (138) 20:28:15.817716 enp4s0 Out IP 172.31.48.127.57177 > 172.31.48.254.53: 3045+ AAAA? 3f9917dadb55.gw.mujsrv.org. (42) 20:28:15.817797 enp4s0 Out IP 172.31.48.127.40721 > 172.31.48.254.53: 22744+ A? 3f9917dadb55.gw.mujsrv.org. (42) 20:28:15.817997 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.57177: 3045 NXDomain 0/1/0 (127) 20:28:15.818074 enp4s0 In IP 172.31.48.254.53 > 172.31.48.127.40721: 22744 NXDomain 0/1/0 (127) ....
# tail -f /var/log/messages Apr 16 20:27:55 pc-jana nm-openvpn[786758]: RESOLVE: Cannot resolve host address: 7cf36e0b3a88.gw.mujsrv.org:1194 (Name or service not known) Apr 16 20:27:55 pc-jana nm-openvpn[786758]: RESOLVE: Cannot resolve host address: bd30780f6ca9.gw.mujsrv.org:1194 (Name or service not known) Apr 16 20:27:55 pc-jana nm-openvpn[786758]: Could not determine IPv4/IPv6 protocol Apr 16 20:27:55 pc-jana nm-openvpn[786758]: SIGUSR1[soft,init_instance] received, process restarting Apr 16 20:28:15 pc-jana nm-openvpn[786758]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Apr 16 20:28:15 pc-jana nm-openvpn[786758]: RESOLVE: Cannot resolve host address: 041d1d870348.gw.mujsrv.org:1194 (Name or service not known) Apr 16 20:28:15 pc-jana nm-openvpn[786758]: RESOLVE: Cannot resolve host address: 3f9917dadb55.gw.mujsrv.org:1194 (Name or service not known) Apr 16 20:28:15 pc-jana nm-openvpn[786758]: Could not determine IPv4/IPv6 protocol Apr 16 20:28:15 pc-jana nm-openvpn[786758]: SIGUSR1[soft,init_instance] received, process restarting Apr 16 20:28:24 pc-jana nm-openvpn[786758]: SIGTERM[hard,init_instance] received, process exiting ...
From above, NM tries DNS result not for 'gw.mujsrv.org' host, but for some insane 7cf36e0b3a88.gw.mujsrv.org / bd30780f6ca9.gw.mujsrv.org / 041d1d870348.gw.mujsrv.org / 3f9917dadb55.gw.mujsrv.org /...
Can anyone see where the problem might be?
And one more, perhaps not a very important little thing: is it possible to tell the NM to do only IPv4 resolution of the vpn server name (it does not have an IPv6 address)? --- Thanks in advance, Franta Hanzlik
On 4/16/23 12:16, Franta Hanzlík via users wrote:
I'm trying to configure OpenVPN connection in Fedora 37 NetworkManager. The configuration was created by importing the .ovpn file and subsequent its result correction. But connection is not working, and it seems it is because MetwokManage/nm-openvpn prepend OpenVPN server name with random string - which, of course, isn't resolvable to IP (v4) address.
My configuration file is: # cat /etc/NetworkManager/system-connections/lada.nmconnection [connection] id=mojevpn uuid=523155d8-ce42-499f-9b65-371733cd420c type=vpn autoconnect=false
[vpn] remote-random-hostname=yes
Maybe because of this?
On Sun, 16 Apr 2023 13:02:03 -0700 Samuel Sieb samuel@sieb.net wrote:
On 4/16/23 12:16, Franta Hanzlík via users wrote:
I'm trying to configure OpenVPN connection in Fedora 37 NetworkManager. The configuration was created by importing the .ovpn file and subsequent its result correction. But connection is not working, and it seems it is because MetwokManage/nm-openvpn prepend OpenVPN server name with random string - which, of course, isn't resolvable to IP (v4) address.
My configuration file is: # cat /etc/NetworkManager/system-connections/lada.nmconnection [connection] id=mojevpn uuid=523155d8-ce42-499f-9b65-371733cd420c type=vpn autoconnect=false
[vpn] remote-random-hostname=yes
Maybe because of this?
Hi Samuel, thanks to reply!
You are right, there was problem.
And I saw this option, but I messed up this "remote-random-hostname" (in nm-connection-editor checkbox with notation "Prefix remote DNS name with random string" and context help bubble "Adds a random string to remote DNS name to awoid DNS caching. config: remote-random-hostname ")
with previously mentioned option "Randomize remote hosts" and help bubble "Randomize the order of gateways list (remote) as kind of basic load-balancing measure. config: remote-random " - and because I have only one host, I assumed there could be no problem.
And I also change this option to "no" - but editing config file with normal text editor (not nm-connection-editor) - which was also wrong (connection are perhaps cached, and 'external' editing will not load the configuration ;)
But - somehow I don't understand - this wonderful feature (hostname randomizing == disabling its resoulution/usage) that will cause the connection to not work - does it have any real use? Has anyone gone crazy? Or am I crazy? --- Thanks, Franta Hanzlik
On 4/16/23 14:37, Franta Hanzlík wrote:
And I also change this option to "no" - but editing config file with normal text editor (not nm-connection-editor) - which was also wrong (connection are perhaps cached, and 'external' editing will not load the configuration ;)
If you edit it manually, you need to use something (like nmcli) to tell NetworkManager to reload the connection information.
But - somehow I don't understand - this wonderful feature (hostname randomizing == disabling its resoulution/usage) that will cause the connection to not work - does it have any real use? Has anyone gone crazy? Or am I crazy?
It's an option that I can only imagine would be used in very rare cases. That option will break connecting for almost everyone.
On Sun, 16 Apr 2023 16:46:31 -0700 Samuel Sieb samuel@sieb.net wrote:
On 4/16/23 14:37, Franta Hanzlík wrote:
And I also change this option to "no" - but editing config file with normal text editor (not nm-connection-editor) - which was also wrong (connection are perhaps cached, and 'external' editing will not load the configuration ;)
If you edit it manually, you need to use something (like nmcli) to tell NetworkManager to reload the connection information.
But - somehow I don't understand - this wonderful feature (hostname randomizing == disabling its resoulution/usage) that will cause the connection to not work - does it have any real use? Has anyone gone crazy? Or am I crazy?
It's an option that I can only imagine would be used in very rare cases. That option will break connecting for almost everyone.
Hm, for example, this case of stealing my time and yours. I hope such a case does not happen too often. Such an option should be accessible only to extra gurus ;) --- Anyway, thanks again for yours help! Franta Hanzlik
Franta Hanzlík:
But - somehow I don't understand - this wonderful feature (hostname randomizing == disabling its resoulution/usage) that will cause the connection to not work - does it have any real use? Has anyone gone crazy? Or am I crazy?
Samuel Sieb:
It's an option that I can only imagine would be used in very rare cases. That option will break connecting for almost everyone.
I see networking parameter randomisation in other things, too (like mobile phones), and really can't see it doing anything but cause you problems.
Every time your connection drops (and it will), you may have to reauthenticate to reconnect (something usually does reauthenticate, and you may have to manually do something, too). No anonymising happening then. Even if your connection seems different, something else (like your browser) re-identifies you.
If you *really* need to be anonymous, like you're a whistleblower, or your government murders their citizens, don't use your phone.
On Mon, 17 Apr 2023 13:13:27 +0930 Tim via users users@lists.fedoraproject.org wrote:
Franta Hanzlík:
But - somehow I don't understand - this wonderful feature (hostname randomizing == disabling its resoulution/usage) that will cause the connection to not work - does it have any real use? Has anyone gone crazy? Or am I crazy?
Samuel Sieb:
It's an option that I can only imagine would be used in very rare cases. That option will break connecting for almost everyone.
I see networking parameter randomisation in other things, too (like mobile phones), and really can't see it doing anything but cause you problems.
Every time your connection drops (and it will), you may have to reauthenticate to reconnect (something usually does reauthenticate, and you may have to manually do something, too). No anonymising happening then. Even if your connection seems different, something else (like your browser) re-identifies you.
If you *really* need to be anonymous, like you're a whistleblower, or your government murders their citizens, don't use your phone.
--
You are probably writing about the anonymization of the client - which is a case that still has some kind of substantiation. But in this case the connection specifies the target VPN server somehow (I called it gw.mujsrv.org), but the NM OpenVPN client tries to connect to 1a9107897c24.gw.mujsrv.org, 3abc1fd99dff.gw.mujsrv.org, 85f0005caa82.gw.mujsrv.org, f6046c7831be.gw.mujsrv.org, ... - which, of course, isn't DNS resolvable and thus the connection cannot be established at all. And I don't understand why it does that ;) --- Franta Hanzlik
On 4/16/23 21:40, Franta Hanzlík via users wrote:
You are probably writing about the anonymization of the client - which is a case that still has some kind of substantiation. But in this case the connection specifies the target VPN server somehow (I called it gw.mujsrv.org), but the NM OpenVPN client tries to connect to 1a9107897c24.gw.mujsrv.org, 3abc1fd99dff.gw.mujsrv.org, 85f0005caa82.gw.mujsrv.org, f6046c7831be.gw.mujsrv.org, ... - which, of course, isn't DNS resolvable and thus the connection cannot be established at all. And I don't understand why it does that ;)
The only situation I can see this being useful is if the vpn server has a dynamic address and a wildcard domain, so that you can force a DNS lookup avoiding any cached values. But that seems like a very unlikely situation.
On Mon, 2023-04-17 at 06:40 +0200, Franta Hanzlík via users wrote:
But in this case the connection specifies the target VPN server somehow (I called it gw.mujsrv.org), but the NM OpenVPN client tries to connect to 1a9107897c24.gw.mujsrv.org, 3abc1fd99dff.gw.mujsrv.org, 85f0005caa82.gw.mujsrv.org, f6046c7831be.gw.mujsrv.org, ... - which, of course, isn't DNS resolvable and thus the connection cannot be established at all.
For that kind of thing (I'm assuming some kind of load balancing, so people don't always use the same server), it being resolveable would have to be an issue that *their* end would have to solve.
By your example, their DNS server for gw.mujsrv.org would either know what to do with the hashed subdomain, or simply ignore it and return a random IP for a particular host. Or, perhaps it works like virtual webserving:
With webserving, that sort of thing would be all subdomains for that domain have the same IP, and different virtual webserver respond to different subdomains.
But looking at this as an outsider, all I can see is that for it work, all the addresses would have to resolve, and *they'd* have to be the one managing that.
If I try "dig gw.mujsrv.org" there is no results returned. Perhaps they have a fault at the moment, or is that a faked example?
-
Franta Hanzlík -
Samuel Sieb -
Tim