Leaderboard

Hello! We're very glad to inform you that a new 1 Gbit/s server located in Siauliai (LT) is available: Tarf. The AirVPN client will show automatically the new server; if you use any other OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP. Just like every other "second generation" Air server, Tarf supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.2 and tls-crypt. Full IPv6 support is included as well. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. You can check the server status as usual in our real time servers monitor: https://airvpn.org/servers/Tarf Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

@hawkflights Hello! Can you please tell us your exact Linux distribution version? @colorman Hello! TLS Crypt encrypts the whole OpenVPN Control Channel. Therefore DPI can't detect anymore any typical OpenVPN "fingerprint", thus can't trigger traffic shaping against OpenVPN, or similar. TLS Crypt in an agnostic network does not improve or affect negatively performance, as most of the time is spent on encryption and decryption of the Data Channel. Therefore, if you experience a better throughput with TLS crypt, a plausible explanation is that your ISP enforces traffic shaping. @inc Hello! Should the re-keying errors re-appear, can you tell us your exact Linux distribution version? @funkoholic Hello! Connection over Tor is not planned for the next major release, which is focused on creating an Hummingbird daemon and two different frontends, one of them in Qt, without adding major new features at least for the first release cycle. Connection over Tor is a special case of the more general connection over a SOCKS proxy, with the addition of communications with Tor to obtain the Tor entry-node IP address and route it outside the VPN, preventing the infinite routing loop problem. Hence, we need to review the code of the library pertaining to connections over a proxy, which we did not touch. Kind regards

I know it's a long shot, but would it be possible to introduce vpn over tor support in near future? Then I'm ready to ditch eddie Thanks.

Hummingbird landed on HN: https://news.ycombinator.com/item?id=21997261

I think it's almost trivial to connect to internet via multi hop OpenVPN system, at least on Linux. Thanks to AirVPN for allowing multiple connections at the same time! The hopping can be made with the following bash script by Perfect Privacy (https://www.perfect-privacy.com/en/manuals/linux_openvpn_terminal_cascading). At first, you download the ovpn configurations for your favorite servers. I use only one hop so in practice, I need two different OpenVPN servers with their entry IP addresses. Then you follow the instructions of the script. For example, if your first server is in Siauliai, you run sudo openvpn --config AirVPN_LT-Siauliai_Porrima_UDP-443.ovpn --script-security 2 --route remote_host --persist-tun --up updown.sh --down updown.sh --route-noexec Then read the output of the above command and insert the given gateway IP address to the next hop: sudo openvpn --config AirVPN_LV-Riga_Meissa_UDP-443.ovpn --script-security 2 --route remote_host--persist-tun --up updown.sh --down updown.sh --route-noexec --setenv hopid 2 --setenv prevgw 10.xxx.yyy.zzz (Note that the hop script looks also for update-resolv-conf script to update the DNS, so install it if necessary from https://github.com/jonathanio/update-systemd-resolved). Then the traffic goes through two VPN servers! Your ISP sees UDP traffic to the first hop, meanwhile your external IP looks to be the exit IP address of the second server. If you want to apply leak protection, you can use Eddie. The second option is to apply Eddie's leak protection and then export the generated iptables rules to a file: sudo iptables-save > iptables-rules.txt sudo iptables-restore iptables-rules.txt If your iptables rules were empty before leak protection, you can recover that state by sudo iptables -F The last step is really not necessary, but rather for peace of mind. Latest Linux distros may have peculiar DNS behaviour (not leak, because even DNS requests are tunneled in the VPN connection), you can remove the nasty entry of DNS Domain: ~. from your systemd-resolved daemon by command (assumed that your interface is called wlan0) sudo systemd-resolve -i wlan0 --set-domain local I don't know, if the local argument is a proper one, but at least is forces away the value ~. and ipleak.net shows that non-AirVPN DNS servers are not used at all.