Jump to content


Photo

IPv6 support and new smart features


  • Please log in to reply
85 replies to this topic

#1 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7697 posts

Posted 15 June 2018 - 01:40 PM

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.

 

See the last update here: https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features/page-4#entry77508

 

 

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



#2 go558a83nk

go558a83nk

    Advanced Member

  • Members2
  • PipPipPip
  • 1684 posts

Posted 15 June 2018 - 02:53 PM

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



#3 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7697 posts

Posted 15 June 2018 - 02:59 PM

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



#4 5YmkoLQZ

5YmkoLQZ

    Advanced Member

  • Members2
  • PipPipPip
  • 206 posts

Posted 15 June 2018 - 06:57 PM

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)


#5 Monotremata

Monotremata

    Advanced Member

  • Members2
  • PipPipPip
  • 67 posts

Posted 15 June 2018 - 10:03 PM

Merope should be on there too, its also Gen2, and that and Sabik just came off maintenance after 2 days finally!



#6 mz5fi6xqp8ab

mz5fi6xqp8ab

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 16 June 2018 - 11:26 AM

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?



#7 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7697 posts

Posted 16 June 2018 - 04:06 PM

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



#8 puff-m-d

puff-m-d

    Advanced Member

  • Members
  • PipPipPip
  • 50 posts

Posted 16 June 2018 - 07:15 PM

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?



#9 trekkie.forever

trekkie.forever

    Advanced Member

  • Members
  • PipPipPip
  • 39 posts

Posted 16 June 2018 - 08:12 PM

Updated documentation please

 

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



#10 Psamathe

Psamathe

    Newbie

  • Members
  • Pip
  • 3 posts

Posted 17 June 2018 - 07:50 AM

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).



#11 altae

altae

    Advanced Member

  • Members
  • PipPipPip
  • 120 posts
  • LocationSwitzerland

Posted 18 June 2018 - 11:44 AM

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?



#12 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7697 posts

Posted 18 June 2018 - 12:44 PM

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



#13 altae

altae

    Advanced Member

  • Members
  • PipPipPip
  • 120 posts
  • LocationSwitzerland

Posted 18 June 2018 - 04:08 PM

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



#14 Shiver Me Whiskers

Shiver Me Whiskers

    Member

  • Members
  • PipPip
  • 26 posts

Posted 19 June 2018 - 11:13 AM

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



#15 zsam288

zsam288

    Advanced Member

  • Members
  • PipPipPip
  • 33 posts

Posted 19 June 2018 - 03:52 PM

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

#16 altae

altae

    Advanced Member

  • Members
  • PipPipPip
  • 120 posts
  • LocationSwitzerland

Posted 19 June 2018 - 10:30 PM

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.



#17 kaymio

kaymio

    Member

  • Members
  • PipPip
  • 11 posts

Posted 20 June 2018 - 09:52 AM

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.



#18 go558a83nk

go558a83nk

    Advanced Member

  • Members2
  • PipPipPip
  • 1684 posts

Posted 21 June 2018 - 04:34 PM

@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?



#19 mwm

mwm

    Advanced Member

  • Members
  • PipPipPip
  • 30 posts

Posted 21 June 2018 - 06:44 PM

@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?



#20 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7697 posts

Posted 21 June 2018 - 07:05 PM

@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






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Servers online. Online Sessions: 14098 - BW: 42648 Mbit/sYour IP: 3.80.177.176Guest Access.