remote_host_ipv6=n/a - error Operation not supported

[wintermute1912 6]

I use Ubuntu 16.04.5 with ipv6.disable=1 in my grub file. I have OpenVPN version 2.4 installed.

I generated ovpn config files for all TLS 1.2 primary servers (entry point 3) UDP 443 with the following options:

• IPv4 only
• Resolve hostnames
• Separate keys / certs

Then to connect I only ever run openvpn in terminal selecting one of the ovpn files pretty much at random but lately most of them generate the following and fail to connect. It looks as if they're trying to force an ipv6 connection?

I don't want to use ipv6 as it's harder to lock down and I make sure to select IPv4 ONLY in the config generator.

Wed Dec  4 04:36:47 2019 OpenVPN 2.4.8 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 31 2019
Wed Dec  4 04:36:47 2019 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
Wed Dec  4 04:36:47 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Dec  4 04:36:47 2019 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Dec  4 04:36:47 2019 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Dec  4 04:36:47 2019 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Dec  4 04:36:47 2019 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Dec  4 04:36:47 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]184.75.223.213:443
Wed Dec  4 04:36:47 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed Dec  4 04:36:47 2019 UDP link local: (not bound)
Wed Dec  4 04:36:47 2019 UDP link remote: [AF_INET]184.75.223.213:443
Wed Dec  4 04:36:47 2019 TLS: Initial packet from [AF_INET]184.75.223.213:443, sid=4dfd5b1f 47dea206
Wed Dec  4 04:36:47 2019 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
Wed Dec  4 04:36:47 2019 VERIFY KU OK
Wed Dec  4 04:36:47 2019 Validating certificate extended key usage
Wed Dec  4 04:36:47 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Dec  4 04:36:47 2019 VERIFY EKU OK
Wed Dec  4 04:36:47 2019 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Agena, emailAddress=info@airvpn.org
Wed Dec  4 04:36:48 2019 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Wed Dec  4 04:36:48 2019 [Agena] Peer Connection Initiated with [AF_INET]184.75.223.213:443
Wed Dec  4 04:36:49 2019 SENT CONTROL [Agena]: 'PUSH_REQUEST' (status=1)
Wed Dec  4 04:36:49 2019 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.4.210.1,dhcp-option DNS6 fde6:7a:7d20:d2::1,tun-ipv6,route-gateway 10.4.210.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:d2::1073/64 fde6:7a:7d20:d2::1,ifconfig 10.4.210.117 255.255.255.0,peer-id 2,cipher AES-256-GCM'
Wed Dec  4 04:36:49 2019 OPTIONS IMPORT: timers and/or timeouts modified
Wed Dec  4 04:36:49 2019 OPTIONS IMPORT: compression parms modified
Wed Dec  4 04:36:49 2019 OPTIONS IMPORT: --ifconfig/up options modified
Wed Dec  4 04:36:49 2019 OPTIONS IMPORT: route options modified
Wed Dec  4 04:36:49 2019 OPTIONS IMPORT: route-related options modified
Wed Dec  4 04:36:49 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Wed Dec  4 04:36:49 2019 OPTIONS IMPORT: peer-id set
Wed Dec  4 04:36:49 2019 OPTIONS IMPORT: adjusting link_mtu to 1625
Wed Dec  4 04:36:49 2019 OPTIONS IMPORT: data channel crypto options modified
Wed Dec  4 04:36:49 2019 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Dec  4 04:36:49 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Dec  4 04:36:49 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Dec  4 04:36:49 2019 ROUTE_GATEWAY 10.1.1.1/255.255.255.0 IFACE=eno1 HWADDR=2c:27:d7:1e:2f:56
Wed Dec  4 04:36:49 2019 GDG6: remote_host_ipv6=n/a
Wed Dec  4 04:36:49 2019 GDG6: NLMSG_ERROR: error Operation not supported

Wed Dec  4 04:36:49 2019 ROUTE6: default_gateway=UNDEF
Wed Dec  4 04:36:49 2019 TUN/TAP device tun0 opened
Wed Dec  4 04:36:49 2019 TUN/TAP TX queue length set to 100
Wed Dec  4 04:36:49 2019 /sbin/ip link set dev tun0 up mtu 1500
Wed Dec  4 04:36:49 2019 /sbin/ip addr add dev tun0 10.4.210.117/24 broadcast 10.4.210.255
Wed Dec  4 04:36:49 2019 /sbin/ip -6 addr add fde6:7a:7d20:d2::1073/64 dev tun0
RTNETLINK answers: Operation not supported
Wed Dec  4 04:36:49 2019 Linux ip -6 addr add failed: external program exited with error status: 2
Wed Dec  4 04:36:49 2019 Exiting due to fatal error

[OpenSourcerer 1435]

Can you post your generated config?

[nexsteppe 24]

Rather than a problem in the openvpn config, I believe what's happening is that openvpn client is still trying to setup IPv6 routes for the tunnel device on a machine that has IPv6 disabled.  (I do think there are still valid reasons to disable IPv6, nowadays.)  And it's an annoying problem, because it seems like it doesn't happen all the time — or rather, that some Air servers will still ask the client to setup IPv6 routes even though they've not pushed UV_IPV6 to the environment using push-peer-info — so you'll connect perfectly with IPv4 only on some servers but not others with such a configuration.

On your (@wintermute1912's) side, I'm unsure what can be actually done short of adding these lines to your openvpn config and enduring a bit more terminal noise when connecting:

pull-filter ignore "ifconfig-ipv6 "
pull-filter ignore "route-ipv6 "

Maybe Air staff might have a better suggestion for what to do.

[wintermute1912 6]

On 12/4/2019 at 8:40 AM, giganerd said:

Can you post your generated config?

Here is an example of one that demonstrates the ipv6 problem. Everything after the line "auth SHA512" is added by me to be sure of no DNS leakage (which incidentally is also the reason I have ipv6 disabled) but that is not causing a problem as the same error occurs without it.

@hawkflights solution has promise though still some issues - see post below.

Also for what's it's worth I seem to only have this problem with the Canadian servers (so far). I generally use either CA or NL.

# --------------------------------------------------------
# Air VPN | https://airvpn.org | Friday 29th of November 2019 01:00:36 PM
# OpenVPN Client Configuration
# AirVPN_CA-Toronto-Ontario_Tejat_UDP-443-Entry3
# --------------------------------------------------------

client
dev tun
remote 184.75.221.197 443
resolv-retry infinite
nobind
persist-key
persist-tun
auth-nocache
route-delay 5
verb 3
explicit-exit-notify 5
ca "ca.crt"
cert "user.crt"
key "user.key"
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
proto udp
tls-crypt "tls-crypt.key"
auth SHA512

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
 

[wintermute1912 6]

On 12/4/2019 at 10:03 AM, hawkflights said:

Rather than a problem in the openvpn config, I believe what's happening is that openvpn client is still trying to setup IPv6 routes for the tunnel device on a machine that has IPv6 disabled.  (I do think there are still valid reasons to disable IPv6, nowadays.)  And it's an annoying problem, because it seems like it doesn't happen all the time — or rather, that some Air servers will still ask the client to setup IPv6 routes even though they've not pushed UV_IPV6 to the environment using push-peer-info — so you'll connect perfectly with IPv4 only on some servers but not others with such a configuration.

On your (@wintermute1912's) side, I'm unsure what can be actually done short of adding these lines to your openvpn config and enduring a bit more terminal noise when connecting:

pull-filter ignore "ifconfig-ipv6 "
pull-filter ignore "route-ipv6 "

Maybe Air staff might have a better suggestion for what to do.

Thanks @hawkflights that seemed initially to be effective. You're right I do get a little back chat from terminal:

Tue Dec 10 20:06:49 2019 WARNING: OpenVPN was configured to add an IPv6 route over tun0. However, no IPv6 has been configured for this interface, therefore the route installation may fail or may not work as expected.

but then after about a minute the connection spontaneously disconnects:

^CTue Dec 10 20:07:40 2019 event_wait : Interrupted system call (code=4)
Tue Dec 10 20:07:40 2019 SIGTERM received, sending exit notification to peer

I promise I am not pressing Ctrl-C in that window!


https://airvpn.org/profile/139863-hawkflights/

[nexsteppe 24]

1 hour ago, wintermute1912 said:

but then after about a minute the connection spontaneously disconnects:

^CTue Dec 10 20:07:40 2019 event_wait : Interrupted system call (code=4)
Tue Dec 10 20:07:40 2019 SIGTERM received, sending exit notification to peer

If you nix the "auth SHA512" line in your openvpn config (ie, so as to default to SHA1) and change the "tls-crypt" line to

tls-auth "tls-crypt.key" 1

does it still sigterm as you described?


 

[wintermute1912 6]

16 hours ago, hawkflights said:

 

Quote

If you nix the "auth SHA512" line in your openvpn config (ie, so as to default to SHA1) and change the "tls-crypt" line to

tls-auth "tls-crypt.key" 1

does it still sigterm as you described?

 

No it gets stuck instead and there's nothing in syslog or kern.log around those times either which is weird?

Dec 11 13:11:44 2019 OpenVPN 2.4.8 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Oct 31 2019
Wed Dec 11 13:11:44 2019 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
Wed Dec 11 13:11:44 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Dec 11 13:11:44 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Dec 11 13:11:44 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Dec 11 13:11:44 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]184.75.221.197:443
Wed Dec 11 13:11:44 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]
Wed Dec 11 13:11:44 2019 UDP link local: (not bound)
Wed Dec 11 13:11:44 2019 UDP link remote: [AF_INET]184.75.221.197:443

Just sits there after that.

[nexsteppe 24]

I must admit I'm not clear on what's actually happening tbh, but I might start by generating a new openvpn config for testing — make sure you toggle "advanced settings" so you can specifically prepare an IPv4-only config for your OS and openvpn version, and keep the keys bundled with the config to rule out other variables.  Test that config first, then add the "pull-filter" lines suggested earlier and test again.  If that doesn't do it, I might just take this directly to AirVPN support.  Sorry I can't be of more assistance!

[SurprisedItWorks 49]

Is this the server bug discussed in https://airvpn.org/forums/topic/45682-setting-up-tomato-to-connect-to-entry-domain-name/?tab=comments#comment-102620?  Apparently there are still some servers with the problem. Here's what's been working for me to get around it.  Note that the last line ignores the pushed routes, even the IPv4 ones, but that works for me because my setup sets up routes with a shell script and doesn't use the pushed route instructions.

  pull-filter ignore "dhcp-option DNS6 "
  pull-filter ignore "ifconfig-ipv6 "
  pull-filter ignore "redirect-gateway ipv6 " 

Edited ... by SurprisedItWorks
omission of something important

[wintermute1912 6]

Have not encountered this problem for weeks now. Fixed?