Jump to content
Not connected, Your IP: 216.73.216.49

Leaderboard


Popular Content

Showing content with the highest reputation on 10/24/22 in all areas

  1. 1 point
    cstreet

    [ENDED] Spooky Hallowen 2022 deals

    un anno Halloween grazie, Edoardo - from New World
  2. 1 point
    SLASH

    [ENDED] Spooky Hallowen 2022 deals

    Extended for another year. Keep up the good work people!
  3. 1 point
    Staff

    [ENDED] Spooky Hallowen 2022 deals

    @Xoese Hello! As it's an Halloween deal, you can safely assume that it will not end before the HALLOWEEN NIGHT. grim regards
  4. 1 point
    About 2+ years ago I paid for Air VPN upon the recommendation of many people. I've used 10+ VPNs and this one is my favorite so far. I saw the Halloween deal and decided to buy another 3 years, which is only like $65. I would have topped off another 9+ years if I wasn't trying to save some money. Air VPN for the win!
  5. 1 point
    pyq

    eddie stuck for latency test

    Same problem here with Ubuntu 22.04.1. Happy to read that it's being worked on.
  6. 1 point
    Quick 👏 to the team, I installed WireGuard on my Pi4. Very quick test connecting to the same Air server and same Speedtest server showed a 3x improvement on downloads and uploads. It went from about 54/59 down/up to 156/159. LOVE IT
  7. 1 point
    You should get different interface addresses if you configure multiple different "devices" in AirVPN's UI here: https://airvpn.org/devices/. Each device has a details button to view the VPN IP for that device. Two AirVPN devices should work fine on the same physical device, just remember to use different adapter names if on Linux (eg. wg0 for the first one and wg1 for the second one).
  8. 1 point
    this for Mulvad you can change it for AirVPN with your config https://airvpn.org/external_link/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DwYe7FzZ_0X8
  9. 1 point
    Did you add a new "device" here: https://airvpn.org/devices/? Then ensure you select different devices for each config you download. Each device has its own WireGuard IP - You can see it by clicking the "Details" button. For the first error, you might need to change the /10 to /32 to avoid it. It shouldn't break anything since you're not going to be contacting other VPN users over the VPN (and I don't think that even works).
  10. 1 point
    FWIW, I have been "on the fence" about migrating to WireGuard from OpenVPN for my primary connections. It's newer and not as "battle tested" as it were as OpenVPN. I have read more discussions about the pros and cons that I care to admit. I will say that I found the setup for each tunnel a bit more tedious, but that may be my bias from years with OpenVPN. However, once I had multiple connections up and running in a load balance/fail-over configuration identical to my OpenVPN setup, I have to admit that it's not just a speed increase (150+ Mbps), but the fluctuation in speeds seems to have disappeared. Running any bandwidth testing program would result in ups and downs based on the network activity, CPU load and a million other factors at that moment running OpenVPN. Not a great deal mind you, but still there in the logs. This WireGuard setup is a constant download and upload speed almost every test, within a few Mbps. A much smaller margin. I believe I'm a convert.
  11. 1 point
    kbps

    [COMPLETED] WireGuard beta testing available

    Thanks @Staff. Upon closer look in Wireguard, there is a check box in edit mode called 'exclude private IPs' that is not checked by default. Checking it populates with the IP ranges from your link. I can now see my local network.
  12. 1 point
    pfsense 2.5.2 System with wireguard ISP Vodafone 1 Gbit up 50 Mbit down Client Windows 10 All is good for me 🙂 Howto not for AirVPN but give me a few ideas How to pfsense wireguard
  13. 1 point
    If you youtube 'Christian Mcdonald', he explains everything in his series of videos. He's also overseeing the wireguard package for netgate, and talks about the whole process and where he wants to take it in the future. Hello! Speaking of netgate.com, we found this article on it which looks good: https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html In order to fit it to AirVPN, please generate a configuration file for WireGuard and the server or country you wish from the Configuration Generator. It's a text file inside which you can find the settings/values you need. Kind regards
  14. 1 point
    I use an Ubuntu VM as my AirVPN client tunnel. In my router I use policy based rules to route a particular subnet to this Ubuntu VM so internet requests go through AirVPN. I've used this method with OpenVPN for over 2 years and it's been rock solid. Since OpenVPN is very CPU intensive, I decided to try Wireguard to see if speeds increased. Using the same server, I went from 300/80 Mbps via OpenVPN to ~800/500 Mbps with Wireguard. However using Wireguard vs OpenVPN seems to prevent access to a server that uses an API key. Using: curl --include --request GET https://websitename/api?t=caps&apikey=myapikey it works when OpenVPN is used but I get an error with Wireguard: curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to websitename:443 Here is a dump of systemctl status wg-quick@tun0 ● wg-quick@tun0.service - WireGuard via wg-quick(8) for tun0 Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled) Active: active (exited) since Fri 2021-11-26 11:52:25 EST; 10min ago Docs: man:wg-quick(8) man:wg(8) https://www.wireguard.com/ https://www.wireguard.com/quickstart/ https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8 https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8 Process: 1253 ExecStart=/usr/bin/wg-quick up %i (code=exited, status=0/SUCCESS) Main PID: 1253 (code=exited, status=0/SUCCESS) Nov 26 11:52:25 OpenVPN-Client wg-quick[1253]: [#] ip -6 route add ::/0 dev tun0 table 51820 Nov 26 11:52:25 OpenVPN-Client wg-quick[1253]: [#] ip -6 rule add not fwmark 51820 table 51820 Nov 26 11:52:25 OpenVPN-Client wg-quick[1253]: [#] ip -6 rule add table main suppress_prefixlength 0 Nov 26 11:52:25 OpenVPN-Client wg-quick[1253]: [#] ip6tables-restore -n Nov 26 11:52:25 OpenVPN-Client wg-quick[1253]: [#] ip -4 route add 0.0.0.0/0 dev tun0 table 51820 Nov 26 11:52:25 OpenVPN-Client wg-quick[1253]: [#] ip -4 rule add not fwmark 51820 table 51820 Nov 26 11:52:25 OpenVPN-Client wg-quick[1253]: [#] ip -4 rule add table main suppress_prefixlength 0 Nov 26 11:52:25 OpenVPN-Client wg-quick[1253]: [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 Nov 26 11:52:25 OpenVPN-Client wg-quick[1253]: [#] iptables-restore -n Nov 26 11:52:25 OpenVPN-Client systemd[1]: Started WireGuard via wg-quick(8) for tun0. I called my config tun0 because that's the default name of the OpenVPN tunnel and required no changes to my iptables config in rc.local. Is there anything in inherently different between OpenVPN and Wireguard connections that might cause this? One important detail is that from the client tunnel VM the curl command works, but is broken when applied from a machine that's being routed to this VM. Normally this would point to an issue with firewall rules (either in my router or Ubuntu machines) but I've changed nothing except the VPN protocol. Thanks for any suggestions. Update: The issue is that OpenVPN uses an MTU=1500 while Wireguard uses MTU=1420. Dropped packets were preventing the proper SSL handshake. My fix is to manually force an MTU=1392 in the machine that's having trouble. The long term fix is to have any machine that connects to this subnet use an MTU of 1392, but that's an issue outside of Wireguard and AirVPN.
  15. 1 point
    "I too am confused as to where and why the user's IP address is stored permantly. I understand that while connected to Air servers, the user IP address will be known. Why is this not purged from the Air after disconnect or server change?" Re why: The wireguard protocol itself has no notion of a "disconnect," and the server is always open to seeing more packets from a given peer (client in this case). Keeping the last known IP from which each peer communicates with the server radically speeds up incoming packet authentication, because if a packet arrives from a sender in the "last known" list, it's pretty obvious which public key to try first to test whether it's authentic. Air has worked around the issue nicely by deleting the last known IP after (currently) 3m during which the usual handshake packets have not arrived. The next packet that does arrive then has to be tested for authenticity against a large number of peer (users here) public keys. That carries a computational cost that Air kindly absorbs for the sake of our privacy in the comically unlikely case of some serious evildoer breaking into a datacenter and somehow siphoning off the contents of a running server's memory (IIRC they are diskless) for subsequent analysis. Summary: Air has made the saved public IP a nonissue in practical terms.
×
×
  • Create New...