Jump to content
Not connected, Your IP: 3.93.74.227
Staff

IPv6 support and new smart features

Recommended Posts

Hello!

We're very glad to inform that full IPv6 support is being deployed to our VPN servers. The experimental phase ended during the first half of June and we can now reliably deploy IPv6 to any other VPN server, provided that it is in a datacenter with IPv6 infrastructure of course. This thread will be periodically updated to provide the list of VPN servers new generation setup (internally, we call this new setup "Gen 2").

 

FINAL UPDATE: as of September the 14th 2018, all AirVPN servers have been upgraded to 2nd generation software.

 

 

New smart features:

  • Standard protocols/ports with IPv6 support (*), updated OpenVPN server, better cipher negotiation. You can keep using AirVPN as usual, even if you have an old OpenVPN version, on entry-IP addresses 1 and 2 of each server.
  • Additional protocols/ports with IPv6 support (*), updated OpenVPN server, better cipher negotiation, 'tls-crypt' support (*), TLS 1.2 (*) forced on entry-IP addresses 3 and 4 of Gen 2 servers. The additional protocols/ports mentioned in this paragraph require OpenVPN 2.4 or higher versions

(*) OpenVPN 2.4 or higher version is required.

 

tls-crypt plays a role even against ISPs that throttle or block OpenVPN.

 

Something more about tls-crypt can be found here: https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

Search for "--tls-crypt keyfile"

 

 

Planning the future: internal load balancing between multiple OpenVPN daemons.

 

This is a feature which will let OpenVPN squeeze the maximum bandwidth on each server, because OpenVPN runs in a single thread of a single core. By balancing the load on multiple OpenVPN daemons with a reliable algorithm, we overcome significantly this OpenVPN limitation.

 

Such bandwidth would be mostly wasted without our load balancing method simply because there are no CPUs capable to process 10 Gbit/s AES-256 encryption/decryption on multiple flows to/from multiple channels (according to our empirical tests on the field, the load does not grow linearly with the growth of connected OpenVPN clients) with just one one core.

 

Our solution is important because it's a founding prerequisite toward servers connected to 10 Gbit/s lines, even if OpenVPN multicore / multi-threading support should not become available in the near future, not to mention that it can be useful even in different environments.

 

The internal load balancing is already active on all "Gen 2" servers.

 

Kind regards and datalove

AirVPN Staff

Share this post


Link to post

So, which servers are connected to 10Gbit/s lines?  :blink:

 

Hello!

 

None of our 10 Gbit/s lines are connected to a single server. We have 10 Gbit/s lines which are used to connect 10 servers. The fact that load balancing is being deployed is the founding step which prepares the chance to break the 980/990 Mbit/s (of AES encryption-decryption in a system with dozens of OpenVPN clients) limit on AES-NI supporting CPUs.

 

Kind regards

Share this post


Link to post
Guest
Just for prosperity, here's a list of servers that have been upgraded so far to 'Gen 2', when the upgrade took place, and how long it took.

 

15th June: 45/219 servers

19th June: 63/219 servers

21st June: 68/219 servers

 

Server list (name, date upgraded, upgrade duration).

 

 


Carinae Thu, 21 Jun 2018 09:57 4h 4m 20s

 

Cursa Thu, 21 Jun 2018 09:57 4h 4m 24s

 

Ogma Thu, 21 Jun 2018 09:57 4h 4m 30s

 

Salm Thu, 21 Jun 2018 09:56 4h 4m 35s

 

Angetenar Thu, 21 Jun 2018 09:56 4h 4m 43s


 


Persei Tue, 19 Jun 2018 14:28 19h 19m 13s

 

Adhara Tue, 19 Jun 2018 14:28 1d 0h 1m

 

Columba Tue, 19 Jun 2018 14:27 19h 19m 34s

 




Alcyone Tue, 19 Jun 2018 14:27 5h 22m 50s

 

Eridanus Tue, 19 Jun 2018 07:43 2h 45m 49s

 

Hydra Tue, 19 Jun 2018 07:43 2h 46m 4s

 

Alderamin Tue, 19 Jun 2018 07:43 2h 46m 4s

 

Kajam Tue, 19 Jun 2018 07:42 2h 46m 17s

 

Cephei Tue, 19 Jun 2018 07:42 2h 46m 22s

 

Betelgeuse Mon, 18 Jun 2018 10:12 4h 15m 42s

 

Subra Mon, 18 Jun 2018 10:12 1h 31m 34s

 

Diadema Mon, 18 Jun 2018 10:12 1h 34m 47s

 

Aludra Mon, 18 Jun 2018 10:12 1h 31m 45s

 

Gomeisa Mon, 18 Jun 2018 07:32 1h 19m 25s

 

Achird Mon, 18 Jun 2018 07:32 1h 19m 38s

 

Hydrus Mon, 18 Jun 2018 07:32 1h 20m 16s

 

Lepus Mon, 18 Jun 2018 07:32 1h 20m 18s

 

Alhena Mon, 18 Jun 2018 07:32 1h 20m 30s

 

Baiten     Fri, 15 Jun 2018 13:23  1h 15m 19s

 

Heze       Fri, 15 Jun 2018 08:57  3h 5m 50s

 

Mekbuda       Fri, 15 Jun 2018 08:57  3h 6m 5s

 

Turais       Fri, 15 Jun 2018 08:54  3h 8m 47s

 

Asterion     Fri, 15 Jun 2018 08:54  3h 8m 56s

 

Nash       Fri, 15 Jun 2018 08:54  3h 9m 0s

 

Pyxis    Wed, 13 Jun 2018 18:09  5m 20s

 

Pollux       Wed, 13 Jun 2018 18:09  5m 42s

 

Pleione       Wed, 13 Jun 2018 18:09  5m 4s

 

Perseus       Wed, 13 Jun 2018 18:02  5m 43s

 

Phact       Wed, 13 Jun 2018 18:02  6m 0s

 

Situla       Wed, 13 Jun 2018 18:02  6m 22s

 

Skat       Wed, 13 Jun 2018 18:02  14m 8s

 

Orion       Wed, 13 Jun 2018 17:55  7m 13s

 

Minkar       Wed, 13 Jun 2018 17:55  5m 44s

 

Mesarthim  Wed, 13 Jun 2018 17:55  6m 1s

 

Menkab       Wed, 13 Jun 2018 17:55  6m 3s

 

Kocab       Wed, 13 Jun 2018 17:47  5m 52s

 

Helvetios  Wed, 13 Jun 2018 17:47  5m 26s

 

Gianfar       Wed, 13 Jun 2018 17:47  6m 9s

 

Gacrux       Wed, 13 Jun 2018 17:46  5m 59s

 

Diphda  Wed, 13 Jun 2018 12:05  6m 12s

 

Cebalrai  Wed, 13 Jun 2018 12:04  6m 2s

 

Atria  Wed, 13 Jun 2018 12:04  6m 16s

 

Almach  Wed, 13 Jun 2018 12:04  6m 32s

 

Alkaid  Wed, 13 Jun 2018 12:04  6m 30s

 

Errai  Mon, 11 Jun 2018 17:14  5m 25s

 

Equuleus  Mon, 11 Jun 2018 17:14  5m 30s

 

Chara  Mon, 11 Jun 2018 17:14  5m 33s

 

Volans  Mon, 11 Jun 2018 17:03  4m 1s

 

Taurus  Mon, 11 Jun 2018 17:03  4m 15s

 

Spica  Mon, 11 Jun 2018 17:03  4m 14s

 

Rana  Mon, 11 Jun 2018 16:53  6m 21s

 

Chamaeleon  Mon, 11 Jun 2018 16:53  39m 47s

 

Orion  Mon, 11 Jun 2018 14:39  22m 57s

 

Sabik  Mon, 11 Jun 2018 14:39  15m 28s

 

Helvetios  Mon, 11 Jun 2018 14:39  23m 16s

 

Almach       Mon, 11 Jun 2018 14:39  15m 49s

 

Gianfar       Mon, 11 Jun 2018 14:30  6m 57s

 

Gacrux       Mon, 11 Jun 2018 14:29  5m 40s

 

Errai       Mon, 11 Jun 2018 14:29  6m 7s

 

Minkar       Mon, 11 Jun 2018 12:21  6m 21s

 

Mesarthim   Mon, 11 Jun 2018 12:21  6m 53s

 

Chara       Mon, 11 Jun 2018 12:21  6m 58s

 

Merope (no info - likely an original 'experimental' server)


Share this post


Link to post

For both my clients I see in your online status that I am assigned IPv6 addresses

 

But none of them use the IPv6 from you, both clients use the IPv6 from the ISP

 

The openvpn.log file does not show you "pushing" the IPv6 address

 

Do I need to change my ovpn files?

Share this post


Link to post

For both my clients I see in your online status that I am assigned IPv6 addresses

 

But none of them use the IPv6 from you, both clients use the IPv6 from the ISP

 

The openvpn.log file does not show you "pushing" the IPv6 address

 

Do I need to change my ovpn files?

 

Hello!

 

Yes, you need that. In the Configuration Generator please tick "Advanced Mode", select OpenVPN version ">= 2.4" and select "IPv4 & IPv6 (connect with IPv6)".

 

Kind regards

Share this post


Link to post

Hello Staff,

I have a quick question about the following and how it may equate to Eddie:

In the Configuration Generator please tick "Advanced Mode", select OpenVPN version ">= 2.4" and select "IPv4 & IPv6 (connect with IPv6)".

Under "Eddie > Preferences > Networking > IP Protocol used for connection", "IPv4, IPv6" is selected by default. There is also another setting of "IPv6, IPv4" listed. I assume that the difference in these settings is which ever protocol is listed first will be how Eddie connects. If this assumption is correct and you are recommending to connect via IPv6, should I change from the default of "IPv4, IPv6" to "IPv6, IPv4" and "IPv6, IPv4" also be made the default in Eddie? What are the pros and/or cons and differences of connecting either by IPv4 or IPv6?

Share this post


Link to post

Will we need to create new .ovpn config files to use IP6? (e.g. not through your own client but using e.g. Viscosity or Tunnelblick) or do the existing client side config files automatically switch to IP6 (given an IP6 internet connection/router/ISP - client to VPN Server).

Share this post


Link to post

For me IPv6 connectivity always fails at route check.

 

! 2018.06.18 13:31:05 - Disconnecting
. 2018.06.18 13:31:05 - Routes, removed a route previously added, 194.187.251.163 for gateway 10.15.168.1
. 2018.06.18 13:31:05 - Sending management termination signal
. 2018.06.18 13:31:05 - Management - Send 'signal SIGTERM'
. 2018.06.18 13:31:05 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2018.06.18 13:31:05 - OpenVPN > SIGTERM received, sending exit notification to peer
. 2018.06.18 13:31:10 - OpenVPN > /sbin/ip route del 194.187.251.162/32
. 2018.06.18 13:31:10 - OpenVPN > /sbin/ip route del 0.0.0.0/1
. 2018.06.18 13:31:10 - OpenVPN > /sbin/ip route del 128.0.0.0/1
. 2018.06.18 13:31:10 - OpenVPN > Closing TUN/TAP interface
. 2018.06.18 13:31:10 - OpenVPN > /sbin/ip addr del dev tun0 10.15.168.6/24
. 2018.06.18 13:31:10 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting
. 2018.06.18 13:31:10 - Connection terminated.
. 2018.06.18 13:31:10 - DNS of the system restored to original settings (Rename method)
. 2018.06.18 13:31:10 - Flushing DNS
! 2018.06.18 13:31:12 - Session terminated.
! 2018.06.18 13:31:14 - Deactivation of Network Lock
! 2018.06.18 13:32:58 - Activation of Network Lock - Linux iptables
. 2018.06.18 13:34:54 - Updating systems & servers data ...
. 2018.06.18 13:34:58 - Systems & servers data update completed
I 2018.06.18 13:39:29 - Session starting.
I 2018.06.18 13:39:29 - Checking authorization ...
! 2018.06.18 13:39:29 - Connecting to Castor (Belgium, Brussels)
. 2018.06.18 13:39:29 - OpenVPN > OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
. 2018.06.18 13:39:29 - OpenVPN > library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08
. 2018.06.18 13:39:29 - Connection to OpenVPN Management Interface
. 2018.06.18 13:39:29 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100
. 2018.06.18 13:39:29 - OpenVPN > Control Channel Authentication: tls-auth using INLINE static key file
. 2018.06.18 13:39:29 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.18 13:39:29 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.18 13:39:29 - OpenVPN > Socket Buffers: R=[212992->212992] S=[212992->212992]
. 2018.06.18 13:39:29 - OpenVPN > UDPv4 link local: [undef]
. 2018.06.18 13:39:29 - OpenVPN > UDPv4 link remote: [AF_INET]91.207.57.114:443
. 2018.06.18 13:39:29 - OpenVPN > TLS: Initial packet from [AF_INET]91.207.57.114:443, sid=446b37a7 ef83ce09
. 2018.06.18 13:39:29 - OpenVPN > MANAGEMENT: Client connected from [AF_INET]127.0.0.1:3100
. 2018.06.18 13:39:29 - OpenVPN > VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org
. 2018.06.18 13:39:29 - OpenVPN > Validating certificate key usage
. 2018.06.18 13:39:29 - OpenVPN > ++ Certificate has key usage  00a0, expects 00a0
. 2018.06.18 13:39:29 - OpenVPN > VERIFY KU OK
. 2018.06.18 13:39:29 - OpenVPN > Validating certificate extended key usage
. 2018.06.18 13:39:29 - OpenVPN > ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
. 2018.06.18 13:39:29 - OpenVPN > VERIFY EKU OK
. 2018.06.18 13:39:29 - OpenVPN > VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Castor, emailAddress=info@airvpn.org
. 2018.06.18 13:39:30 - OpenVPN > Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2018.06.18 13:39:30 - OpenVPN > Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.18 13:39:30 - OpenVPN > Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
. 2018.06.18 13:39:30 - OpenVPN > Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
. 2018.06.18 13:39:30 - OpenVPN > Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
. 2018.06.18 13:39:30 - OpenVPN > [Castor] Peer Connection Initiated with [AF_INET]91.207.57.114:443
. 2018.06.18 13:39:32 - OpenVPN > SENT CONTROL [Castor]: 'PUSH_REQUEST' (status=1)
. 2018.06.18 13:39:32 - OpenVPN > PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway  def1 bypass-dhcp,dhcp-option DNS 10.12.232.1,route-gateway 10.12.232.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.12.232.144 255.255.255.0,peer-id 2'
. 2018.06.18 13:39:32 - OpenVPN > OPTIONS IMPORT: timers and/or timeouts modified
. 2018.06.18 13:39:32 - OpenVPN > OPTIONS IMPORT: LZO parms modified
. 2018.06.18 13:39:32 - OpenVPN > OPTIONS IMPORT: --ifconfig/up options modified
. 2018.06.18 13:39:32 - OpenVPN > OPTIONS IMPORT: route options modified
. 2018.06.18 13:39:32 - OpenVPN > OPTIONS IMPORT: route-related options modified
. 2018.06.18 13:39:32 - OpenVPN > OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
. 2018.06.18 13:39:32 - OpenVPN > OPTIONS IMPORT: peer-id set
. 2018.06.18 13:39:32 - OpenVPN > OPTIONS IMPORT: adjusting link_mtu to 1561
. 2018.06.18 13:39:32 - OpenVPN > ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=ens33 HWADDR=00:50:56:2b:26:f9
. 2018.06.18 13:39:32 - OpenVPN > TUN/TAP device tun0 opened
. 2018.06.18 13:39:32 - OpenVPN > TUN/TAP TX queue length set to 100
. 2018.06.18 13:39:32 - OpenVPN > do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
. 2018.06.18 13:39:32 - OpenVPN > /sbin/ip link set dev tun0 up mtu 1500
. 2018.06.18 13:39:32 - OpenVPN > /sbin/ip addr add dev tun0 10.12.232.144/24 broadcast 10.12.232.255
. 2018.06.18 13:39:37 - OpenVPN > /sbin/ip route add 91.207.57.114/32 via 192.168.1.1
. 2018.06.18 13:39:37 - OpenVPN > /sbin/ip route add 0.0.0.0/1 via 10.12.232.1
. 2018.06.18 13:39:37 - OpenVPN > /sbin/ip route add 128.0.0.0/1 via 10.12.232.1
. 2018.06.18 13:39:37 - /etc/resolv.conf moved to /etc/resolv.conf.eddie as backup
. 2018.06.18 13:39:37 - DNS of the system updated to VPN DNS (Rename method: /etc/resolv.conf generated)
. 2018.06.18 13:39:37 - Routes, added a new route, 91.207.57.115 for gateway 10.12.232.1
. 2018.06.18 13:39:37 - Unable to compute route for 2001:ac8:27:f:c0ca:9f36:68ed:1e70: IPv6 VPN gateway not available.
. 2018.06.18 13:39:37 - Flushing DNS
I 2018.06.18 13:39:39 - Checking route IPv4
I 2018.06.18 13:39:39 - Checking route IPv6
. 2018.06.18 13:39:59 - curl: (28) Connection timed out after 20000 milliseconds
. 2018.06.18 13:39:59 - Checking route (2° try)
. 2018.06.18 13:40:20 - curl: (28) Connection timed out after 20001 milliseconds
. 2018.06.18 13:40:20 - OpenVPN > Initialization Sequence Completed
! 2018.06.18 13:40:20 - Disconnecting
. 2018.06.18 13:40:20 - Routes, removed a route previously added, 91.207.57.115 for gateway 10.12.232.1
. 2018.06.18 13:40:20 - Sending management termination signal
. 2018.06.18 13:40:20 - Management - Send 'signal SIGTERM'
. 2018.06.18 13:40:20 - OpenVpn Management > ENTER PASSWORD:
. 2018.06.18 13:40:20 - OpenVPN > MANAGEMENT: CMD 'signal SIGTERM'
. 2018.06.18 13:40:20 - OpenVPN > SIGTERM received, sending exit notification to peer
. 2018.06.18 13:40:25 - OpenVPN > /sbin/ip route del 91.207.57.114/32
. 2018.06.18 13:40:25 - OpenVPN > /sbin/ip route del 0.0.0.0/1
. 2018.06.18 13:40:25 - OpenVPN > /sbin/ip route del 128.0.0.0/1
. 2018.06.18 13:40:25 - OpenVPN > Closing TUN/TAP interface
. 2018.06.18 13:40:25 - OpenVPN > /sbin/ip addr del dev tun0 10.12.232.144/24
. 2018.06.18 13:40:25 - OpenVPN > SIGTERM[soft,exit-with-notification] received, process exiting
. 2018.06.18 13:40:25 - Connection terminated.
. 2018.06.18 13:40:25 - DNS of the system restored to original settings (Rename method)
I 2018.06.18 13:40:25 - Cancel requested.
! 2018.06.18 13:40:25 - Session terminated.

Is there anything I can do to fix it?

Share this post


Link to post

Hello!

This error:

. 2018.06.18 13:39:37 - Unable to compute route for 2001:ac8:27:f:c0ca:9f36:68ed:1e70: IPv6 VPN gateway not available.

 

is apparently hinting to a problem on the server side. However, first of all could you please check OpenVPN latest release? Additionally, a system report from Eddie might provide us with additional and potentially precious clues (to send a system report: "Logs" > click life belt icon > Copy all > paste into your message).

 

Have you already tested different Generation 2 VPN servers? If so, does the problem stay?

 

Last but not least, can you please verify the IPv6 status for your tun/tap interface, and make sure that IPv6 is not disabled?

 

Kind regards

Share this post


Link to post

Updating OpenVPN to 2.4.6 vià their repository fixed the issue. Thanks for the hint 

Share this post


Link to post

I did noticed some incredible speed on occasion, maxing out my 400mbps line !

First reaction was "Is VPN still on ? This is too fast !"

 

I'm guess it's the load-balancer that did it's magic.

 

Good job Air, good job !!

 

9e9.gif

Share this post


Link to post

Will Eddie on desktop default to tls-crypt when protocol is set to automatic if the chosen server is capable?

Share this post


Link to post

For those who use Ubuntu (or derivatives) and who plan to jump on the IPv6 wagon: Be aware that some third party repos don't support IPv6 yet. You may need to force IPv4 connectivity to be able to update your system while connected to AirVPN servers. You can do so by adding the following command when invoking apt: -o Acquire::ForceIPv4=true

 

Another solution is to add a config file that stores this rule permanently, just copy the following command to your terminal emulator and execute it: echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

 

I know it's not really eddie or AirVPN related but it's one of the first issues I encountered after making use of the new IPv6 capabilities of eddie. Before IPv6 was disabled on os level for privacy reasons. And I bet I'm not the only one who might encounter this issue after IPv6 has been implemented into the stable release of eddie.

Share this post


Link to post

Great that you implemented IPv6 in your service. Thank you!

 

Although I got a few questions:

1. Port Forwarding is not working (yet)? I've already pointed a URL to the exit v6 and can ping it, but I can't establish a connection with SSH

 

 

2. The test from https://test-ipv6.com/ is showing me a 10/10 but says "Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this."

 

Both my browsers (FF and Chromium) don't use IPv6 actively. Is this a problem because of the DNS using IPv4 or because the IPv6 of the tun device gets a Unique local address?

 

 

3. When importing your ovpn files in NetworkManager, the IPv6 functionality is absent. Even if I activate the IPv6 tun-connection manually. It is working fine with the openvpn cli tool.

 

Hope you can shed some light on these questions.

 

Arch Linux up to date

 

EDIT: A test on Subra revealed some problems:

Danger! IPv6 sorta works - however, large packets appear to fail, giving the appearance of a broken website. If a publisher publishes to IPv6, you will believe their web site to be broken. Ask your ISP about MTU issues; possibly with your tunnel. Check your firewall to make sure that ICMPv6 messages are allowed (in particular, Type 2 or Packet Too Big)

 

Gianfar and Kajam are working fine.

Share this post


Link to post

@Staff, I saw your tweet about Atik and the huge amount of traffic on it.

 

For testing purposes were you directing all connections to the Netherlands region to that server to put a huge load on it?

Share this post


Link to post

@Staff, I saw your tweet about Atik and the huge amount of traffic on it.

 

For testing purposes were you directing all connections to the Netherlands region to that server to put a huge load on it?

Also curious to know this and also how it managed 1.7Gbit/s when it's only connected to a 1Gbit/s line?

Share this post


Link to post

@Staff, I saw your tweet about Atik and the huge amount of traffic on it.

 

For testing purposes were you directing all connections to the Netherlands region to that server to put a huge load on it?

 

 

Hello!

 

No, we wouldn't make a stress test with customers. However, a system error caused the overload and we took advantage to take a look (ex post) to see how the server reacted to this mistake. When we realized what happened, it had already happened: at least we now have an interesting set of data coming from a "real life" test. The set of data is comfortably surprising, even because Atik is NOT YET a Gen 2 server, so the latest load balancing system is not yet implemented. This means that now we expect even more from Gen 2 servers which share 10 Gbit/s lines.

 

Kind regards

Share this post


Link to post

 

@Staff, I saw your tweet about Atik and the huge amount of traffic on it.

 

For testing purposes were you directing all connections to the Netherlands region to that server to put a huge load on it?

Also curious to know this and also how it managed 1.7Gbit/s when it's only connected to a 1Gbit/s line?

 

 

 

Hello!

 

We are not yet well equipped to break the laws of physics. Servers in the NL are connected to 10 Gbit/s lines and ports. However, the lines are shared by 11 servers, so in the worst case scenario of maximum, simultaneous bandwidth requirement, theoretically and optimistically (and boldly assuming that a perfect balance is possible) each server can have 909 Mbit/s.

 

Kind regards

Share this post


Link to post

Great that you implemented IPv6 in your service. Thank you!

 

Although I got a few questions:

 

1. Port Forwarding is not working (yet)? I've already pointed a URL to the exit v6 and can ping it, but I can't establish a connection with SSH

Hello!

 

Thanks, this needs an investigation. When you test in IPv4, you have no problems with port forwarding, is this right? Does the same happen if you run Eddie with Network Lock enabled and disabled? Have you checked the firewall rules pertaining to IPv6, especially when you run some other software to connect?

 

 

2. The test from https://test-ipv6.com/ is showing me a 10/10 but says "Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this."

 

Both my browsers (FF and Chromium) don't use IPv6 actively. Is this a problem because of the DNS using IPv4 or because the IPv6 of the tun device gets a Unique local address?

 

This is a matter we are aware of, but we still don't have a definite explanation. https://airvpn.org/topic/25140-the-issue-your-browser-is-avoiding-ipv6/

 

We counted on some feedback and additional investigation, but the never ending black outs with IPv6 and the poor implementation in Italy ISPs made this impossible and we have postponed an additional investigation. On top of that, the issue does not affect the most important achievements we wanted with IPv6 support. i.e. the ability to provide at the same time:

- a comfortable experience without any connectivity breaks to those who have only IPv6 connectivity

- access to IPv6 services even to those who only have IPv4

- definitive resolution of IPv6 leaks with no need to completely block or disable globally IPv6 (unless explicitly required by the user) for those users who don't run Eddie

 

3. When importing your ovpn files in NetworkManager, the IPv6 functionality is absent. Even if I activate the IPv6 tun-connection manually. It is working fine with the openvpn cli tool.

 

Hope you can shed some light on these questions.

 

Arch Linux up to date ;)

We have dropped support to network-manager-openvpn since a long ago. We might investigate the issue in the future, but currently the official recommendation from the techies is just to not use it.

 

EDIT: A test on Subra revealed some problems:

 

Danger! IPv6 sorta works - however, large packets appear to fail, giving the appearance of a broken website. If a publisher publishes to IPv6, you will believe their web site to be broken. Ask your ISP about MTU issues; possibly with your tunnel. Check your firewall to make sure that ICMPv6 messages are allowed (in particular, Type 2 or Packet Too Big)

 

Gianfar and Kajam are working fine.

 

Thanks, that needs an investigation too.

 

Kind regards

Share this post


Link to post

@Staff is it possible connecting with IPV6 could be used to bypass IP blocks?

 

Suppose a ISP blocks a VPN IPv4 VPN entry. Could the IPv6 still get through?

 

Hello!

 

Yes, it's possible.

 

Kind regards

Share this post


Link to post

Updated documentation please

 

How would I use IPv4 and IPv6 on DD-WRT with tls-crypt for example?

 

I would also like to know that!

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...