Allow dual-stack entry layer (IPv4 and IPv6), document *.airdns.org

[ss11 15]

The service is amazing, it has so many configurable options, for me its a piece of art and I hope all the backbone scripts and configs are safely kept.

In Config Generator -> Advanced Mode, when you select entry layer you can only select IPv4 or IPv6. So far so good, but nowadays there are plenty plenty of dual-stacked users, wouldn't it make sense to also have a third button, "Both" that will:
a) try in order first IPv6 if available, if not fail back to IPv4 (easily achieved with two `remote` config lines and no `remote random` so they are tried in order. We first try IPv6.

b) this can be manually done by any users, easily, but I did not see documentation for our *airdns.org hostname blueprint. example. nl.all.ipv6.vpn.airdns.org does not resolve to any valid IPv6 addresses. I see the *.airdns.org is configured in a sane logic way, as in nl3.vpn for example IP3 entry, and so on, but its not as clear for IPv6. A web page explaining it would be neat, I could do it if I knew the logic. Or is there any reason to keep this information private?

[OpenSourcerer 1359]

14 minutes ago, ss11 said:

a) try in order first IPv6 if available, if not fail back to IPv4 (easily achieved with two `remote` config lines and no `remote random` so they are tried in order. We first try IPv6.

Your suggestion does not work if v6 is disabled.

$ sudo openvpn AirVPN_DE-Munich_Mesarthim_UDP-443-Entry3.ovpn
2022-12-03 11:48:58 OpenVPN 2.5.8 [git:makepkg/0357ceb877687faa+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov  1 2022
2022-12-03 11:48:58 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
2022-12-03 11:48:58 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-12-03 11:48:58 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-12-03 11:48:58 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-12-03 11:48:58 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-12-03 11:48:58 TCP/UDP: Preserving recently used remote address: [AF_INET6]2a02:c205:0:1031:c1d7:aa8c:4a26:1d03:443
2022-12-03 11:48:58 Socket Buffers: R=[212992->425984] S=[212992->425984]
2022-12-03 11:48:58 UDPv6 link local: (not bound)
2022-12-03 11:48:58 UDPv6 link remote: [AF_INET6]2a02:c205:0:1031:c1d7:aa8c:4a26:1d03:443
2022-12-03 11:48:58 Network unreachable, restarting
2022-12-03 11:48:58 SIGUSR1[soft,network-unreachable] received, process restarting
2022-12-03 11:48:58 Restart pause, 5 second(s)
2022-12-03 11:49:03 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-12-03 11:49:03 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-12-03 11:49:03 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-12-03 11:49:03 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-12-03 11:49:03 RESOLVE: Cannot resolve host address: 178.238.229.56:443 (Address family for hostname not supported)
2022-12-03 11:49:03 RESOLVE: Cannot resolve host address: 178.238.229.56:443 (Address family for hostname not supported)
2022-12-03 11:49:03 Could not determine IPv4/IPv6 protocol
2022-12-03 11:49:03 SIGUSR1[soft,init_instance] received, process restarting
2022-12-03 11:49:03 Restart pause, 5 second(s)
2022-12-03 11:49:08 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-12-03 11:49:08 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-12-03 11:49:08 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2022-12-03 11:49:08 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2022-12-03 11:49:08 TCP/UDP: Preserving recently used remote address: [AF_INET6]2a02:c205:0:1031:c1d7:aa8c:4a26:1d03:443
2022-12-03 11:49:08 Socket Buffers: R=[212992->425984] S=[212992->425984]
2022-12-03 11:49:08 UDPv6 link local: (not bound)
2022-12-03 11:49:08 UDPv6 link remote: [AF_INET6]2a02:c205:0:1031:c1d7:aa8c:4a26:1d03:443
2022-12-03 11:49:08 Network unreachable, restarting
2022-12-03 11:49:08 SIGUSR1[soft,network-unreachable] received, process restarting
2022-12-03 11:49:08 Restart pause, 5 second(s)
^C2022-12-03 11:49:09 SIGINT[hard,init_instance] received, process exiting

Also be advised that v4 and v6 configs use slightly different config directives, e.g. UV_IPV6.
 

19 minutes ago, ss11 said:

b) this can be manually done by any users, easily, but I did not see documentation for our *airdns.org hostname blueprint. example. nl.all.ipv6.vpn.airdns.org does not resolve to any valid IPv6 addresses. I see the *.airdns.org is configured in a sane logic way, as in nl3.vpn for example IP3 entry, and so on, but its not as clear for IPv6. A web page explaining it would be neat, I could do it if I knew the logic. Or is there any reason to keep this information private?

I see you did not yet read the FAQ.

[ss11 15]

I thought `UV_IPV6` and `UV_IPV4` are meant to control the exit layer of addresses, if the client will exit with both, or just one of them.

Yes, sorry for not reading the FAQ - my mistake here.

As for OpenVPN failing - I a not sure why that is. I see you use a recent enough OpenVPN version (2.5.8). From OpenVPN community project:
 

Quote

On a git master (2.4-to-be) or 3.0 (OpenVPN Connect) client, you can just use "udp" as it will properly call getaddrinfo() and use whatever IP protocol the server and network supports, trying one family first and falling over to the other one, using the preference the OS signals (via getaddrinfo() result ordering).

This means that you tried an *.airdns.org hostname that only resolves to IPv6, and have IPv6 disabled on your machine.
I think there is a config option in OpenVPN client to skip the first `remote` if family does not exist and move to the next one, I'll re-read the manual and let you know. Edited ... by ss11

[ss11 15]

For example:

us.all.vpn.airdns.org (or us2|3|4|.all.vpn.airnds.org) is a hostname that properly resolves to the all the servers in the US, with their respected fist entry address, second, third or forth.
If you use this to connect as `remote`, and you are on OpenVPN 2.4 or later, you should first try IPv6 and if unavailable fail down to IPv4 transparently to the user.
We can make the `Both` IP layer entry REQUIRE at least OpenVPN 2.4 in this respect, but I think that is already quite old so should not be a problem.

This of course if `UV_IPV6` and `UV_IPV4` don't represent a problem, but I think those are only for the exit layers and do not care about the entry layers, which is the subject of this thread.

But in order to achieve this, we need also additional code for *airdns.org:

For example, to connect to the best server in Netherlands now we have:
nl.vpn.airdns.org -> IPv4 entry layer
nl.ipv6.vpn.airnds.org -> IPv6 entry layer

but nothing for dual stack. For dual stack we only have *ALL* servers in a given geo-loc: example: nl.all.vpn.airdns.org -> this resolves to all first IP entry of both IPv4 and IPv6. So this can be used.

So, we should have:
nl{2|3|4}.dualstack.airdns.org hostname that resolves to best server in given geo-loc to both their IPv4 and IPv6 fist, second, third or forth entry IP addresses.

(name is just what came to mind, we can choose something simpler than dualstack).

also every:
{server_name}.airservers.org -> currently maps to only IPv4. This should map to IPv6 as well (dual stack) and also be extended to:

{server_name}{2|3|4}.airservers.org - to map to either first IPv4/IPv6 entry, second, third or forth.

Faq page to be updated of course. I am willing to help with this of course if we implement it.

Edited ... by ss11
add airdns.org comments

[OpenSourcerer 1359]

Okay, you've made your point clear on how it could work in a technical sense. The question on why remains. Why is this better than to simply use IPv4 for environments where it's not clear whether v6 is supported? It's what I'd do.

The way I see it, it will cause the emergence of a FAQ. "Why does my connection never work on the first time but always on the second?"
Next question would be "This messes with my custom-automated-made-in-Bash script for connection monitoring, it makes my container/playbook/whatever terminate. Is there no way for OpenVPN to first determine which stack is available?" You'd answer "Then use v4/v6 only" – but what about the work invested into the Both feature?
Next, a common recommendation is to disable IPv6 because "yOu WiLl Be UnIqUe WiTh It, It'S bAd FoR pRiVaCy". So a v4-only settings works for the majority of "normal" users.

To be perfectly honest with you, I wouldn't bother with trying to support a temporary expedient such as dual-stack. Because it's what it is, a temporary expedient! One should move to v6 and ditch v4 instead, that's why we setup dual-stack, an OS-independent routing preference and Happy Eyeballs in the first place! But we're stuck, aren't we? Because only half the v4 internet is reachable on v6 in soon-to-be 2023, 25 years after the v6 RFC. And it's not just the "internet backwater" that doesn't support it. Reddit and Steampowered, just to name two big ones, don't support v6 at all.
I think a hard separation between v4 and v6 does thankfully not promote the idea that dual-stack is the norm of the future.

I do agree with a few things, though. mesarthim.airvpn.org should really resolve to the first v4 and v6. And the 1|2|3|4 should resolve to the respective IP, too.

[ss11 15]

On 12/4/2022 at 8:40 AM, OpenSourcerer said:

Okay, you've made your point clear on how it could work in a technical sense. The question on why remains. Why is this better than to simply use IPv4 for environments where it's not clear whether v6 is supported? It's what I'd do.

Don't understand the why the why question remains.

This is the industry standard and common practice among everywhere. I mean, this is how all Operating Systems work. First thy try an IPv6 address and if not possible the fail back to IPv4. It's the standard recommendations as per any RFC.
Which is why I think the why question is answered and does not need further input.

The better question is: why NOT to do it? Does it break anything?

I fully agree with your point of view, that we are stuck and at 25 years after the IPv6 RFC we are still slightly above 50% adoption on a world-wide level, but the problem with the current approach is, in our scenario most of AirVPN customers who don't know or don't care about these advanced settings only connect to AirVPN servers using IPv4 entry layer, and I think this is a penalty performance as well as not-so-good practice, because we prefer a legacy protocol on top of the new, better one. Why there's still so little IPv6 support on a global level when you think that the IPv6 RFC is 25 years old is another problem but outside the scope of this topic - not much we can do about it anyway, except optimize how we treat things in our garden.

There are many users that have IPv6 but don't know or care about it, and use AirVPN by connecting to IPv4 as entry layer.
 

On 12/4/2022 at 8:40 AM, OpenSourcerer said:

To be perfectly honest with you, I wouldn't bother with trying to support a temporary expedient such as dual-stack. Because it's what it is, a temporary expedient! One should move to v6 and ditch v4 instead, that's why we setup dual-stack, an OS-independent routing preference and Happy Eyeballs in the first place!

This is also true, I don't find anything wrong in this claim.
I am 50% - 50% with this approach versus the dual stack approach...
The only reason why I suggest to support dual stack is because it's a global standard and RFC recommendation practice in everything from web services, to ssh, to whatever. That's why I have one slight argument in pro of supporting dual stack entry mode, but not sure is enough - your approach also makes sense to me, so if this is the consensus among other AirVPN experts, its perfectly fine with me. I just wanted to express how it's technically easy and cheap for us to do it.

For example, I use only IPv6 for entry layer, because I know I have it and my devices support it and so on, but I have plenty of friends whom I recommended airvpn.org too and they use it with 'default' settings  (connect via IPv4 while having native IPv6 - but they don't know or care) so I think this is a waste. I think currently the general entry layer in AirVPN.org from all countries on all servers is so much more IPv4 versus IPv6.

For those users and many other current users that we have in the same situation, I thought the setup would be good - I mean it's just adding few more *.airdns.org records and a new config param "Both" that will include a `remote $dual_stack_dns_hostname` in the config file.

There is one more argument in PRO of adding dual-stack support.
When you connect to AirVPN if you select exit layer both you get an IPv6 ULA address (Unique Local Address) - this is not an address routable in the public internet.
If you also have IPv6 natively, you have a global public Ipv6 address (or IPv6 prefix) assigned, so that is normally *Preferred* on top of AirVPN's ULA Ipv6 address as per RFC recommendations and standards.
AirVPN fixes this by assigning a lower metric to the tun interface, so that the route is preferred, but in some scenarios this might not be enough. If you connect via IPv6, this problem goes away (at least in some operating systems).
 

On 12/4/2022 at 8:40 AM, OpenSourcerer said:

I do agree with a few things, though. mesarthim.airvpn.org should really resolve to the first v4 and v6. And the 1|2|3|4 should resolve to the respective IP, too.

Thanks for supporting this, indeed this is needed in order to maintain the same logic in *airdns.org map.

Pleasure to hear your well sustained and detailed opinion on this topic and thanks for your replies.

[ss11 15]

So, what are the feelings about this? Is any staff account monitoring the forums postings?
I managed to fix myself up by using the *all* DNS hostname, but the downside is that this doesn't always guarantee me it will select the best (least loaded ) server.
For me it is not a big problem because I have this mixed setup only on my mobile phone (the Mobile Network operator does not  support IPv6 so I use IPv4 entry layer while on my mobile network, but everywhere there is Wi-Fi there is also IPv6 so for those connections I wanted to connect via IPv6 entry layer).

[OpenSourcerer 1359]

If anything, the priority of implementing this is not very high. The general recommendation around here is disabling v6, anyway.
It also helps with troubleshooting sometimes because some problems simply go away when v6 is disabled, so a v4 default helps in support ticket reduction.

Please open a ticket for an answer from professional support; some things are relayed to relevant decision makers there.