Howdy ! I am referring to the last protonvpn bug, which i can not find anymore - how do i browse my issues in here ? ) --> Bugs can be merged if reasonable ____________________ The normal way to install proton gives back a 404 : Example : # dnf install protonvpn-cli ProtonVPN Fedora Stable repository 725 B/s | 153 B 00:00 Errors during downloading metadata for repository 'protonvpn-fedora-stable': - Status code: 404 for https://repo.protonvpn.com/fedora-9-stable/repodata/repomd.xml (IP: 172.67.70.114) Error: Failed to download metadata for repo 'protonvpn-fedora-stable': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried ____________ Proton states : " The reason for this is that our repository is configured such as .../fedora-{VERSION}-stable/repodata... where {VERSION} is automatically changed to the version of your distribution. This works if you are running a supported Fedora version, as it would become fedora-40-stable and so on, but since you are running Mageia 9, the version number 9 is used, but Fedora 9 is not supported by us, and therefore such a repository does not exist. Unfortunately, there is not much to do in this case, as Mageia is not supported by us, we are not able to proceed further with the official applications and you will have to rely on a manual OpenVPN connection instead. " Therefore - and by the manual https://protonvpn.com/support/linux-openvpn/#preparation - openresolv is needed. I have tried just so ( resolvconf installed ), but shuts down all internet, when openvpn **** is issued.
The page you cite says: "2. Install openresolv You need openresolv (an open-source implementation of resolvconf) to properly configure DNS and prevent DNS leaks." OK, we do not have openresolv. Is our resolvconf really equivalent? Is it worth you raising a 'new package request' for openresolv? That would be a safer trial. For an eventual packager, this looks a good URL: https://github.com/NetworkConfiguration/openresolv Did you try the Fedora openresolv RPM whose URL you give? Often Fedora RPMs work on Mageia. We obviously need more information than you gave ("shuts down all internet, when openvpn **** is issued" is inadequate). Terminal output? End of system journal? CC'ing DaveH who is more savvy about this sort of thing, network information to look at.
CC: (none) => davidwhodgins, lewyssmithURL: (none) => https://rpmfind.net/linux/RPM/fedora/40/x86_64/o/openresolv-3.13.2-4.fc40.noarch.htmlSummary: Normal proton does not go - openvpn wants it => openvpn kills Internet when used with resolvconf; it really wants openresolv to work with ProtonvpnSource RPM: https://rpmfind.net/linux/RPM/fedora/40/x86_64/o/openresolv-3.13.2-4.fc40.noarch.html => openvpn-2.5.9-1.mga9.src.rpm
I will try the Fedora rpm, but OK, i will try and get to the packager and ask kindly. I have tried all versions, all failed or shut the internet. Here is an example output. # openvpn us-free-345051.protonvpn.udp.ovpn 2024-05-23 13:55:48 OpenVPN 2.5.9 x86_64-mageia-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 21 2023 2024-05-23 13:55:48 library versions: OpenSSL 3.0.13 30 Jan 2024, LZO 2.10 Enter Auth Username: ****************** Enter Auth Password: ******************* 2024-05-23 13:56:41 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2024-05-23 13:56:41 TCP/UDP: Preserving recently used remote address: [AF_INET]14xxxxxxxxxxxxxx 2024-05-23 13:56:41 UDP link local: (not bound) 2024-05-23 13:56:41 UDP link remote: [AF_INET]14xxxxxxxxxxxxxxx 2024-05-23 13:56:41 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 2024-05-23 13:56:42 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1549', remote='link-mtu 1541' 2024-05-23 13:56:42 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA1' 2024-05-23 13:56:42 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128' 2024-05-23 13:56:42 [node-us-180.protonvpn.net] Peer Connection Initiated with [AF_INET]14xxxxxxxx9 2024-05-23 13:56:43 NOTE: setsockopt TCP_NODELAY=1 failed 2024-05-23 13:56:43 TUN/TAP device tun0 opened 2024-05-23 13:56:43 net_iface_mtu_set: mtu 1500 for tun0 2024-05-23 13:56:43 net_iface_up: set tun0 up 2024-05-23 13:56:43 net_addr_v4_add: 1xxxxxxxxx16 dev tun0 2024-05-23 13:56:43 /etc/openvpn/update-resolv-conf tun0 15xxxxxxxxxxxxxxx 255.255.0.0 init dhcp-option DNS 10.96.0.1 resolvconf: Error: Command not recognized Usage: resolvconf (-d IFACE|-a IFACE|-u|--enable-updates|--disable-updates|--updates-are-enabled) 2024-05-23 13:56:43 Initialization Sequence Completed ^C2024-05-23 13:58:52 event_wait : Interrupted system call (code=4) 2024-05-23 13:58:52 SIGTERM received, sending exit notification to peer 2024-05-23 13:58:53 net_addr_v4_del: 10xxxxxxx dev tun0 2024-05-23 13:58:53 /etc/openvpn/update-resolv-conf tun0 15xxxxxxxx 255.255.0.0 init 2024-05-23 13:58:53 SIGTERM[soft,exit-with-notification] received, process exiting
(In reply to Holger Mainz from comment #2) > I will try the Fedora rpm Certainly worth a try. Download it, and use urpmi to install the file. Copy the terminal output. If there are problems give up; and urpme (remove) it. >> Is it worth you raising a 'new package request' for openresolv? > i will try and get to the packager and ask kindly. This involves opening a 'new package request' bug; but not yet. We need to find out whether the use of resolvconf is problematic. > dhcp-option DNS 10.96.0.1 > resolvconf: Error: Command not recognized > Usage: resolvconf (-d IFACE|-a > IFACE|-u|--enable-updates|--disable-updates|--updates-are-enabled) Most of the output comment 2 looks normal except for this; but does it in fact matter? It is not clear exactly what command resolvconf is complaining about. I cannot see the exact command 'dhcp-option' anywhere; maybe that command was successful. There is a man page for 'dhcp-options' in pkg 'dhcp-common' (which requires other packages to function). The penultimate line of the journal extract is about openvpn: /etc/openvpn/update-resolv-conf tun0 15xxxxxxxx 255.255.0.0 init Ag @Dave: ping.
... Again, it is unclear whether that is what ended: SIGTERM[soft,exit-with-notification] received, process exiting
Seems, there is not much difference [root@localhost openvpn]# urpmi openresolv-3.13.2-4.fc40.noarch.rpm Warnung: openresolv-3.13.2-4.fc40.noarch.rpm: Header V4 RSA/SHA256 Signature, Schlüssel-ID a15b79cc: NOKEY Folgendes Paket hat eine inkorrekte Signatur: openresolv-3.13.2-4.fc40.noarch.rpm: Falsche Signatur (NOT OK (no key): openresolv-3.13.2-4.fc40.noarch.rpm: Header V4 RSA/SHA256 Signature, Schlüssel-ID a15b79cc: NOKEY) Wollen Sie die Installation fortsetzen? (j/N) j openresolv-3.13.2-4.fc40.noarch.rpm wird installiert Vorbereiten … ############################################################# 1/1: openresolv ############################################################# failed to link /usr/sbin/resolvconf -> /etc/alternatives/resolvconf: /usr/sbin/resolvconf exists and it is either not a symlink or --keep-foreign was set and link points outside /etc/alternatives openvpn us-free-345051.protonvpn.udp.ovpn 2024-05-26 21:03:02 OpenVPN 2.5.9 x86_64-mageia-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 21 2023 2024-05-26 21:03:02 library versions: OpenSSL 3.0.13 30 Jan 2024, LZO 2.10 Enter Auth Username: ++++++++++++++++++++ Enter Auth Password: ******************* 2024-05-26 21:03:34 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2024-05-26 21:03:34 TCP/UDP: Preserving recently used remote address: [AF_INET]146xxxxxxxxxxxx 2024-05-26 21:03:34 UDP link local: (not bound) 2024-05-26 21:03:34 UDP link remote: [AF_INET]146xxxxxxxxxxxx 2024-05-26 21:03:34 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this 2024-05-26 21:03:34 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1549', remote='link-mtu 1541' 2024-05-26 21:03:34 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA1' 2024-05-26 21:03:34 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128' 2024-05-26 21:03:34 [node-us-180.protonvpn.net] Peer Connection Initiated with [AF_INET]146xxxxxxxxxxxx 2024-05-26 21:03:36 NOTE: setsockopt TCP_NODELAY=1 failed 2024-05-26 21:03:36 ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1) 2024-05-26 21:03:36 Exiting due to fatal error
Then : # urpme openresolv-3.13.2-4.fc40.noarch.rpm says unknown pkg, while # rpm -i openresolv-3.13.2-4.fc40.noarch.rpm means , the pkg IS installed. I don´t get it. I have to start over
CC'ing Frank hoping he can add something. I do not know whether the complaint is about 'openvpn' or 'resolvconf'. Note that the install of the Fedora openresolv package in fact failed: > Folgendes Paket hat eine inkorrekte Signatur: > openresolv-3.13.2-4.fc40.noarch.rpm: Falsche Signatur (NOT OK (no key): > openresolv-3.13.2-4.fc40.noarch.rpm: Header V4 RSA/SHA256 > Signature, Schlüssel-ID a15b79cc: NOKEY) > [root@localhost openvpn]# urpmi openresolv-3.13.2-4.fc40.noarch.rpm > ############################################################# > 1/1: openresolv > ############################################################# > failed to link /usr/sbin/resolvconf -> /etc/alternatives/resolvconf: > /usr/sbin/resolvconf exists and it is either not a symlink or --keep-foreign > was set and link points outside /etc/alternatives but it was worth a try. (In reply to Holger Mainz from comment #6) > Then : # urpme openresolv-3.13.2-4.fc40.noarch.rpm says unknown pkg, while > # rpm -i openresolv-3.13.2-4.fc40.noarch.rpm means , the pkg IS installed. > I don´t get it. 'rpm -i' says it "gives package information"; it does not say whether it applies to installed packages. In fact, trying it here on both installed and not installed packages produces a similar error! The -q option says "Query installed package named ..., and trying where the package is installed, it returns the full package-id up to .mga9 ; if the package is not installed, it returns "package ... is not installed"
CC: (none) => sturm-fr
(In reply to Holger Mainz from comment #6) > Then : # urpme openresolv-3.13.2-4.fc40.noarch.rpm says unknown pkg, while > > # rpm -i openresolv-3.13.2-4.fc40.noarch.rpm means , the pkg IS installed. > > I don´t get it. I have to start over To uninstall a package you don't give the complete package name including the version and ".rpm"! Simply # urpme openresolv The way via the Fedora rpm seems a complete dead end. Better try to setup the connection via Networkmanger. If you are not already using Networkmanger, switch to it as described here: https://wiki.mageia.org/en/Switching_to_networkmanager Make sure networkmanager-openvpn is installed After you have sucessfully switched to Networkmanger, simply import the openVPN configuration file. https://protonvpn.com/support/linux-openvpn/#preparation https://protonvpn.com/support/linux-openvpn/#NetworkManager
Allrighty. The proton guys told me, to try openvpn, but we do it our way now.
Thank you sturmvogel for your learned advice.
The Protons recommend, installing the app ( which is not the topic here ), and on my journey through the vpns, i came across the networkmanager several times They say On Fedora, enter: sudo dnf -y install NetworkManager-openvpn NetworkManager-openvpn-gnome On my machine networkmanager-1.40.18-2.mga9.x86_64 is installed, but NetworkManager-openvpn-gnome is nowhere to be found. urpmiing NetworkManager-openvpn-gnome-1.11.0-1.fc41.x86_64.rpm fails due to deps. However, there are some gnome net thing plug ins in the repos, but i wait for a round instead of just clicking them. Also: When i switch to the new "NetworkManager" and it don´t work, can it be undone - with normal knowledge and tools ?
(In reply to Holger Mainz from comment #11) > On Fedora, enter: > sudo dnf -y install NetworkManager-openvpn NetworkManager-openvpn-gnome > On my machine networkmanager-1.40.18-2.mga9.x86_64 is installed, but > NetworkManager-openvpn-gnome is nowhere to be found. Not surprising. sturmvogel said "Make sure networkmanager-openvpn is installed", not the gnome variant. We do not have that; but we do have, as he said, 'networkmanager-openvpn'. Try that.
OK, i have it. I have imported the tcp config file and use the pw selection. I have ticked the port and tcp at extras. The port was taken to the firewall as well. It starts, but also, shuts the internet down. Switched to a different port for no change. Any suggestions ?
Thank you for your efforts. If you have not already done so, please air this on the forum; some usr may have experience of this: https://forums.mageia.org/de/ or failing, https://forums.mageia.org/ Be sure to say exactly what packages you have ended up with, and refer to this bug. I do not want to forward it yet to the developers with the uncertainty about exactly what is not working.
OK, thank you. I will get it into the forum. I did nothing special here, Just installed the NetworkManager stuff switched to it following dr5000s instructions. It worked without interruption or restart.
-- case solved -- I will report to the proton lads
Please say exactly how!
Hello ! OK, i admit, it is partly solved. With the switch to Networkmanager, it was not a big deal. Just took the ovpn file to it and entered the credentials. But the firewall does not let me out. ( Interesting: When i hack in the port 53/udp, it is not saved, such as others got into the shorewall/iptables with the 3rd attempt ). Per advice from proton, i opened: TCP/443, for accessing our API UDP/53, for DNS resolution UDP/80, UDP/1194, UDP/4569, UDP/5060, UDP/51820, for the OpenVPN UDP protocol TCP/443, TCP/7770, TCP/8443, for the OpenVPN TCP protocol shorewall stop unblocks the connection and vpn starts working.
(In reply to Holger Mainz from comment #18) > ( Interesting: When i hack in the port > 53/udp, it is not saved, such as others got into the shorewall/iptables with > the 3rd attempt ). > TCP/443, for accessing our API > UDP/53, for DNS resolution > UDP/80, UDP/1194, UDP/4569, UDP/5060, UDP/51820, for the OpenVPN UDP > protocol > TCP/443, TCP/7770, TCP/8443, for the OpenVPN TCP protocol Please say exactly how you tried to configure the 53/udp port that was not applied. Was the failure just for this port, or the others that you cite? This would be a different problem. And are you saying that changes *are* applied after a certain number of attempts? > shorewall stop unblocks the connection and vpn starts working. We need to see the state of these ports after you opened them with shorewall. Are they shown open? Perhaps a screenshot. The fact that stopping shorewall allows things to work changes the direction of the bug. @Dave: please comment on this aspect.
(In reply to Lewis Smith from comment #19) > (In reply to Holger Mainz from comment #18) > > ( Interesting: When i hack in the port > > 53/udp, it is not saved, such as others got into the shorewall/iptables with > > the 3rd attempt ). > > TCP/443, for accessing our API > > UDP/53, for DNS resolution > > UDP/80, UDP/1194, UDP/4569, UDP/5060, UDP/51820, for the OpenVPN UDP > > protocol > > TCP/443, TCP/7770, TCP/8443, for the OpenVPN TCP protocol > Please say exactly how you tried to configure the 53/udp port that was not > applied. > Was the failure just for this port, or the others that you cite? This would > be a different problem. > And are you saying that changes *are* applied after a certain number of > attempts? ---> Hello ! No, the ports are all included after several attempts, except for 53/udp I did it the way via mcg-safety-set personal firewall-advanced and entered the port numbers in the given field. Is this file hoster ok for now ? https://ibb.co/TL7MMcv > > > shorewall stop unblocks the connection and vpn starts working. > We need to see the state of these ports after you opened them with > shorewall. Are they shown open? Perhaps a screenshot. > The fact that stopping shorewall allows things to work changes the direction > of the bug. ----> What would be a suitable command for this ?
Thank you for the screenshot. Two interesting things: * the 53/udp port is not shown; but you did say it was not applied. Do you ever succeed in opening it? * TCP/443 is NOT shown, but ? instead 433/tcp This picture is what I suggested. Will try to suggest commands later.
(In reply to Lewis Smith from comment #21) > Thank you for the screenshot. Two interesting things: > * the 53/udp port is not shown; but you did say it was not applied. Do you > ever succeed in opening it? ---> At the end, no. When checking during the next run, it is always gone. > * TCP/443 is NOT shown, but ? instead 433/tcp > > This picture is what I suggested. Will try to suggest commands later. ---> You are right, i missed the 443/tcp port here and there. That is a mind bug so to say.
Damn 53 and 433 just don´t stick :-/
So it looks like a real bug where certain ports are not remembered by Shorewall. Will come back.
At last have explored how to see what ports are open on a given host. I ended up with this command: $ sudo nmap -sS -sU localhost although on my box, where 6 ports are defined in the personal firewall to be open, and are shown in the second personal firewall screen list (like your screenshot referenced in comment 20) - they are not shown by that command! Perhaps there is no application wanting them. Try nmap anyway.
I agree. There certainly are some orphans in my list.
(In reply to Lewis Smith from comment #25) > At last have explored how to see what ports are open on a given host. I > ended up with this command: > $ sudo nmap -sS -sU localhost > although on my box, where 6 ports are defined in the personal firewall to be > open, and are shown in the second personal firewall screen list (like your > screenshot referenced in comment 20) - they are not shown by that command! > Perhaps there is no application wanting them. Try nmap anyway. Yeah, same here. The command shows ports, but not the ones, we have discussed here.
OK, i have started the old emule and it is running full throttle. The, now, used ports don´t show with the command; ( but they are still visible in the shorewall gui )
(In reply to Lewis Smith from comment #25) > At last have explored how to see what ports are open on a given host. I > ended up with this command: > $ sudo nmap -sS -sU localhost > although on my box, where 6 ports are defined in the personal firewall to be > open, and are shown in the second personal firewall screen list (like your > screenshot referenced in comment 20) - they are not shown by that command! > Perhaps there is no application wanting them. Try nmap anyway. That will not work. Accessing localhost does not go through the network, so it does not go through the firewall. The nmap command is just showing you what ports have something listening, not whether or not it will get past shorewall for things coming from other computers. Check (as root) /etc/shorewall/rules.drakx for ipv4 traffic and /etc/shorewall6/rules.drakx for ipv6 traffic, to see what drakfirewall and drakfirewall6 have set up shorewall to allow. Note that port 53 is shown as domain name system, rather then port number 53 by drakfirewall.
Also make sure the network interface being used for incoming traffic is listed in /etc/shorewall/interfaces and /etc/shorewall6/interfaces.
OK, commanding Dave´s commands show the ports. The MCC, on the other hand, does not. I just post the output since i can not comment on it: [root@localhost ]# cat /etc/shorewall/rules.drakx ACCEPT net fw udp 53,53,80,4569,5060,1194,4663,4670,51820 - ACCEPT net fw tcp 80,443,53,443,7770,8443,943,945,4660,51820,62582 - [root@localhost ]# cat /etc/shorewall6/rules.drakx ACCEPT net fw udp 53,53,80,1194,4569,5060,51820,4663,4670 - ACCEPT net fw tcp 80,443,53,22,443,7770,8443,943,945,4660 - [root@localhost ]# cat /etc/shorewall/interfaces # # Shorewall -- /etc/shorewall/interfaces # # For information about entries in this file, type "man shorewall-interfaces" # # The manpage is also online at # http://www.shorewall.net/manpages/shorewall-interfaces.html # ############################################################################### #ZONE INTERFACE OPTIONS net eno1 detect net proton0 detect net enp4s0 detect [root@localhost ]# cat /etc/shorewall6/interfaces # # Shorewall6 -- /etc/shorewall6/interfaces # # For information about entries in this file, type "man shorewall6-interfaces" # # The manpage is also online at # http://www.shorewall.net/manpages6/shorewall6-interfaces.html # ############################################################################### #ZONE INTERFACE OPTIONS net proton0 detect net enp4s0 detect net eno1 detect [root@localhost ]#
Thanks Dave for jumping in. I guessed I was on the wrong track. Holger's rules show that everything he allowed in the MCC interface is present. (In reply to Dave Hodgins from comment #29) > The nmap command is just showing you what ports have something listening, not > whether or not it will get past shorewall for things coming from other > computers. I suspected just this. But surely when the vpn is in use, the ports shown in comment 18 should show up as being listened to?
I think, i have found the problem. The iptables did not start. In the services box, iptables start with system launch is ticked, but does not. Clicking the start button does not change the entry. # service iptables start does the job, but the status in the services gui remains untouched. So, during the whole bug process, i had to restart shorewall, so, the services section did not come to my mind.
Shorewall is shown inactive as well, although it is running: # shorewall start Shorewall is already running
You have been valiant in exploring around this issue. I am unclear now whether you have working what you want (VPN | ProtonVPN ?) If so, please can you summarise the steps you took? There always seems to be another one... There were so many changes along the way, it is difficult to pin down what, in the end, mattered; and what did not. Again, this would be to help others trying the same thing. TIA
OK, i can prepare and wrap that up a bit
Status: NEW => NEEDINFOCC: (none) => marja11
Ahm. allright. So, the problem is/was, that protonvpn does not fully support the cli anymore. They instead go mainly for the app. The command line gave back an error with the normal launch. Getting wireguard started failed as well. Setting up the app failed, because the required packages did not match our repos. An attempt on openvpn did not go either, because we don´t sport the required openresolv package. The fedora package did not work, but the networkmanager is trucking with resolvconf and a hint by Sturmvogel set us on the right track https://wiki.mageia.org/en/Switching_to_networkmanager And that in fact worked out very well in the end, but still one problem remained. The firewall does not start with the system launch and ports are not set as they should. So, all in all, we have solved the problem splendid, the latter problem, however, remains still. I figure, it´ll provide food for our bug list or forum in the future. As a note. due to the firewall issue, i would not close out, that wireguard is a valid option to start protonvpn
(In reply to Holger Mainz from comment #37) > The firewall does not start with the system launch and ports are > not set as they should. > So, all in all, we have solved the problem splendid, the latter problem, > however, remains still. I figure, it´ll provide food for our bug list or > forum in the future. Thank you for your résumé. As for the firewall problem, please try that on a forum; and if necessary, raise a new bug just for that. I think we can close this. Does it wrrant an errata?
Status: NEEDINFO => RESOLVEDKeywords: (none) => FOR_ERRATA9Resolution: (none) => WORKSFORME
From my standpoint, all clear. If there is nothing to add from the board, we can close and i will report to the protons, that we are ready to sail.
As both openvpn and resolvconf is from our repo, I think this problem warrant an errata entry to help users. Please help me with the text! openvpn kills Internet when used with resolvconf...
CC: (none) => fri
Added to https://wiki.mageia.org/en/Mageia_9_Errata#Networking
Keywords: FOR_ERRATA9 => IN_ERRATA9