Search the Community

Hi, I'm trying to setup wireguard in a way that only applications i set to use the wg's interface will route its traffic through the VPN, with port forwarding enabled. I was under the impression that something like the following should work, but it doesn't: [Interface] Address = 10.184.118.49 PrivateKey = [redacted] MTU = 1320 DNS = 9.9.9.9 [Peer] PublicKey = [redacted] PresharedKey = [redacted] Endpoint = ip:port AllowedIPs = 10.184.118.0/24 PersistentKeepalive = 15 If I set the AllowedIPs to 0.0.0.0/0 then I can port forward, but all my traffic is routed over the VPN, and I don't want that. Is something like this possible with AirVPN? Thank you, Alonzo

TLDR Issue: When port forwarding is enabled, traffic forwarded from the VPN is being return via the WAN. So it's going AirVPN -> pfsense via VPN -> server -> pfsense via WAN -> Clear Internet. Software: pfsense 2.7.2-RELEASE, Package: WireGuard 0.2.1. Server: ubuntu 22.04.03 LTS I'm reaching out to the community because I'm out of ideas on how to fix what's going wrong. I'm not a network or firewall guru, I'm tech savy but clearly not enough to resolve my issue 😧. I followed the pfSense baseline setup guide available at nguvu.org to configure my pfsense. While the guide primarily focuses on using OpenVPN for the VPN setup, I adapted the instructions to use WireGuard instead but clearly I've missed something or fundermentally misunderstanding something. When I configure port forwarding using AirVPN with WireGuard to pfSense to my VPN network to a sever, I can see on a TCPDump the the initial inbound packets from AirVPN that's being port forwarded reaches the server, but each reply seems to vanish when returned to the router. Using diag_packet_capture on pfsense, I can see the inbound traffic from AirVPN, but when the server replies, it's going out on the WAN interface. Clearly there's some sort of gateway issue. I even tried to pay someone on Fiverr to fix it but they couldn't see any reason for it, they're claming it's a software defect, but seeing other people have somehow managed to do it, must be possible. Have I missed something silly? The port: The Server: These are my rules so far: WAN: WireGuard: Floating: VL20_VPN: Note: Selective_Routing (or VPN whitelist) isn't set: Gateways: Port Forward: Outbound NAT

Everytime I try "Connect to a recommended server" or just try one of the servers from the server list it tries to connect to it and then instantly fails. I will include the logs here below, I'm kinda new to this so any help would be highly appreciated! :D Eddie_20231114_155636.txt

I noticed this started a month ago when connecting to Valve's servers with an AirVPN server results in a dropped connection. Previously it was possible to run AirVPN on a router and play games on Steam. However, nowadays whilst finding a match with the game coordinator still works it'll disconnect the player and impose a penalty despite accepting the match. Attempts at a workaround by changing servers to different regions, changing DNS servers, OpenVPN and Wireguard protocols, different network interface and devices results in the same dropped connection. It seems like Valve's gaming servers are currently blocking AirVPN.

Using AirVPN suite 1.2.1 on Debian Bullseye, I can't seem to get the --air-list, --air-info, --air-key-list options to output anything. I'm probably missing something obvious. I'm operating under the assumption that these commands are supposed to pull their info from AirVPN servers. Should I instead generate that info independently and store it locally somewhere for goldcrest to query? Here's the output from example commands given in the readme (other variants give the same output): use@host:~$ goldcrest --air-info --air-server all 2023-03-13 14:26:26 Reading run control directives from file /root/.config/goldcrest.rc Goldcrest 1.2.1 - 9 December 2022 2023-03-13 14:26:26 Bluetit - AirVPN OpenVPN 3 Service 1.2.1 - 9 December 2022 2023-03-13 14:26:27 OpenVPN core 3.8.2 AirVPN linux x86_64 64-bit 2023-03-13 14:26:27 Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved. 2023-03-13 14:26:27 OpenSSL 1.1.1n 15 Mar 2022 2023-03-13 14:26:27 Bluetit is connected to VPN

Hello community, I'm quite new to VPN's and used them only in Client mode. I need a solution where all my network traffic gets routed trough a VPN, for every client that is connected to my Archer M600. On my Fritzbox and Archer M600 I only got the option for Server mode, to access my homenetwork from the internet, but not in Clientmode for outgoing traffic Am I maybe just overseeing something? I got a Pi4 aswell. Any chance to get this working? Thanks

Advice on a good VPN. To use both on pc and android

Looking into subscribing? potential issue I'm unsure of. My home has CCTV installed will there be any conflict as the the post used for it are as per image

Hey team, since one week I can't login and play Valorant anymore, supposedly because some EU VPN servers are blocked from access to the authentication servers via Cloudflare. Anything we can do to circumvent this? Like trying different ports or settings? Logging in through Netherlands, US and other VPN servers works, but it's horrible Ping for me obv. Prague, Frankfurt, Vienna, Brussels all don't work. Example: account.riotgames.com

I am just wondering how affected are users of AirVPN who might live in India, because of this news development? i myself do not live in India but might similar countries adopt measures or laws like this one? India tells VPN / Cloud / Crypto companies to collect user data for 5 years or face IMPRISONMENT https://www.techspot.com/news/94441-india-tells-vpn-cloud-crypto-companies-collect-user.html i am asking because i want to know what a user of ANY VPN service would do if this kind of TYRANNY ever came to their country -- could they be detected as a "VPN user"? how dangerous is this law? I know that companies like Mullvad are now LOG-LESS AND DISKLESS -- meaning that their VPN service software CANNOT even collect any logs. How does AirVPN compare to Mullvad when it comes to being LOG-LESS? I know AirVPN is LOGLESS but are their servers also DISKLESS ??? Thanks in advance.

Can this happen while being connected via AirVPN ? I do not know? --- Read more of this story at Slashdot. https://yro.slashdot.org/story/22/01/31/222250/website-fined-by-german-court-for-leaking-visitors-ip-address-via-google-fonts I originally saw this story posted on Facebook and here is their comment thread on it: https://www.facebook.com/slashdot/posts/10158469206330857 I do not know if this can still happen while being connected on ANY VPN, let alone while on or using AirVPN? Can anyone help me who knows better? I guess a simple yes or no from someone who knows better, would be reassuring lol

Lately, I've been unable to get Eddie to connect to any server on my Linux operation system. It's always stuck while doing latency tests and I get this following error message. E 2021.12.27 13:47:45 - Exception: nft issue: exit:1; out:; err:Error: syntax error, unexpected rule, expecting string E 2021.12.27 13:47:45 - del rule ip filter OUTPUT ip daddr 52.48.66.85 counter accept E 2021.12.27 13:47:45 - ^^^^ If you need info on my OS... System: Host: <filter> Kernel: 5.14.0-4mx-amd64 x86_64 bits: 64 compiler: N/A parameters: BOOT_IMAGE=/vmlinuz-5.14.0-4mx-amd64 root=UUID=<filter> ro quiet splash slab_nomerge slub_debug=FZ init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on vsyscall=none debugfs=off oops=panic loglevel=0 spectre_v2=on spec_store_bypass_disable=on tsx=off tsx_async_abort=full,nosmt mds=full,nosmt l1tf=full,force nosmt=force kvm.nx_huge_pages=force ipv6.disable=1 apparmor=1 security=apparmor random.trust_cpu=off intel_iommu=on amd_iommu=on efi=disable_early_pci_dma kaslr pti=on slab_nomerge page_poison=1 slub_debug=FPZ nosmt Desktop: Xfce 4.16.0 tk: Gtk 3.24.24 info: xfce4-panel wm: xfwm4 dm: LightDM 1.26.0 Distro: MX-21_ahs_x64 Wildflower November 22 2021 base: Debian GNU/Linux 11 (bullseye) Machine: Type: Laptop System: ASUSTeK product: ROG Strix G713QM_G713QM v: 1.0 serial: <filter> Mobo: ASUSTeK model: G713QM v: 1.0 serial: <filter> UEFI: American Megatrends LLC. v: G713QM.314 date: 09/03/2021 Battery: ID-1: BAT0 charge: 87.5 Wh condition: 87.5/90.0 Wh (97%) volts: 17.2/15.9 model: AS3GWAF3KC GA50358 type: Li-ion serial: <filter> status: Full Device-1: hidpp_battery_0 model: Logitech Wireless Keyboard K270 serial: <filter> charge: 100% (should be ignored) rechargeable: yes status: Discharging Device-2: hidpp_battery_1 model: Logitech M585/M590 Multi-Device Mouse serial: <filter> charge: 55% (should be ignored) rechargeable: yes status: Discharging CPU: Topology: 8-Core model: AMD Ryzen 9 5900HX with Radeon Graphics bits: 64 type: MCP arch: N/A family: 19 (25) model-id: 50 (80) stepping: N/A microcode: A50000B L2 cache: 4096 KiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 52703 Speed: 2857 MHz min/max: 1200/3300 MHz boost: enabled Core speeds (MHz): 1: 3370 2: 2728 3: 3567 4: 3239 5: 2523 6: 1916 7: 2650 8: 4126 Vulnerabilities: Type: itlb_multihit status: Not affected Type: l1tf status: Not affected Type: mds status: Not affected Type: meltdown status: Not affected Type: spec_store_bypass mitigation: Speculative Store Bypass disabled Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization Type: spectre_v2 mitigation: Full AMD retpoline, IBPB: always-on, IBRS_FW, STIBP: disabled, RSB filling Type: srbds status: Not affected Type: tsx_async_abort status: Not affected Graphics: Device-1: NVIDIA GA106M [GeForce RTX 3060 Mobile / Max-Q] vendor: ASUSTeK driver: N/A bus ID: 01:00.0 chip ID: 10de:2520 Device-2: AMD Cezanne vendor: ASUSTeK driver: amdgpu v: kernel bus ID: 06:00.0 chip ID: 1002:1638 Display: x11 server: X.Org 1.20.13 driver: amdgpu,ati unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz OpenGL: renderer: AMD RENOIR (DRM 3.42.0 5.14.0-4mx-amd64 LLVM 12.0.1) v: 4.6 Mesa 21.2.5 direct render: Yes Audio: Device-1: NVIDIA vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 01:00.1 chip ID: 10de:228e Device-2: AMD Renoir Radeon High Definition Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 06:00.1 chip ID: 1002:1637 Device-3: AMD Raven/Raven2/FireFlight/Renoir Audio Processor vendor: ASUSTeK driver: N/A bus ID: 06:00.5 chip ID: 1022:15e2 Device-4: AMD Family 17h HD Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel bus ID: 06:00.6 chip ID: 1022:15e3 Sound Server: ALSA v: k5.14.0-4mx-amd64 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: ASUSTeK driver: r8169 v: kernel port: e000 bus ID: 02:00.0 chip ID: 10ec:8168 IF: eth0 state: down mac: <filter> Device-2: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel port: e000 bus ID: 03:00.0 chip ID: 8086:2723 IF: wlan0 state: up mac: <filter> IF-ID-1: tun0 state: unknown speed: 10 Mbps duplex: full mac: N/A Drives: Local Storage: total: 7.50 TiB used: 3.22 TiB (43.0%) ID-1: /dev/nvme0n1 vendor: Samsung model: MZVLQ1T0HBLB-00B00 size: 953.87 GiB block size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 serial: <filter> rev: FXM7201Q scheme: GPT ID-2: /dev/nvme1n1 vendor: Samsung model: SSD 970 EVO Plus 250GB size: 232.89 GiB block size: physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 serial: <filter> rev: 2B2QEXM7 scheme: GPT ID-3: /dev/sda type: USB vendor: Seagate model: Backup+ Hub BK size: 7.28 TiB block size: physical: 4096 B logical: 512 B serial: <filter> rev: D781 scheme: GPT Partition: ID-1: / raw size: 63.98 GiB size: 62.68 GiB (97.96%) used: 13.97 GiB (22.3%) fs: ext4 dev: /dev/dm-0 ID-2: /boot raw size: 256.0 MiB size: 237.9 MiB (92.93%) used: 104.7 MiB (44.0%) fs: ext4 dev: /dev/nvme1n1p2 Sensors: System Temperatures: cpu: 51.0 C mobo: N/A gpu: amdgpu temp: 46 C Fan Speeds (RPM): cpu: 0 Repos: No active apt repos in: /etc/apt/sources.list Active apt repos in: /etc/apt/sources.list.d/airvpn-stable.list 1: deb http://eddie.website/repository/apt stable main Active apt repos in: /etc/apt/sources.list.d/atom.list 1: deb [arch=amd64] https://packagecloud.io/AtomEditor/atom/any/ any main Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list 1: deb http://deb.debian.org/debian bullseye-updates main contrib non-free Active apt repos in: /etc/apt/sources.list.d/debian.list 1: deb http://deb.debian.org/debian bullseye main contrib non-free 2: deb http://security.debian.org/debian-security bullseye-security main contrib non-free Active apt repos in: /etc/apt/sources.list.d/mx.list 1: deb https://mirror.us.oneandone.net/linux/distributions/mx/packages/mx/repo/ bullseye main non-free 2: deb https://mirror.us.oneandone.net/linux/distributions/mx/packages/mx/repo/ bullseye ahs Active apt repos in: /etc/apt/sources.list.d/whonix.list 1: deb [signed-by=/usr/share/keyrings/derivative.asc] https://deb.whonix.org bullseye main contrib non-free Info: Processes: 376 Uptime: 1h 32m Memory: 62.24 GiB used: 5.99 GiB (9.6%) Init: SysVinit v: N/A runlevel: 5 default: 5 Compilers: gcc: 10.2.1 alt: 10 Shell: quick-system-in running in: quick-system-in inxi: 3.0.36 Any help would be much appreciated. Thanks. Eddie_20211227_134819.txt

Pegasus, US unconnectable. Fails with AUTH_FAILURE. Unfortunately it is currently selected by the DNS as the preferred US server. Connecting directly to Pollux (US) worked for me: I copied the US config (certs embedded) and changed the IP address. Here's a log for Pegasus (from right now, MTU notifications are from my own edits): 2021-09-26 04:29:38 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning. 2021-09-26 04:29:38 OpenVPN 2.5.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jun 17 2021 2021-09-26 04:29:38 Windows version 6.1 (Windows 7) 64bit 2021-09-26 04:29:38 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10 Enter Management Password: 2021-09-26 04:29:38 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25343 2021-09-26 04:29:38 Need hold release from management interface, waiting... 2021-09-26 04:29:38 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25343 2021-09-26 04:29:38 MANAGEMENT: CMD 'state on' 2021-09-26 04:29:38 MANAGEMENT: CMD 'log all on' 2021-09-26 04:29:38 MANAGEMENT: CMD 'echo all on' 2021-09-26 04:29:38 MANAGEMENT: CMD 'bytecount 5' 2021-09-26 04:29:38 MANAGEMENT: CMD 'hold off' 2021-09-26 04:29:38 MANAGEMENT: CMD 'hold release' 2021-09-26 04:29:38 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2021-09-26 04:29:38 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2021-09-26 04:29:38 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1250) 2021-09-26 04:29:38 MANAGEMENT: >STATE:1632655778,RESOLVE,,,,,, 2021-09-26 04:29:38 TCP/UDP: Preserving recently used remote address: [AF_INET]199.249.230.16:443 2021-09-26 04:29:38 Socket Buffers: R=[8192->262144] S=[8192->262144] 2021-09-26 04:29:38 UDP link local: (not bound) 2021-09-26 04:29:38 UDP link remote: [AF_INET]199.249.230.16:443 2021-09-26 04:29:38 MANAGEMENT: >STATE:1632655778,WAIT,,,,,, 2021-09-26 04:29:39 MANAGEMENT: >STATE:1632655779,AUTH,,,,,, 2021-09-26 04:29:39 TLS: Initial packet from [AF_INET]199.249.230.16:443, sid=83a14a89 9092e81f 2021-09-26 04:29:39 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org 2021-09-26 04:29:39 VERIFY KU OK 2021-09-26 04:29:39 Validating certificate extended key usage 2021-09-26 04:29:39 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-09-26 04:29:39 VERIFY EKU OK 2021-09-26 04:29:39 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Pegasus, emailAddress=info@airvpn.org 2021-09-26 04:29:39 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1372', remote='link-mtu 1558' 2021-09-26 04:29:39 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1250', remote='tun-mtu 1500' 2021-09-26 04:29:39 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 4096 bit RSA, signature: RSA-SHA512 2021-09-26 04:29:39 [Pegasus] Peer Connection Initiated with [AF_INET]199.249.230.16:443 2021-09-26 04:29:40 MANAGEMENT: >STATE:1632655780,GET_CONFIG,,,,,, 2021-09-26 04:29:40 SENT CONTROL [Pegasus]: 'PUSH_REQUEST' (status=1) 2021-09-26 04:29:40 AUTH: Received control message: AUTH_FAILED 2021-09-26 04:29:40 SIGUSR1[soft,auth-failure] received, process restarting 2021-09-26 04:29:40 MANAGEMENT: >STATE:1632655780,RECONNECTING,auth-failure,,,,, 2021-09-26 04:29:40 Restart pause, 5 second(s) 2021-09-26 04:29:45 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2021-09-26 04:29:45 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication 2021-09-26 04:29:45 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1250) 2021-09-26 04:29:45 TCP/UDP: Preserving recently used remote address: [AF_INET]199.249.230.16:443 2021-09-26 04:29:45 Socket Buffers: R=[8192->262144] S=[8192->262144] 2021-09-26 04:29:45 UDP link local: (not bound) 2021-09-26 04:29:45 UDP link remote: [AF_INET]199.249.230.16:443 2021-09-26 04:29:45 MANAGEMENT: >STATE:1632655785,WAIT,,,,,, 2021-09-26 04:29:46 MANAGEMENT: >STATE:1632655786,AUTH,,,,,, 2021-09-26 04:29:46 TLS: Initial packet from [AF_INET]199.249.230.16:443, sid=807e834f 86f4a62b 2021-09-26 04:29:46 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org CA, emailAddress=info@airvpn.org 2021-09-26 04:29:46 VERIFY KU OK 2021-09-26 04:29:46 Validating certificate extended key usage 2021-09-26 04:29:46 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-09-26 04:29:46 VERIFY EKU OK 2021-09-26 04:29:46 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=Pegasus, emailAddress=info@airvpn.org 2021-09-26 04:29:46 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1372', remote='link-mtu 1558' 2021-09-26 04:29:46 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1250', remote='tun-mtu 1500' 2021-09-26 04:29:46 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 4096 bit RSA, signature: RSA-SHA512 2021-09-26 04:29:46 [Pegasus] Peer Connection Initiated with [AF_INET]199.249.230.16:443 2021-09-26 04:29:47 MANAGEMENT: >STATE:1632655787,GET_CONFIG,,,,,, 2021-09-26 04:29:47 SENT CONTROL [Pegasus]: 'PUSH_REQUEST' (status=1) 2021-09-26 04:29:47 AUTH: Received control message: AUTH_FAILED 2021-09-26 04:29:47 SIGUSR1[soft,auth-failure] received, process restarting 2021-09-26 04:29:47 MANAGEMENT: >STATE:1632655787,RECONNECTING,auth-failure,,,,, 2021-09-26 04:29:47 Restart pause, 5 second(s) 2021-09-26 04:29:51 SIGTERM[hard,init_instance] received, process exiting 2021-09-26 04:29:51 MANAGEMENT: >STATE:1632655791,EXITING,init_instance,,,,, The server page shows Pegasus is chosen as the best server although Pegasus' stats show it has zero users and the drop happened a couple hours ago (Sunday 09:00 on the graph). Similar to my last post I propose that servers are ranked differently. Apparently this time an end-to-end test using OpenVPN is required since the server is reachable but it has got issues with authentication.

Hot off the press! Arstechnica 'VPN servers seized by Ukrainian authorities weren’t encrypted' Why did they wait almost 2 weeks? The post was published on July 9th. The blog post seems to rather be in full damage control mode than to admit how much of a failure it was that it apparently contained the single VPN certificate shared across all servers. (looks like I got it wrong read first reply) On top of that a technically incorrect explanation of when this acquired certificate can be successfully exploited. I don't wanna rant right now but will expand on my points when asked. I'm also curious whether AirVPN actually keeps all sensitive data in RAM as stated in the Torrentfreak article: Although I don't see that Windscribe had actually lied about any of their stuff (beyond omissions in current damage control), can we be sure AirVPN actually has all of the above implemented? Though I like how specific the response in the description. Also AMD's Zen CPUs are currently the only ones on the market (in x86 space fore sure) with actual RAM encryption. Having data on RAM disk wouldn't be enough for a prepared attacker due to technical possibility of extracting the data in a cold boot attack. Such an upgrade would not only take a while for the infrastructure and but be costly.

Quality of Service post: Although it is a 10Gbit server it seems to be suffering. I'm from Europe and checking its ping shows average 344ms over 234 attempts. This puts it in range of JP and NZ servers at 350ms. This is not the first time I've seen it perform poorly. Last week I connected to se.vpn.airdns.org (and it still shows as the preferred choice in API and https://airvpn.org/status/ EDIT: not any longer as of finishing writing) and had the same problems downloading a file with speed jumping up and down. To get the ping results I filtered the API JSON into an IP list to use with Nirsoft PingInfoView: https://www.nirsoft.net/utils/multiple_ping_tool.html Current IP list: (if you read this post at a later date: it is not up to date!) sortscript.sh | sort -k2 185.9.19.106 at, Alderamin (Austria, Vienna; 1000) 37.120.155.178 at, Beemim (Austria, Vienna; 1000) 217.64.127.194 at, Caelum (Austria, Vienna; 1000) 194.187.251.90 be, Capricornus (Belgium, Brussels; 1000) 91.207.57.114 be, Castor (Belgium, Brussels; 1000) 194.187.251.114 be, Columba (Belgium, Brussels; 1000) 194.187.251.162 be, Diadema (Belgium, Brussels; 1000) 194.187.251.154 be, Mebsuta (Belgium, Brussels; 1000) 82.102.23.130 bg, Apus (Bulgaria, Sofia; 1000) 82.102.23.138 bg, Grus (Bulgaria, Sofia; 1000) 45.162.229.146 br, Lalande (Brazil, Sao Paulo; 1000) 45.162.228.170 br, Peony (Brazil, Sao Paulo; 1000) 184.75.223.210 ca, Agena (Canada, Toronto, Ontario; 1000) 162.219.176.2 ca, Alhena (Canada, Toronto, Ontario; 1000) 184.75.221.202 ca, Alkurhah (Canada, Toronto, Ontario; 1000) 104.254.90.202 ca, Aludra (Canada, Toronto, Ontario; 1000) 184.75.221.114 ca, Alwaid (Canada, Toronto, Ontario; 1000) 184.75.221.170 ca, Alya (Canada, Toronto, Ontario; 1000) 184.75.221.162 ca, Angetenar (Canada, Toronto, Ontario; 1000) 184.75.221.210 ca, Arkab (Canada, Toronto, Ontario; 1000) 184.75.223.234 ca, Avior (Canada, Toronto, Ontario; 1000) 184.75.214.162 ca, Cephei (Canada, Toronto, Ontario; 1000) 104.254.90.234 ca, Chort (Canada, Toronto, Ontario; 1000) 104.254.90.242 ca, Enif (Canada, Toronto, Ontario; 1000) 104.254.90.250 ca, Gorgonea (Canada, Toronto, Ontario; 1000) 87.101.92.170 ca, Lacerta (Canada, Montreal; 1000) 184.75.221.2 ca, Lesath (Canada, Toronto, Ontario; 1000) 184.75.223.218 ca, Mintaka (Canada, Toronto, Ontario; 1000) 192.30.89.66 ca, Nahn (Canada, Vancouver; 1000) 192.30.89.26 ca, Pisces (Canada, Vancouver; 1000) 184.75.221.34 ca, Regulus (Canada, Toronto, Ontario; 1000) 139.28.218.234 ca, Ross (Canada, Montreal; 1000) 104.254.90.186 ca, Rotanev (Canada, Toronto, Ontario; 1000) 184.75.221.178 ca, Sadalbari (Canada, Toronto, Ontario; 1000) 184.75.223.226 ca, Saiph (Canada, Toronto, Ontario; 1000) 184.75.223.194 ca, Sargas (Canada, Toronto, Ontario; 1000) 192.30.89.74 ca, Sham (Canada, Vancouver; 1000) 104.254.90.194 ca, Sharatan (Canada, Toronto, Ontario; 1000) 184.75.221.42 ca, Sualocin (Canada, Toronto, Ontario; 1000) 137.63.71.50 ca, Tegmen (Canada, Toronto, Ontario; 1000) 184.75.221.194 ca, Tejat (Canada, Toronto, Ontario; 1000) 192.30.89.50 ca, Telescopium (Canada, Vancouver; 1000) 192.30.89.58 ca, Titawin (Canada, Vancouver; 1000) 184.75.223.202 ca, Tyl (Canada, Toronto, Ontario; 1000) 184.75.221.58 ca, Ukdah (Canada, Toronto, Ontario; 1000) 185.156.175.170 ch, Achernar (Switzerland, Zurich; 1000) 185.156.175.34 ch, Achird (Switzerland, Zurich; 1000) 185.156.175.50 ch, Baiten (Switzerland, Zurich; 1000) 195.206.105.226 ch, Dorado (Switzerland, Zurich; 1000) 185.156.175.42 ch, Hamal (Switzerland, Zurich; 1000) 91.214.169.68 ch, Kitalpha (Switzerland, Zurich; 1000) 195.206.105.202 ch, Sextans (Switzerland, Zurich; 1000) 185.156.175.58 ch, Sirrah (Switzerland, Zurich; 1000) 46.19.137.114 ch, Virginis (Switzerland, Bern; 1000) 79.142.69.159 ch, Xuange (Switzerland, Zurich; 10000) 185.156.174.114 cz, Centaurus (Czech Republic, Prague; 1000) 185.156.174.26 cz, Markab (Czech Republic, Prague; 1000) 185.156.174.154 cz, Turais (Czech Republic, Prague; 1000) 89.238.166.234 cz, Zuben (Czech Republic, Prague; 1000) 185.104.184.42 de, Adhara (Germany, Frankfurt; 1000) 141.98.102.186 de, Alsephina (Germany, Frankfurt; 1000) 185.189.112.26 de, Cervantes (Germany, Frankfurt; 1000) 37.120.217.242 de, Cujam (Germany, Berlin; 1000) 141.98.102.242 de, Dubhe (Germany, Frankfurt; 1000) 185.189.112.10 de, Errai (Germany, Frankfurt; 1000) 178.162.204.227 de, Intercrus (Germany, Frankfurt; 1000) 141.98.102.226 de, Menkalinan (Germany, Frankfurt; 1000) 79.143.191.166 de, Mesarthim (Germany, Munich; 1000) 141.98.102.234 de, Mirfak (Germany, Frankfurt; 1000) 141.98.102.178 de, Mirzam (Germany, Frankfurt; 1000) 185.189.112.18 de, Ogma (Germany, Frankfurt; 1000) 178.162.209.151 de, Serpens (Germany, Frankfurt; 1000) 178.162.204.219 de, Tucana (Germany, Frankfurt; 1000) 178.162.204.222 de, Veritate (Germany, Frankfurt; 1000) 185.195.237.202 ee, Alruba (Estonia, Tallinn; 1000) 185.183.106.2 es, Eridanus (Spain, Barcelona; 1000) 185.93.182.170 es, Mekbuda (Spain, Madrid; 1000) 194.99.104.34 es, Taurus (Spain, Madrid; 1000) 185.103.96.132 gb, Alathfar (United Kingdom, Maidenhead; 1000) 217.151.98.162 gb, Alshain (United Kingdom, London; 1000) #89.238.150.42 gb, Arion (United Kingdom, London; 1000) 217.151.98.167 gb, Asterion (United Kingdom, London; 1000) 89.249.74.212 gb, Asterope (United Kingdom, Manchester; 1000) 185.103.96.134 gb, Betelgeuse (United Kingdom, Maidenhead; 1000) 94.229.74.90 gb, Carinae (United Kingdom, Maidenhead; 1000) 89.249.74.217 gb, Chow (United Kingdom, Manchester; 1000) 185.103.96.133 gb, Denebola (United Kingdom, Maidenhead; 1000) 2.58.47.202 gb, Geminorum (United Kingdom, London; 1000) 185.103.96.131 gb, Kitel (United Kingdom, Maidenhead; 1000) 185.103.96.130 gb, Minkar (United Kingdom, Maidenhead; 1000) 84.39.117.56 gb, Naos (United Kingdom, Manchester; 1000) 84.39.116.179 gb, Nashira (United Kingdom, Manchester; 1000) 192.145.126.114 gb, Orbitar (United Kingdom, Manchester; 1000) 141.98.101.132 gb, Westerlund (United Kingdom, Manchester; 1000) 37.120.210.210 jp, Biham (Japan, Tokyo; 1000) 82.102.28.106 jp, Iskandar (Japan, Tokyo; 1000) 37.120.210.218 jp, Okab (Japan, Tokyo; 1000) 193.148.16.210 jp, Taphao (Japan, Tokyo; 1000) 46.183.220.202 lv, Felis (Latvia, Riga; 1000) #159.148.186.13 lv, Meissa (Latvia, Riga; 100) 159.148.186.18 lv, Phact (Latvia, Riga; 100) 159.148.186.24 lv, Schedir (Latvia, Riga; 100) 159.148.186.31 lv, Shaula (Latvia, Riga; 100) 213.152.161.180 nl, Alchiba (Netherlands, Alblasserdam; 1000) 213.152.161.116 nl, Alcyone (Netherlands, Alblasserdam; 1000) 134.19.179.170 nl, Aljanah (Netherlands, Alblasserdam; 1000) 213.152.187.199 nl, Alphard (Netherlands, Alblasserdam; 1000) 213.152.187.194 nl, Alphecca (Netherlands, Alblasserdam; 1000) 134.19.179.242 nl, Alpheratz (Netherlands, Alblasserdam; 1000) 213.152.187.214 nl, Alphirk (Netherlands, Alblasserdam; 1000) 213.152.162.78 nl, Alrai (Netherlands, Alblasserdam; 1000) 213.152.161.4 nl, Alshat (Netherlands, Alblasserdam; 1000) 213.152.161.169 nl, Alterf (Netherlands, Alblasserdam; 1000) 213.152.187.204 nl, Alzirr (Netherlands, Alblasserdam; 1000) 213.152.162.164 nl, Ancha (Netherlands, Alblasserdam; 1000) 213.152.161.228 nl, Andromeda (Netherlands, Alblasserdam; 1000) 213.152.186.18 nl, Anser (Netherlands, Alblasserdam; 1000) 213.152.187.209 nl, Asellus (Netherlands, Alblasserdam; 1000) 134.19.179.194 nl, Aspidiske (Netherlands, Alblasserdam; 1000) 213.152.161.9 nl, Atik (Netherlands, Alblasserdam; 1000) 213.152.161.218 nl, Canis (Netherlands, Alblasserdam; 1000) 134.19.179.138 nl, Capella (Netherlands, Alblasserdam; 1000) 213.152.162.169 nl, Caph (Netherlands, Alblasserdam; 1000) 213.152.161.68 nl, Celaeno (Netherlands, Alblasserdam; 1000) 213.152.187.219 nl, Chara (Netherlands, Alblasserdam; 1000) 213.152.186.162 nl, Comae (Netherlands, Alblasserdam; 1000) 213.152.162.14 nl, Crater (Netherlands, Alblasserdam; 1000) 213.152.161.243 nl, Cygnus (Netherlands, Alblasserdam; 1000) 213.152.161.164 nl, Diphda (Netherlands, Alblasserdam; 1000) 213.152.161.210 nl, Edasich (Netherlands, Alblasserdam; 1000) 213.152.186.39 nl, Elnath (Netherlands, Alblasserdam; 1000) 134.19.179.146 nl, Eltanin (Netherlands, Alblasserdam; 1000) 213.152.162.73 nl, Garnet (Netherlands, Alblasserdam; 1000) 213.152.161.100 nl, Gianfar (Netherlands, Alblasserdam; 1000) 213.152.162.93 nl, Gienah (Netherlands, Alblasserdam; 1000) 213.152.161.39 nl, Hassaleh (Netherlands, Alblasserdam; 1000) 213.152.162.4 nl, Horologium (Netherlands, Alblasserdam; 1000) 213.152.161.34 nl, Hyadum (Netherlands, Alblasserdam; 1000) 213.152.162.9 nl, Hydrus (Netherlands, Alblasserdam; 1000) 213.152.186.23 nl, Jabbah (Netherlands, Alblasserdam; 1000) 213.152.161.84 nl, Kajam (Netherlands, Alblasserdam; 1000) 213.152.162.180 nl, Kocab (Netherlands, Alblasserdam; 1000) 134.19.179.178 nl, Larawag (Netherlands, Alblasserdam; 1000) 213.152.186.167 nl, Luhman (Netherlands, Alblasserdam; 1000) 213.152.162.103 nl, Maasym (Netherlands, Alblasserdam; 1000) 213.152.187.224 nl, Matar (Netherlands, Alblasserdam; 1000) 134.19.179.162 nl, Melnick (Netherlands, Alblasserdam; 1000) 213.152.161.29 nl, Merga (Netherlands, Alblasserdam; 1000) 213.152.162.68 nl, Mirach (Netherlands, Alblasserdam; 1000) 213.152.162.88 nl, Miram (Netherlands, Alblasserdam; 1000) 134.19.179.202 nl, Muhlifain (Netherlands, Alblasserdam; 1000) 213.152.162.153 nl, Muscida (Netherlands, Alblasserdam; 1000) 213.152.161.248 nl, Musica (Netherlands, Alblasserdam; 1000) 213.152.161.24 nl, Nash (Netherlands, Alblasserdam; 1000) 213.152.161.238 nl, Orion (Netherlands, Alblasserdam; 1000) 213.152.187.229 nl, Phaet (Netherlands, Alblasserdam; 1000) 134.19.179.130 nl, Piscium (Netherlands, Alblasserdam; 1000) 213.152.162.148 nl, Pleione (Netherlands, Alblasserdam; 1000) 213.152.161.233 nl, Pyxis (Netherlands, Alblasserdam; 1000) 213.152.162.83 nl, Rukbat (Netherlands, Alblasserdam; 1000) 213.152.161.19 nl, Salm (Netherlands, Alblasserdam; 1000) 134.19.179.154 nl, Scuti (Netherlands, Alblasserdam; 1000) 213.152.186.34 nl, Sheliak (Netherlands, Alblasserdam; 1000) 213.152.161.14 nl, Situla (Netherlands, Alblasserdam; 1000) 213.152.162.98 nl, Subra (Netherlands, Alblasserdam; 1000) 134.19.179.186 nl, Suhail (Netherlands, Alblasserdam; 1000) 213.152.161.137 nl, Talitha (Netherlands, Alblasserdam; 1000) 213.152.161.132 nl, Tarazed (Netherlands, Alblasserdam; 1000) 134.19.179.234 nl, Tiaki (Netherlands, Alblasserdam; 1000) 213.152.186.172 nl, Tianyi (Netherlands, Alblasserdam; 1000) 213.152.161.148 nl, Zibal (Netherlands, Alblasserdam; 1000) 82.102.27.194 no, Camelopardalis (Norway, Oslo; 1000) 82.102.27.170 no, Cepheus (Norway, Oslo; 1000) 185.206.225.50 no, Fomalhaut (Norway, Oslo; 1000) 82.102.27.162 no, Gemini (Norway, Oslo; 1000) 185.206.225.58 no, Ophiuchus (Norway, Oslo; 1000) 103.231.91.58 nz, Fawaris (New Zealand, Auckland; 1000) 91.207.102.162 ro, Alamak (Romania, Bucharest; 1000) 86.105.9.66 ro, Canes (Romania, Bucharest; 1000) 152.89.160.130 rs, Alnitak (Serbia, Belgrade; 1000) 128.127.104.79 se, Ain (Sweden, Stockholm; 10000) 62.102.148.149 se, Albali (Sweden, Uppsala; 1000) 62.102.148.142 se, Algieba (Sweden, Uppsala; 1000) 62.102.148.147 se, Algorab (Sweden, Uppsala; 1000) 62.102.148.145 se, Alrami (Sweden, Uppsala; 1000) 62.102.148.140 se, Altarf (Sweden, Uppsala; 1000) 62.102.148.151 se, Alula (Sweden, Uppsala; 1000) 62.102.148.150 se, Atria (Sweden, Uppsala; 1000) 62.102.148.141 se, Azmidiske (Sweden, Uppsala; 1000) 62.102.148.148 se, Benetnasch (Sweden, Uppsala; 1000) 79.142.76.243 se, Copernicus (Sweden, Stockholm; 1000) 62.102.148.144 se, Hatysa (Sweden, Uppsala; 1000) 128.127.105.183 se, Lupus (Sweden, Stockholm; 1000) 62.102.148.143 se, Menkab (Sweden, Uppsala; 1000) 62.102.148.146 se, Muphrid (Sweden, Uppsala; 1000) 31.3.152.99 se, Norma (Sweden, Stockholm; 1000) 103.254.153.68 sg, Antares (Singapore, Singapore; 1000) 185.200.116.210 sg, Auriga (Singapore, Singapore; 1000) 185.200.116.202 sg, Circinus (Singapore, Singapore; 1000) 185.200.116.218 sg, Delphinus (Singapore, Singapore; 1000) 185.200.117.130 sg, Hydra (Singapore, Singapore; 1000) 209.58.173.142 sg, Lacaille (Singapore, Singapore; 1000) 92.119.178.2 sg, Luyten (Singapore, Singapore; 1000) 209.58.183.86 sg, Struve (Singapore, Singapore; 1000) 185.200.116.130 sg, Triangulum (Singapore, Singapore; 1000) 91.231.84.39 ua, Alcor (Ukraine, Kiev; 1000) 173.44.55.154 us, Acamar (United States, Miami; 1000) 107.167.244.66 us, Alkes (United States, Los Angeles; 1000) 199.249.223.129 us, Aquila (United States, Fremont, California; 1000) 193.37.254.2 us, Bootes (United States, Phoenix, Arizona; 1000) 193.37.254.18 us, Chalawan (United States, Phoenix, Arizona; 1000) 199.249.230.41 us, Chamaeleon (United States, Dallas, Texas; 1000) 96.47.229.58 us, Cursa (United States, Miami; 1000) 185.228.19.146 us, Dimidium (United States, New York City; 1000) 199.249.230.36 us, Equuleus (United States, Dallas, Texas; 1000) 68.235.48.107 us, Fang (United States, Chicago, Illinois; 1000) 91.132.0.202 us, Gliese (United States, New York City; 1000) 37.120.132.82 us, Groombridge (United States, Los Angeles; 1000) 199.249.230.46 us, Helvetios (United States, Dallas, Texas; 1000) 64.42.179.58 us, Hercules (United States, Atlanta, Georgia; 1000) 193.37.254.26 us, Indus (United States, Phoenix, Arizona; 1000) 68.235.35.123 us, Kruger (United States, Chicago, Illinois; 1000) 199.249.230.21 us, Leo (United States, Dallas, Texas; 1000) 64.42.179.66 us, Libra (United States, Atlanta, Georgia; 1000) 194.36.111.58 us, Lich (United States, New York City; 1000) 199.249.230.6 us, Mensa (United States, Dallas, Texas; 1000) 107.167.244.50 us, Merope (United States, Los Angeles; 1000) 156.96.151.131 us, Metallah (United States, Pennsylvania; 1000) 64.42.179.42 us, Musca (United States, Atlanta, Georgia; 1000) 199.249.230.16 us, Pegasus (United States, Dallas, Texas; 1000) 193.37.254.34 us, Phoenix (United States, Phoenix, Arizona; 1000) 198.203.28.42 us, Pollux (United States, Jacksonville, Florida; 1000) 199.249.230.26 us, Ran (United States, Dallas, Texas; 1000) 107.167.244.82 us, Sabik (United States, Los Angeles; 1000) 64.42.179.34 us, Sculptor (United States, Atlanta, Georgia; 1000) 199.249.230.11 us, Scutum (United States, Dallas, Texas; 1000) 68.235.52.35 us, Sneden (United States, Chicago, Illinois; 1000) 37.120.132.90 us, Teegarden (United States, Los Angeles; 1000) 64.42.179.50 us, Ursa (United States, Atlanta, Georgia; 1000) 193.37.254.10 us, Virgo (United States, Phoenix, Arizona; 1000) 199.249.230.31 us, Volans (United States, Dallas, Texas; 1000) 199.249.230.1 us, Vulpecula (United States, Dallas, Texas; 1000) 173.44.55.178 us, Yildun (United States, Miami; 1000) I believe it doesn't affect Eddie as it can pick servers on its own by pinging. But the "preferred" server and DNS responses are still dependent on the server logic, hence Ain sometimes ends up recommended as Earth or Europe server (currently not any longer) but seems to always be the preferred choice for Sweden. To quantify that, it's 350 out of 755 users connected to Swedish servers and unnecessarily getting insane jitter and latencies. To proof it's not just me, https://lg.telia.net/ from AMS-IX showed 24ms to another Swedish server by AirVPN and approx. 340ms to Ain. Or AirVPN's own lookup: https://airvpn.org/routes/?q=128.127.104.79 PS: Is it an Intel CPU? Edit: What I meant to say with this post (not only to start investigating Ain) that the "best server" logic should be not only working based on bandwidth load, but the server's relative latency times. PS2: I do realize that it's currently listed as having issues (packet loss) but during my last week's connect afaik it wasn't. Logically, jitter/high latency begins before packet loss kicks in (networking and throughput theory) - https://airvpn.org/servers/Ain/

Currently AirVPN servers ONLY provide you with IPv6 connectivity (IPv6 traffic via VPN) if OpenVPN correctly pushes a certain value to the server. This is what the relevant config lines look like: push-peer-info setenv UV_IPV6 yes 'UV_IPV6 yes' is a variable that is set to 'yes', basically: yes, gimme IPv6 push-peer-info sends the server information about the client. This includes: OS version and OpenVPN client release, your router's MAC address and of course the UV_IPV6 variable that tells the server to give you an IPv6 address. This last part is problematic and has already led to problems for AirVPN users: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/556 I've run into this issue myself when I tried to get AirVPN running on Linux using the NetworkManager interface (present in virtually every distro out there). It's confusing because it seems to work but in reality it doesn't. You do get a connection, except without IPv6 forwarding. It's no surprise people encounter this: Why would one really need to install your client if the preinstalled GUI manager has worked fine before? Nobody knows the intricacies. Not even those who reported the issue to the correct place above! *drum-roll* and the problem is: NetworkManager. Really. NetworkManager is crippled in that it DOES NOT support many of the OpenVPN features. The combination of push-peer-info + setenv is one of them. The variable is not set upon connection -> VPN connects to the server -> The server does not see UV_IPV6=yes -> The server only setups IPv4 for the client. Yes, THIS IS A SECURITY ISSUE. According to Google, 32% of users have IPv6. Here come you, an AirVPN user with IPv4 and IPv6 on Linux, using NetworkManager. It seems to connect. You quickly check a website to see your IP and see that you indeed got a new IP (IPv4) after connecting to the VPN. Maybe the website doesn't show IPv6 at all, or the user doesn't pay attention to the fact this long and cryptic IPv6 didn't change or maybe the user did not yet have IPv6 and it was enabled later by the ISP... And there the user goes to surf online with half his ass naked: IPv4 is properly routed through AirVPN but IPv6 is still going through his real ISP. This must be changed. IPv6 must be the default. Do not leave a chance to expose users. When this change is applied, both config lines will be rendered obsolete and as a bonus, the clients will no longer unnecessarily send their internal MAC addresses to the server, which can be used too: - https://threatpost.com/fbi-mum-on-how-exactly-it-hacked-tor/117127/ | https://www.theregister.com/2018/02/24/tor_fbi_hacking_appeal/ - https://web.archive.org/web/20180923231303/https://blog.owenson.me/analysis-of-the-fbi-tor-malware/ Finally if you feel there's someone who really wishes to not use IPv6 via Air: reverse the config. Make it an explicit UV_IPV6=no to opt-out. Security must be the default. Thanks for reading. I really hope this change to be introduced soon. PS: Can someone login at the Freedesktop bug tracker above to tell these people that it's fixable? I don't have an account PPS: You can see what push-peer-info sends if you set verbosity to 4: "verb 4" in the config Tags: IPv6 not working AirVPN Linux config openvpn

This guide will explain how to setup OpenVPN in a way such that only select programs will be able to use the VPN connection while all other life continues as usual. Please read this notice before applying the guide Advantages: fail-free "kill switch" functionality (actually better than 98% of VPNs out there) continue using another VPN as primary or don't reroute any other traffic at all nobody, not even peers on LAN, will be able to connect to your torrent client (the only way: through the VPN connection) - eliminating unintended leaks Disadvantage: the apps will still use your default DNS for hostname lookups (secure your DNS separately!) See two more drawings at the end. The guide is applicable to all VPN providers who don't restrict their users to use the OpenVPN client. The method however is universally applicable. It was made with examples from Windows, but with Linux/BSD you will only need little tweaking to do. Specifically, net_gateway placeholder may not available and that's all there is to it. Android clients are probably too limited for this task and lack options we need. - Since there'll be a lot of text, sections titled in (parantheses) are entirely optional to read. The other guide by NaDre is old (2013), hard to read and pursues a slightly different approach. A Staff member actually posted a good first comment there, that's what we're gonna do. (Preface) The BitTorrent as a network is entirely public. Through the decentralized technology called DHT, everyone in the world can find out what torrents you are presumably participating in (this does not apply to private trackers who disable DHT). Clearly this creates an unhealthy atmosphere for privacy of users, e.g. one could find out the OS distribution one is using for a more targetted attack etc. Sometimes the ISPs are outright hostile to peer-to-peer technologies due to the traffic and bandwidth these are consuming. Instead of upgrading dated infrastructure, they cripple their users instead. There are many reasons to use a VPN, that was but a limited selection. ("Split-tunneling") This has become somewhat a marketing term nowadays, but actually explains the nature of the traffic flow well. In this guide only the programs set to use the VPN connection will use it, nothing else. All your traffic goes past the VPN while torrent client traffic (or any other selected program) uses only the VPN connection. ("Kill switch") We'll literally nail it using software settings of your program (the torrent client). This is a marketing-loaded name. In short: if the VPN connection is not available, no traffic ought to be sent bypassing it. In most cases where you have a VPN redirect all your system traffic - you should not rely on it as a feature. The OpenVPN software on Windows is not 100% proof, based on empirical evidence (reconnects and startup/shutdown phases) and some other VPN providers do no better (based on comments and stories). The only bulletproof solution: the VPN tunnel is set up on an intermediary device your PC is connected to - your end device (the PC) has no chance whatsoever to bypass the tunnel in that case. If the VPN provider uses a firewall under the hood, that's good too but with this guide you will not need a firewall nor rely on the VPN software. ("Dual-hop") With the knowledge and methods from this guide you will be able to daisy-chain multiple VPN servers. In essence, your traffic passes PC->VPN1->VPN2->Destination. This was not intended for this guide nor with AirVPN, it's finicky and I wouldn't recommend it myself without a real need and skills to automate the setup and configuration. How it will work Many users (aka mostly idiots on Reddit) are running in circles like qBittorrent is the only client (or probably the only application in the universe, unconfirmed) that can be set to use a certain VPN. Here's the technicality: this is called 'binding' - you can 'bind to IP' which will force the app to use a specific IP address and nothing else. If it cannot use the IP (when VPN is disconnected) then it will not be able to do any networking at all. The OS will deny any communication with the internet: boom! Here's your praised 'kill switch' and 'split-tunneling', 2-in-1. This is the next best bulletproof solution (the only better alternative is to use an intermediary VPN device, as any software could choose a different interface now to communicate with the internet). In a broader sense, you want to 'bind to a network interface' - your client will use any available IPs from the VPN interface - making it ready for IPv4 and IPv6. Oh and you don't need to change the IP once the VPN connection changes to another server. The OS handles the rest. Examples of programs that can bind to user-defined addresses include: (Windows) ping, tracert (IPv6-only, WTF?), curl and wget, and many others, including your favorite torrent client You will find guides online how to do that in your client or just look in settings. (Linux-specific differences of the guide) If you are a Linux/*nix user, there're some minor changes to the quick guide below: * Create custom VPN interface: Create with ip tuntap command. The below line will create 5 interfaces "tun-air1" etc. for YOUR user. Specifying your user allows OpenVPN to drop root rights after connection and run under your user (security). AirVPN allows up to 5 connections. If you have no use for this, create only one. Note: User-owned tunnel interfaces allow to be used by your non-root $user account, but there're issues with running OpenVPN without elevated permissions as $user user="$(whoami)"; for i in {1..5}; do sudo ip tuntap add dev "tun-airvpn$i" mode tun user "$user" group "$user"; done Check their existance with ip -d a -- the interfaces will not be shown under /dev/tun* ALTERNATIVE: openvpn --mktap/--mktun. See manual with man openvpn * Select custom VPN interface: This config part differs from Windows, very confusing. Steps: 1. Replace "dev-node" in config with "dev" 2. Add "dev-type tun" or "tap". Example of config: # if you have these defined multiple times, last entries override previous entries dev tun-airvpn1 # previously dev-node dev-type tun # previously "dev tun" on Windows There're no more differences. In-depth explanation: If you try to use dev-node like for Windows, you will see: OpenVPN log: ERROR: Cannot open TUN/TAP dev /dev/tun-airvpn1: No such file or directory (errno=2) Example strace of error: openat(AT_FDCWD, "/dev/tun-airvpn1", O_RDWR) = -1 ENOENT (No such file or directory) OpenVPN cannot find the TUN/TAP with the name? No, on Linux/*nix/*BSD dev-node has a totally different meaning. Dev-node specifies where the control interface with the kernel is located. On Linux it's usually /dev/node/tun, for the "mknode" command. If OpenVPN can't detect it for some reason, then you'd need to use dev-node. Finally you can start OpenVPN from terminal: sudo openvpn --config 'path/to/config.ovpn' --user mysystemusername --group mysystemusergroup PS: There're issues when running OpenVPN under your current $user. I think the problem was that it couldn't remove added routes after a disconnect. Instead run OpenVPN as root (isn't a good advice but it's what works) Windows Quick Guide Go to the folder where you installed OpenVPN and its exe files: 'C:\Program Files\OpenVPN\' Open CMD inside the 'bin' folder: Hold Shift + Right Click the 'bin' folder -> 'Open Command Window here' We will use tapctl.exe to create a new VPN network interface solely for use with AirVPN (to look around: run "tapctl.exe" or "tapctl.exe help") C:\Program Files\OpenVPN\bin>tapctl create --name AirVPN-TAP {FDA13378-69B9-9000-8FFE-C52DEADBEEF0} C:\Program Files\OpenVPN\bin> A TAP interface is created by default. I have not played enough with Wireguard's TUN to recommend it. You can check it out, it will be under adapters in your Windows network settings Important: Configure your app/torrent client to use this 'AirVPN-TAP' interface. This is what ensures your traffic never leaks. It may appear under a different name, in such case find out which one it is in the output of 'ipconfig /all' (enter this into CMD) If your client does not allow to bind to a general interface but a specific IP (poor decision) then connect to the VPN first to find out the local IP within the VPN network. In this case with AirVPN you may only use one single server or you'll have to constantly change the IP in settings. Generate AirVPN configs where you connect to the server via IPv4! This is important Add these to the .ovpn config files (either under 'Advanced' on the config generator page or manually to each config file) # NOPULL START route-nopull # IF YOU DO NOT USE ANOTHER VPN THAT TAKES OVER ALL YOUR TRAFFIC, USE "net_gateway" (just copy-paste all of this) # net_gateway WILL BE AUTOMATICALLY DETERMINED AND WILL WORK IF YOU CONNECT THROUGH OTHER NETWORKS LIKE A PUBLIC WIFI # personally, due to a second VPN, I had to specify my router IP explicitly instead of net_gateway: 192.168.69.1 # "default"/"vpn_gateway"/"remote_host"/"net_gateway" are allowed placeholders for IPv4 route remote_host 255.255.255.255 net_gateway route 10.0.0.0 255.0.0.0 vpn_gateway route 0.0.0.0 0.0.0.0 default 666 route-ipv6 ::/0 default 666 dev-node AirVPN-TAP # END OF NOPULL Test if the configuration works. Full tests, don't leave it up to chance. In-depth explanation of the OpenVPN config route-nopull rejects any networking routes pushed to you by the server, we will write our own route remote_host 255.255.255.255 <router IP> we tell our system that, to reach remote_host (the AirVPN server IP), it must send traffic to <router IP>. The subnet mask 255.255.255.255 says that this only applies to this single IP set <router IP> to be net_gateway (only for Windows users, check availability on other platforms) <router IP> may be any of the OpenVPN placeholders too, for example "net_gateway" should work universally (you avoid hard-coding the router IP and if it ever changes: wondering years later why the config no longer works) <router IP> is "192.168.1.1" in my case, for my home router that connects me to the internet. route 10.0.0.0 255.0.0.0 vpn_gateway we tell our system that all 10.x.x.x traffic will be sent to the AirVPN server the internal VPN network with AirVPN is always on the 10.0.0.0 - 10.255.255.255 network range. The subnet mask reflects that. However this may interfere with other VPNs if you ever need to be connected to both at once. I will not go into detail on this. What you need to do is to be more specific with 10.x.x.x routes in this config, i.e. instead of /8 subnet, only route the specific /24 subnet of the current VPN server (AirVPN uses a /24 subnet for your connections on each VPN server -> 10.a.b.0 255.255.255.0) vpn_gateway is one of OpenVPN placeholders route 0.0.0.0 0.0.0.0 default 666 allow routing of ANY traffic via the VPN we set the metric to 666, metric defined as path cost (historically) so setting it to a high value will make sure no normal connection runs through it, unless specifically bound to the VPN IP. route-ipv6 ::/0 default 666 same for IPv6. How many can claim they have working VPN IPv6 setup? Welcome in the future. IPv6 is over 20 years old at this point anyhow. dev-node AirVPN-TAP (Windows-only) tell OpenVPN to ONLY use this network interface to create the VPN tunnel on. Nothing should interfere with our setup now That's all, folks! Note: Somehow on Windows my AirVPN connection receives a wrong internal IP that doesn't enable networking at first. In my case I need to wait 1-3 minutes until OpenVPN reconnects itself based on ping timeout: after the reconnect I receive another IP and everything starts to work. I do not know whether it's an OpenVPN or a Windows bug. One last note: using multiple VPNs Actually this will work, that's how I roll. As long as both VPNs don't clash by using the same 10.0.0.0/8 subnet. If this happens, you will need to change Line 5 to point to a more specific (aka smaller) subnet tailored to your AirVPN server. Specifying a 10.x.x.0/24 subnet for routing will surely do (subnet mask: 255.255.255.0). Just be aware that you cannot practically use the same IP range in both networks at the same time (well, you'd need to bind the application you are using to either interface, which you cannot do with a browser or the printing service in case of internal resources). (The story of broken net_gateway) For this placeholder, OpenVPN attempts to determine your 'default gateway', i.e. the router all your internet traffic passes through. It normally works, but may not be supported on other platforms (Linux, sigh). However it has one unintended side-effect: if you already have a VPN that reroutes all your traffic, net_gateway will make all AirVPN traffic go through the first VPN: Your traffic -> VPN1 -> Internet Torrent traffic -> VPN1 -> AirVPN -> Internet That's the unintended dual-hop. Surely you can extend that scheme to 3,4,n-hops if you fiddle enough with routing, subnet masks and correct order. I'm not responsible for headaches We avoid that behavior with Line 4 from our config - the remote_host line forces the AirVPN traffic to go straight to the internet (through your LAN router). One more thing: net_gateway is not available for IPv6 routes in OpenVPN. That's why it currently only works with a IPv4 connection to the VPN server. (Crash course: Subnet masks) You've seen the weird number 255.0.0.0 above. You should refer to other pages for a proper explanation, but basically this is a very simple way for computers to determine the range of IP addresses that are part of a network (a subnet). What's simple for computers is very hard to grasp for us humans. 255 means there are NO changes allowed to the first set of IP numbers. I.e. the 10 in 10.0.0.0 always stays a 10. 0 means all numbers can be used. I.e. the zeroes in 10.0.0.0 can be (0-255), lowest address is 10.0.0.1 and the last address is 10.255.255.254 (technically, 10.0.0.0 is the first and the last 10.255.255.255 is reserved for 'broadcast') Any number in between denotes ... a range in between. 2^(32-prefix)=number. Number is the amount of available addresses and prefix is called the subnet prefix. Both are meant to describe the same thing. For 10.0.0.0/26 or 10.0.0.0 with subnet mask of 255.255.255.192 you get addresses in range 10.0.0.0-10.0.0.64 -- 2^(32-26) = 64. Similarly you can convert the subnet mask into the prefix number and work from there; or eyeball it: 256-192 = 64. (Two ways to accomplish routing) If you have two equal routes, e.g. 0.0.0.0 goes through VPN with metric 666 0.0.0.0 goes through LAN router with metric 10 then obviously the default route for a packet will travel through (2) - because it's a cheaper path. Unless an application specifies to talk only on the VPN interface. However a different rule applies whenever a more specific route exists 0.0.0.0/0 goes through VPN2 with metric 666 0.0.0.0/0 goes through LAN router with metric 10 0.0.0.0/1 goes through VPN1 with metric 30 128.0.0.0/1 goes through VPN1 with metric 30 Here the routes (3) and (4) cover the entire addressing space, just like 0.0.0.0/0. However because they are more specific, they'll be preferred for all traffic because these routes are more selective. This is how OpenVPN does override system routing with VPN routing by default. This is also what the other guide attempted as well, by pushing four {0,64,128,192}.0.0.0/2 routes. Since that was more specific, it would in return override the 0,128 routes and so on. We can calculate how many multi-hops we would be able to do with this method: IPv4 has 32 bits, we will not touch the last 8 bits of the subnets. That leaves us then with 24 bits or 24 maximum amount of hops. Theoretically. The routing table would be outright f---- to look at. This method is a bit more 'secure' in a way because you don't need to rely on overriding a certain metric value, you just slap a more specific route on top and it's automatically made default. Also you don't need to override the default gateway (router) and all that junk. However with my preferred method (first) you can quite easily do DIY dual-hop routing: 0.0.0.0/0 goes through VPN2 with metric 666 0.0.0.0/0 goes through LAN router with metric 10 0.0.0.0/1 goes through VPN1 with metric 30 128.0.0.0/1 goes through VPN1 with metric 30 <VPN2-IP>/32 goes through VPN1 with metric (any) Such a setup will make sure that all traffic destined for the internet (hits 3 and 4) will go through VPN1. If a program specifies the VPN2 network interface, then VPN2 will be reached via VPN1 first (you->VPN1->VPN2). This is quite 'quizzacious' to set up/control. Not part of this guide. As a part of this guide we told the system to route VPN2 via router on LAN. Yet you could indeed chain multiple VPNs this way and force the VPN1 to not only catch all traffic but also be chained via multiple VPNs itself so you would not need to manually set programs. I've seen scripts online for that purpose. Although be aware of MTU issues due to encapsulation. Troubleshooting tips TEST. SERIOUSLY, TEST YOUR SETUP BEFORE ENGAGING YOUR DATA CANNONS! A couple hours now are infinitely many times more worth than a 'leaked' mistake and headaches later on. https://ipleak.net/ - tests your client's default connection route. It would not tell you if your client is alternatively available on LAN for example. If you followed this guide and set up your client correctly, it will not be available on LAN etc. See the images below: 'without interface binding' (most newbie users) and 'with interface binding' (this guide) Wireshark to inspect how the traffic is actually flowing. Follow online tutorials, you only need to select the right network interfaces and filter traffic by port/IP (tcp/udp and your local or VPN IP) curl to send network requests. Like ifconfig.co / ifconfig.io will respond with the IP address it sees you as: curl --interface <your computer IP> http://ifconfig.co curl --interface 192.168.1.42 http://ifconfig.co # for IPv4 or IPv6, default route curl -4 http://ifconfig.co curl -6 http://ifconfig.co > route -4 print and > route -6 print on Windows. To compare the outputs, you can use Notepad++ with the compare plugin (you need two documents open, one in left and another in right pane before comparing). PS: AirVPN configuration generator does not support #comment lines. Please fix. Sorry Linux users, maybe another time I will write something tailored to you. But I believe you are smart cookies and will adapt the OS-specific steps to fulfill this guide's goal.

There is one Teamspeak Server (gommehd.net) that disconnects and bans you almost instantly if you are using a VPN - its not just a list of blocked IPs, since you are able to connect but some seconds later you get blocked, try for yourself to understand what I mean. Is there anyway to bypass that? any ideas?

The average number of times I lost the connection to the server is once a day. Is this is expected, or is this an issue with my OS? Is there any variation about the interval for each server restart?

Last week i shared a nice topic about VPN’s and how in the 21st century it is mandatory that every single person should be using one, is how some one mentioned AirVPN. I “had” 5 VPN’s on my iphone ( since it is where i use the internet the most ) i signed aboard to AirVPN and asked for a trial. And let me tell you i have not been this excited in a long time. after my trial ended few days ago i decided i should support AirVPN and get a subscription. Set up my windows 10 tablet, linux mint PC and of course my phone, i deleted the other VPNs off my system and did a few test and research in between and I have to say AirVPN is simple, fast, affordable, transparent and yet reliable. i can not believe i have not came across AirVPN before ( Google definitely did not help bring up any mention of AirVPN ) and wasted so much time, money, researching and hassle with choosing the right VPN service. enough of my ranting, keep up the good work and keep up with the good fight!!!

Downloaded this program for the first time and after i press "connect to recommended server" and the "tunnel drivers" are installing, the process is aborted and this message apears: "VPN network adaptor not found: install fail (0901)". After three seconds it restarts, and the message reappears, over and over again. What to do?

Recently, the Tor Project announced a membership program. As Air has always been a strong supporter of the Tor Project, maybe you can also consider the membership? This can help secure its independecy while also making AirVPN known to a wider audience. Many NGOs still struggle as the pandemic has decreased their donations. Here is the link to the announcement: https://blog.torproject.org/tor-project-membership-program

Every week or so I am finding my connection really slow. After troubleshooting, I find that changing the DNS server fixes the problem. Because I have the VPN configured on my ASUS Merlin router the DNS settings are manual. I select a DNS server from the OpenNIC project, but I would like to avoid having to manually change every couple of weeks. Do the DNS servers periodically experience issues? Is there a way to find a stable DNS server? Could my issue be related to something else?

Hello. Today, I stumbled across this interesting video hosted by Techlore and The Hated One. I watched some of Techlore's videos before and I enjoy the use of AirVPN (I used to use PIA and NordVPN - until I learned of NordVPN's data mining practises). I thought I would share this video, get you to watch it so we can talk about the points it brings up. How VPN providers use common myths to trick you into using them Please watch and listen to this! I am aware that my browsing traffic and real IP addressgets routed through a server and can potentially be monitored by my VPN provider, whether they claim to have a no-logs policy or not. And I definitely know VPN's don't prevent social media from tracking you - that's what add-ons like uBlock Origin and uMatrix and, of course, not using social media is for. Third-parties like governments, companies and hackers can use correlation attacks to track you (i.e. compare when I access a website to when I access the VPN server) along with other techniques to identify you, in spite of your VPN, like fingerprinting. Basically, completely anonymity with a VPN is impossible - even if you make an account with a temporary email address and pay for it with cryptocurrency if you're not careful how you browse the web. What caught my attention is that while VPN providers claim you can combine their VPN with Tor for improved security and anonymity (hiding the fact you are using Tor from your ISP, for instance), using Tor bridges effectively do that as well. Plus using a VPN with Tor would basically help third parties correlate your browsing traffic to your VPN's IP address. There are other interesting points that bear discussion such as web traffic being decrypted once leaving a VPN server (Is even AirVPN lying about encrypting our web traffic?) and such. So what are anyone's thoughts on this?

SemperVideo, a German HackInfo site has published a video on youtube claiming ALL VPN service provider lie when claiming NO LOG blabla. In the video you can see two examples. Video is in German (sorry), maybe subtitle works.. https://www.youtube.com/watch?v=zCePL6lkfGA Now the question is: How is this with AIRvpn???