Failed to connect when IPv6 is disabled

[reback00]

Thanks for creating a FOSS tool for Hide.me vpn. Recently I found an issue that I thought I should address. It connects just fine when I connect with IPv6 enabled. But when I have ipv6.disable=1 added as kernel parameter (and as such the file /proc/sys/net/ipv6/conf/all/disable_ipv6 doesn't exist due to that option being set) it fails to connect with this message:

...
...
Link: [ERR] IPv6 RPDB rule addition failed, address family not supported by protocol
Main: [ERR] RPDB rules failed, address family not supported by protocol
Link: IPv4 DHCP VPN bypass RPDB rule removed
Link: IPv4 RPDB rule removed
Link: Interface vpn deactivated

I read somewhere it is a good security practice to disable IPv6. So I have it disabled on some machines. It would be great if it could connect without IPv6 available.

[tcohar]

It is a good security practice indeed when the VPN service you use does not support IPv6 or does not have some sort of IPv6 leak protection. Hide.me Linux CLI supports IPv6 and does have leak protection/killswitch built-in. Our kill-switch/leak protection will drop all traffic, IPv4 and IPv6 included, on any sort of a sudden disconnect. On the other hand, when you're connected, the RPDB rules make sure your IPv6 does not leak. It's just about the same situation as with IPv4. So, we strongly suggest you keep IPv6 on, at least as long as you use our service. There's no risk of leaks or anything like that, yet you gain IPv6 connectivity and help increase the IPv6 adoption rate. Having said that, I can imagine a use case where customers of ours might wish to use only one IP protocol ( IPv4 or IPv6 ) with our network. We will make that possible by adding additional options to the client. This will solve your issue too. We will publish an update in the next few days which addresses this enhancement.

[alturismo]

Hi, i also have the same situation here, server is builded for ip v4 only, i try to create myself a vpn proxy docker with this hide.me binary (currently using ovpn).

returning now

root@b15faedf8729:/config/hide# ./hide.me connect de.hide.me Link: Generated a new wireguard private key Link: Wireguard interface vpn activated Link: Wireguard device vpn configured Link: IPv4 DHCP VPN bypass RPDB rule added Link: IPv4 RPDB rule for non mark 55555 marked traffic added Link: [ERR] IPv6 RPDB rule addition failed, address family not supported by protocol Main: [ERR] RPDB rules failed, address family not supported by protocol Link: IPv4 DHCP VPN bypass RPDB rule removed Link: IPv4 RPDB rule removed Link: Interface vpn deactivated

would be nice to get an update to choose ipvx only, thanks ahead

[tcohar]

Hi, we pushed an update ( 0.9.1 ) which addresses this issue. You may use hide.me CLI in the following manner in order to disable IPv6 addresses, rules and routes:

hide.me -4 connect server

Option -4 will make hide.me CLI work on hosts which have their IPv6 stack disabled. It is safe to use that option on such hosts. However, on dual-stack hosts -4 is dangerous and should not be used because IPv6 leaks may happen

[alturismo]

thanks you very much, quick test failed here now due

Link: [ERR] Rename of /etc/resolv.conf to /etc/resolv.conf.backup.hide.me failed, device or resource busy

---

./hide.client.linux -4 -u username -P password-s 192.168.1.0/24 connect de.hideservers.net & ~/.xteve/_hideme # Link: Generated a new wireguard private key Link: Wireguard interface vpn activated Link: Wireguard device vpn configured Link: Split tunnel rule for 192.168.1.0/24 added Link: IPv4 DHCP VPN bypass RPDB rule added Link: IPv4 RPDB rule for non mark 55555 marked traffic added Link: Loopback route 0.0.0.0/0 dev lo mtu 0 table 55555 added Name: Resolved de.hideservers.net to 91.199.118.74 Main: Connecting to 91.199.118.74:432 Pins: Hide.Me Server CA #1 pin OK Pins: Hide.Me Root CA pin OK Main: Connected to 91.199.118.74:432 Rest: Remote UDP endpoint is 91.199.118.74:432 Rest: Keepalive is 20 seconds Rest: Assigned IPs are 10.129.205.140, fd00:6968:6564:e6:c11e:e727:7c05:a5cc Rest: Gateway IPs are 10.129.204.1, fd00:6968:6564:e6::1 Rest: DNS servers are 10.129.204.1, fd00:6968:6564:e6::1 Link: Interface vpn MTU set to 1392 Link: Peer 91.199.118.74:432 added Link: Address 10.129.205.140 added to interface vpn Link: Gateway route 10.129.204.1/32 dev vpn mtu 1392 table 55555 added Link: Route 0.0.0.0/1 via 10.129.204.1 dev vpn mtu 1392 table 55555 added Link: Route 128.0.0.0/1 via 10.129.204.1 dev vpn mtu 1392 table 55555 added Link: [ERR] Rename of /etc/resolv.conf to /etc/resolv.conf.backup.hide.me failed, device or resource busy Link: Received 0 bytes, transmitted 148 bytes Link: Route 0.0.0.0/1 via 10.129.204.1 dev vpn mtu 1392 table 55555 removed Link: Route 128.0.0.0/1 via 10.129.204.1 dev vpn mtu 1392 table 55555 removed Link: Gateway route 10.129.204.1/32 dev vpn mtu 1392 table 55555 removed Link: 10.129.205.140 removed from interface vpn Link: Peer 91.199.118.74:432 removed Link: Down Main: [ERR] Link up failed, rename /etc/resolv.conf /etc/resolv.conf.backup.hide.me: device or resource busy Main: [ERR] Connection setup/teardown failed, traffic blocked, waiting for a termination signal

after quick look, looks like its due mv resolv.conf ... which is inside the docker enviroment ...

may a way to disable and write manually the dns entries ?

[reback00]

Hi, we pushed an update ( 0.9.1 ) which addresses this issue. You may use hide.me CLI in the following manner in order to disable IPv6 addresses, rules and routes:

hide.me -4 connect server

Option -4 will make hide.me CLI work on hosts which have their IPv6 stack disabled. It is safe to use that option on such hosts. However, on dual-stack hosts -4 is dangerous and should not be used because IPv6 leaks may happen

This works as expected. Thanks a lot.

To make sure I don't use -4 by mistake I made a script to connect:

#!/bin/sh
# connect.sh - hide.me connect script
# Usage: Place the file on same dir as "hide.me" binary, make edits, like "server_name", then:
# chmod +x connect.sh; ./connect.sh or /path/to/connect.sh

# Hide.me server you connect to. Use your dashboard to find the name.
server_name='<enter your server name here>'
# Automatically handle IPv4 parameter
if [ ! -d /proc/sys/net/ipv6 ]; then
  ipv4_param=' -4 '
fi

# cd to where the script is so that the script can be ran from any other dir.
cd $(cd -P -- "$(dirname -- "$0")" && pwd -P)
# Connect to Hide.me. Add params if you need to. -k is for killswitch (optional but recommended).
sudo ./hide.me $ipv4_param connect $server_name -k

EDIT: added /path/to

[reback00]

@alturismo I think this is the way Docker was designed...

This is by design. /etc/resolv.conf is used by docker engine to handle service discovery. ... ... If you want to override/reconfigure some dns settings, use --dns parameters during container starting. See more details: Configure DNS in Docker

Seems to be not related to this project.

[alturismo]

sadly yes, i know i can write to my resolv conf, but wont help me due hide.me client wants to mv resolve.conf anyway ... and wont start ;)

so only way would be to tell hide.me client not to move and edit instead ... nvm for now, so i stay on ovpn for now as vpn proxy for my apps, i dont want to put everything behind the vpn due latency

[tcohar]

This is a valid enhancement proposal. We'll add an option to leave DNS settings alone, i.e. to skip resolv.conf handling. Also, an option to specify custom DNS servers would be nice as well. We'll add that one too :)

[reback00]

This is a valid enhancement proposal. We'll add an option to leave DNS settings alone, i.e. to skip resolv.conf handling. Also, an option to specify custom DNS servers would be nice as well. We'll add that one too :)

Also, how about adding warning messages about possible security risks of using such options? For example, when using -4 even when ipv6 is enabled, skipping resolv.conf change, adding custom dns etc. This way Hide.me stays less responsible if something happens due to using these options.

[reback00]

Closing this since IPv4 option is working now. Created a separate issue for the Docker error. @alturismo @tcohar