Staff

Hello! 10.4.0.1 remains good for your purpose. It is ping-able from any subnet. EDIT: nope. It is a DNS server IP address which is reachable from any subnet. Kind regards

10.4.0.1 must be ping-able from any subnet, if you experience this issue there's something wrong either in the server or in your connection. For a preliminary check can you please tell us the server(s) you experience this problem on? Kind regards

Hi Nadre, not random, they are unique (and always the same) for each OpenVPN daemon of each server. You will not find the same subnets, either in IPv4 or IPv6, in two different AirVPN servers or even daemons (that's why Gen 2 are multi-homing friendly, which is a feature frequently requested by pfSense and other systems users since when we provide five simultaneous connection slots). Kind regards

@kaymio Our assigned ULAs are in fde6:7a:7d20::/48 which is inside the range officially reserved to ULA so we don't understand why a browser should discriminate against them in favor of a local IPv4 address... Kind regards

Hello! In Generation 2 subnets are smaller and unique to each server OpenVPN daemon. In this way multi-homing becomes much easier and any (unlikely) overlapping with your local subnet somewhere in 10.0.0.0/8 can immediately be resolved by changing server. In IPv6, our assigned ULAs are in fde6:7a:7d20::/48 - even here collisions with your local addresses are very unlikely. Kind regards

When the whole infrastructure supports it, sure. In the meantime, is there anything unclear in the first post of this thread, in the Eddie protocols menu and in the Configuration Generator? They seem to tell what you want. Kind regards

Hello! We inform you that we have received the following warning from M24Seven, our provider for Prague servers and lines: network maintenance on our Prague PoP during the following time interval:. Start: 27th June 2018, 04:30 UTC End: 27th June 2018, 08:30 UTC During this time Infrastructure engineers will be working on upgrading the infrastructure serving Prague customers. Customers in Prague may experience sub-optimal routing, speed degradation and in some cases complete outage whilst the network is upgraded. These works are crucial to ensure additional services, resiliency and capacity out of this site. Since outages may not be ruled out, you might like to consider to avoid Prague servers during those four maintenance hours. Kind regards AirVPN Staff

Hello! The "Events" tab disappeared. This is a bug which will be fixed. Please downgrade to 2.13.6 in the meantime, if you need the "Events" menu. We apologize for the inconvenience. Kind regards

Hello! At the moment this is not planned, we're sorry. We want to maintain the protection you have with IPv4, where the exit-IPv4 address is shared between all the clients connected to a certain VPN, and the nodes are behind a NAT with a private address in some subnet. Kind regards

@serenacat Here the reports we have: China: tls-crypt always works in TCP and only sometimes in UDP (due to the fact that in mobile lines UDP is blocked by itself, we presume). OpenVPN over SSL works. tls-crypt is faster. Iran. same as China UAE: same as China Egypt: OpenVPN over SSL works. No reports about tls-crypt so far, unfortunately. Saudi Arabia: same as Egypt Kind regards

Just to clarify, does WebRTC show your public IPv6 address, your public IPv4 address or your private addresses? Kind regards I checked just now, and apparently its NOT any of my addresses. IPleak says its a "private use" one, its a 10.28.x.x address, which I think might be AirVPN?? Yes, as securvark explained as well, that's the virtual private network IP address. Therefore Network Lock works as expected and you have never had any leak. Everything was and is fine. Kind regards

Just to clarify, does WebRTC show your public IPv6 address, your public IPv4 address or your private addresses? Kind regards

Ok! We'll see to do something. Kind regards Quick question, are IPV6 addresses less likely to be blocked than their IPV4 counterparts? For example if a VPN IPV4 address is blocked and the offending network has IPV6 support, is a connection attempt through IPV6 instead possibly effective? Yes, it's possible. Yes, of course. Normally we have a /64 range per server, so... More info and details can be found here: https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features/ Kind regards

Hello! Wait, while the other issues could be caused by the browsers and other factors we can't have any control on, this should NOT happen if Network Lock is enabled. Can you please try again with Network Lock enabled AND Eddie version 2.15.2? Kind regards

Hello! The sudden OpenVPN disconnection, which apparently occurs even before that OpenVPN tries anything to connect, makes us think about some problem with the tun/tap interface. In the past, it happened 3-4 times that OpenVPN did not work at all on Mac beta operating systems. Can you please increase log verbosity by ticking "Log debug" in the "Logging" window (then click "Save") and publish a system report, either here or in a ticket, taken just after the problem has occurred? Kind regards

Hello! Yes, it's possible. Kind regards

Hello! It's 10.4.0.1. It is reachable from any other subnet, even in Generation 2 servers, where subnets are smaller (/24) and unique for each server, port and protocol (a modification which makes multi-homing much simpler). Alternatively, consider to accept the DNS push from the server, if possible. Accepting the DNS push has a relevant advantage: it makes attacks based on DNS hijacking through route injection impossible, because the default VPN gateway address matches the DNS server address. Kind regards

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? 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 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. Thanks, that needs an investigation too. Kind regards

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

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

Hello! Because you need to compare changes against version 2.14.5, since 2.15.1 has not been promoted to stable. Bug fixes and changes on version 2.15.1 have been kept in version 2.15.2 for Linux and Mac. In this way Linux, Mac and Windows systems are "aligned" to use the same release number for the latest stable version. Kind regards

Hello! Eddie 2.15.2 has just been released: https://airvpn.org/topic/28343-eddie-2152-released/ Kind regards

That's correct. Kind regards

Hello! We're very glad to inform you that a new Eddie Air client version has been released: 2.15.2. As usual, Eddie is released as free and open source software under GPLv3. Eddie 2.15.2 includes an important bug fix for Windows users who change the default settings and force Network Lock to work with "Windows Firewall" (an option that anyway remains not recommended, Windows Filtering Platform should be preferred). You can see the changelog here: https://airvpn.org/services/changelog.php?software=client&format=html Network Lock is an Eddie feature that prevents any type of traffic leak outside the VPN tunnel https://airvpn.org/faq/software_lock Eddie includes a full, seamless and integrated IPv6 support, as well as new features which will let you use our latest service additions including IPv6 and tls-crypt: https://airvpn.org/topic/28153-ipv6-support-and-new-smart-features/ Users who have only IPv4 connectivity will be able to access IPv6 services, At the same time users who have only IPv6 (and not IPv4) connectivity, will be able to use our service as well. tls-crypt implementation provides a new, interesting way to efficiently bypass blocks and throttling against OpenVPN. This version has been released for GNU/Linux, OS X (Mavericks or higher is required), macOS and Windows (Vista or higher is required). 2.15.2 version is compatible with several Linux distributions. For important notes about environments, please read here: https://airvpn.org/topic/27259-status-of-eddie-on-linux-distributions/ Just like previous versions, Eddie implements direct Tor support for OpenVPN over Tor connections. Eddie makes OpenVPN over Tor easily available to Linux, OS X and macOS users: no needs for Virtual Machines, middle boxes or other special configurations. Windows users will find a more friendly approach as well. This mode is specifically designed for Tor and therefore solves multiple issues, especially in Linux and OS X/macOS, including the "infinite routing loop" problem (see for example http://tor.stackexchange.com/questions/1232/me-tor-vpn-how/1235#1235 ) As far as we know, Eddie is the first and currently the only OpenVPN wrapper that natively allows OpenVPN over Tor connections for multiple Operating Systems. https://airvpn.org/tor Since version 2.14, Eddie sends a NEWNYM signal to Tor to ensure the use of a new circuit in every connection. We recommend that you upgrade Eddie as soon as possible. Eddie 2.15.2 for GNU/Linux can be downloaded here: https://airvpn.org/linux Eddie 2.15.2 for Windows can be downloaded here: https://airvpn.org/windows Eddie 2.15.2 for OS X Mavericks, Yosemite, El Capitan and macOS Sierra and High Sierra can be downloaded here: https://airvpn.org/macosx PLEASE NOTE: Eddie 2.15.2 package includes an OpenVPN version re-compiled by us from OpenVPN 2.4 source code to fix this bug: https://community.openvpn.net/openvpn/ticket/328 Eddie overview is available here: https://airvpn.org/software Eddie includes a Network Lock feature: https://airvpn.org/faq/software_lock Eddie is free and open source software released under GPLv3. GitHub repository: https://github.com/AirVPN/airvpn-client Kind regards & datalove AirVPN Staff

Hello! We inform you that IPv4 addresses of the servers mentioned in the subject have been changed. The change was mandatory to have the servers communicate in a different sub network in the same datacenter. The old IP addresses were behind a peculiar DDoS protection which was impacting performance heavily (maybe due to some sub-optimal configuration against UDP). From now on the three mentioned servers should go back to the normal and expected high performance. If you run Eddie, just update servers data (Eddie will do that automatically anyway, unless you explicitly disabled this function). If you don't run Eddie, please remember to generate new configuration files for those servers, if you wish to connect to them. Kind regards AirVPN Staff