Jump to content
Not connected, Your IP: 54.236.58.220

Leaderboard


Popular Content

Showing content with the highest reputation since 02/04/21 in Posts

  1. 4 points
    Hello! We're very glad to inform you that a new 1 Gbit/s server located in Auckland (NZ) is available: Fawaris. We're also very pleased to be back in Oceania. 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 Air server, Fawaris supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3 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/Fawaris Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team
  2. 2 points
    Staff

    Japan needs more servers

    @OpenSourcerer Hello! It's a good idea. Actually we already have it (it is shown only to special users, we don't know if you can see it) so it would be simple to make it available to anyone. We will consider it seriously. Kind regards
  3. 2 points
    It's more than necessary, maybe not for regular users but for those who are building networks for users to use. Whoever told you that v6 is unnecceary is probably such an user him/herself. Those leaks you mentioned are nothing but VPN configuration errors and don't appear outside the VPN context – why should they, after all. Every IP host needs a globally unique IP. When the internet was an infant, designed as a research network, 255^4 - 2 IP addresses were probably enough for a second lifetime of the earth, they said. But the core belief was still that every participant in this network needed a unique IP to be directly addressable. Nothing changed with IPv6, every participant still needs a unique IP. And thus NAT was born: The idea that multiple devices of the same network/house/company/whatever can use the internet through a machine in the middle which will forward their requests and return the answers. Pro: 100+ hosts need just one public IP. Con: You get to deal with port forwarding and other stuff. That's what AirVPN's "privacy" is all about: You use the internet as if you were the AirVPN server. It's pseudonymous, not anonymous. The IPv6 challenge for VPN providers is that IPv6 does not need NAT anymore as it was explicitly made to tackle this IPv4 address space exhaustion. There's no such thing as a v6 address exhaustion (yet), so we can again afford to assign public IPs to all hosts out there. The engineers wanted it to be as easy as possible, so they used the MAC address of the interfaces to automatically build part of that IPv6 address. The problem: This MAC address is supposed to be globally unique as well (it's not exactly, but still). Another problem is that by the time v6 started to be more or less widely adopted, the online ad train was already speeding and looking for more data points to use in the targeting algorithms. A unique IP which is not changed even after a reconnect is almost equivalent to finding the Holy Grail in targeted advertising. That's what gets people around communities like this spooked. And thus the v6 Privacy Extensions were born which are now the default on all platforms: The hosts themselves simply randomize this address, and no one really needs to know how they do it as long as the address is in fact addressable. Makes them less of a target for those ads, and in my humble opinion that should be enough, but people are still spooked by the addressing possibility by MAC so they avoid it in a privacy context. Not to mention the loudest argument of them all: "I can't memorize those long addresses!" Now, IPv6 can be configured to be NATed, just like v4. AirVPN did just that: v6 is NATed like v4 so your exit IPv6 address is that of the AirVPN server, not an address calculated by your own machine. It works and is what happens if you don't disable IPv6.
  4. 2 points
    Staff

    Linux: AirVPN Suite 1.0.0 released

    @frpergflf Hello! Allowing access to those directories to group "airvpn" is a choice of each superuser. For security reasons, by default the installer sets them belonging to root user and root or wheel group to comply to the best security practices consolidated in UNIX in the last 30 years. In general, as an optimal security solution, we want that Bluetit files can be edited only by root and sudo-ers, while Goldcrest files (but not Goldcrest binary) can be changed only by users belonging to airvpn group. The lock file removal failure after Bluetit clean stop order by systemd is unexpected. When the problem re-occurs, would you be so kind to send us Bluetit log? sudo journalctl | grep bluetit @asdfasdfasdfasdfasdf No, it is not. If you proceed to implement, don't forget that Bluetit is a daemon. @dL4l7dY6 @airvpnclient A source of Bluetit instability in OSMC and Raspbian 32 bit has been detected, and it's libcurl . The linked library explodes now and then. The problem has been resolved with specific libcurl linking. Development is now focused on a new Network Lock approach, to make the whole environment more secure especially during a system bootstrap. Once it is implemented (a matter of just a few days) we will be ready for testing and soon after a new release will follow, perfectly compatible with OSMC too. Kind regards
  5. 2 points
    @Maggie144 Hello! Since Network Lock is enforced via pf rules, which act directly on the kernel filtering table, it is not plausible that Apple services can bypass them. Leaks observed on Catalina and Big Sur with other software (not our software) take place because filtering rules are enforced via specific network API. The specific network filtering exceptions (for Apple programs) hard coded in macOS Catalina and Big Sur filtering API, which caused a lot of controversies (and rightly so), allow the horrendous behavior. Actually, lack of traffic leaks when Eddie or Hummingbird Network Lock is active on Intel Mac has been thoroughly verified by us through external network sniffers. We confirm that nothing, including Apple services and apps, is able to bypass the firewall (pf) rules. We can perform the same verification on Mac M1 in the near future. The problem in iOS is worse and can't be resolved, because in iOS devices you are not in control of the device filtering table (and you are not in control of the device in general). Anyway we do not write software for iOS, as you know. Should, in the future, "Apple Silicon" platforms evolve in iOS-like system which the user can not control, then they will be unsuitable for purposes where privacy and a layer of anonymity are a priority. We doubt anyway that Apple will expel its own customers from administrative device control like it did with iOS, but let's wait and see. Kind regards
  6. 1 point
    Quite likely because of this, yes. Doesn't matter much, your client still connects to the hosts. The LAN torrent client will be added to the peer list just like everyone else is and it's up to your client's settings to prefer it, treat it normally or ignore it entirely. But generally, it's a noble thing to do
  7. 1 point
    B-B-B-B-B-Bingo!!!!!! That was it. Thank you for the assist my good man!!!!!!!
  8. 1 point
    nl.all.vpn.airdns.org
  9. 1 point
    SteiferFinger

    Unable to start (No socket)

    Hello, I installed AirVPN with the Eddit Client on my Windows10 machine. Since I retstarted my computer I get following error message when trying to open the EddiUI: Unable to obtain elevated privileges (required): Unable to start (No socket) I dont know what to do, could someone help?
  10. 1 point
  11. 1 point
    The newest pfSense how to for 2.5 is this and works perfect https://nguvu.org/pfsense/pfsense-baseline-setup/
  12. 1 point
    @busybee911 Hello! After you have stopped and disabled systemd-resolved you should generate your own resolv.conf file before running Eddie, or restart networking and let network-manager do that (via DHCP etc.) if you wish to query the router. The new resolv.conf file will then be the file that Eddie will restore when its job is finished. Kind regards
  13. 1 point
    Hello This was already in my custom option, what's your view on removing these custom options from: client;remote-cert-tls server;persist-key;persist-tun;keysize 256;key-method 2;key-direction 1;explicit-exit-notify 5;mlock;keepalive 5 30;prng sha512 64; to... client;persist-key;persist-tun;remote-cert-tls server;prng sha256 64;mlock;auth-nocache; Thank you!
  14. 1 point
    I have a reason to believe that M247 is falsifying a few of its server locations which it sells to VPN companies such as AirVPN. Disclaimer: I am not accusing AirVPN of participating in this falsification, I believe that AirVPN staff has the integrity and honesty to only purchase servers in locations they know are correct as advertised. My hypothesis is that AirVPN was merely duped into buying thse falsified locations because M247 claimed that they were real locations and AirVPN did not have any reason to suspect anything to the contrary. I noticed recently that the M247 "Phoenix" location seems to really be located in Los Angeles, M247 "Barcelona" location seems to really be in Madrid, and the M247 "Berlin" location seems to really be in Frankfurt. Traceroute shows identical routes between each of these false locations and the real location they are in, not to mention that neither Phoenix, Barcelona, or Berlin appear on M247's list of locations on their website Disclaimer 2: All of the data below is shown as it was generated, with the only thing being edited is the redaction of my ISP's traceroute hops for protection of my privacy. Exhibit A: "Phoenix" is really Los Angeles. Traceroute and ping to Indus , allegedly in M247 Phoenix Traceroute to Indus server traceroute to indus.airservers.org (193.37.254.26), 30 hops max, 38 byte packets [Redacted my ISP's traceroute hops] 8 * * * 9 ae-5.r01.lsanca20.us.bb.gin.ntt.net (129.250.6.49) 73.593 ms 68.449 ms 69.689 ms 10 ce-0-1-0-0.r01.lsanca20.us.ce.gin.ntt.net (128.241.6.1) 66.818 ms 71.847 ms 72.087 ms 11 * irb-0.agg1.lax1.us.m247.com (77.243.185.149) 89.481 ms et-0-0-49-0.agg1.lax1.us.m247.com (77.243.185.145) 79.797 ms 12 vlan2921.as09.lax1.us.m247.com (193.9.115.167) 123.200 ms 71.520 ms vlan2909.as09.lax1.us.m247.com (193.9.115.169) 74.228 ms 13 * * * 14 * * * Traceroute from Indus to Google traceroute to google.com (172.217.5.110), 30 hops max, 60 byte packets 1 10.32.6.1 (10.32.6.1) 69.597 ms 69.603 ms 69.595 ms 2 vlan177.as09.lax1.us.m247.com (193.37.254.1) 69.687 ms 69.711 ms 69.778 ms 3 irb-0.agg1.lax1.us.m247.com (193.9.115.168) 633.031 ms 633.038 ms 633.034 ms 4 37.120.220.170 (37.120.220.170) 69.490 ms 69.452 ms 69.546 ms 5 72.14.204.180 (72.14.204.180) 69.661 ms te-4-3-0.bb1.lax1.us.m247.com (82.102.29.110) 69.769 ms 69.821 ms 6 10.252.217.158 (10.252.217.158) 69.615 ms 72.14.204.180 (72.14.204.180) 67.888 ms 10.23.211.158 (10.23.211.158) 68.754 ms 7 10.252.234.254 (10.252.234.254) 67.871 ms 142.250.228.74 (142.250.228.74) 68.216 ms 10.252.234.254 (10.252.234.254) 68.221 ms 8 108.170.247.244 (108.170.247.244) 68.254 ms 108.170.237.114 (108.170.237.114) 68.228 ms 108.170.247.244 (108.170.247.244) 68.243 ms 9 108.170.247.211 (108.170.247.211) 68.818 ms 108.170.247.148 (108.170.247.148) 68.598 ms 68.843 ms 10 108.170.230.123 (108.170.230.123) 68.806 ms 108.170.230.133 (108.170.230.133) 69.010 ms 172.253.75.217 (172.253.75.217) 76.905 ms 11 172.253.75.217 (172.253.75.217) 76.921 ms 172.253.70.153 (172.253.70.153) 80.406 ms 74.125.253.148 (74.125.253.148) 75.588 ms 12 142.250.234.59 (142.250.234.59) 81.965 ms 108.170.243.1 (108.170.243.1) 78.518 ms 80.377 ms 13 108.170.236.61 (108.170.236.61) 75.650 ms 75.356 ms 108.170.243.1 (108.170.243.1) 77.960 ms 14 sfo03s07-in-f14.1e100.net (172.217.5.110) 82.906 ms 108.170.236.63 (108.170.236.63) 77.106 ms sfo03s07-in-f110.1e100.net (172.217.5.110) 103.936 ms Ping to Indus PING 193.37.254.26 (193.37.254.26) 56(84) bytes of data. 64 bytes from 193.37.254.26: icmp_seq=1 ttl=57 time=69.5 ms 64 bytes from 193.37.254.26: icmp_seq=2 ttl=57 time=68.8 ms 64 bytes from 193.37.254.26: icmp_seq=3 ttl=57 time=69.1 ms 64 bytes from 193.37.254.26: icmp_seq=4 ttl=57 time=68.0 ms 64 bytes from 193.37.254.26: icmp_seq=5 ttl=57 time=69.3 ms 64 bytes from 193.37.254.26: icmp_seq=6 ttl=57 time=68.5 ms 64 bytes from 193.37.254.26: icmp_seq=7 ttl=57 time=70.0 ms 64 bytes from 193.37.254.26: icmp_seq=8 ttl=57 time=69.2 ms 64 bytes from 193.37.254.26: icmp_seq=9 ttl=57 time=69.7 ms 64 bytes from 193.37.254.26: icmp_seq=10 ttl=57 time=68.1 ms Hmm, I wonder why all the M247 router hops are all labelled as "LAX1" for a "Phoenix" location??? Now we will compare this to Groombridge, a server in M247 Los Angeles Traceroute to Groombridge traceroute to groombridge.airservers.org (37.120.132.82), 30 hops max, 38 byte packets [Redacted my ISP's traceroute hops] 7 * * * 8 ae-2.r25.lsanca07.us.bb.gin.ntt.net (129.250.3.189) 74.561 ms 97.764 ms * 9 ae-5.r01.lsanca20.us.bb.gin.ntt.net (129.250.6.49) 73.048 ms 70.967 ms 73.707 ms 10 ce-0-1-0-0.r01.lsanca20.us.ce.gin.ntt.net (128.241.6.1) 65.112 ms 73.968 ms 71.939 ms 11 irb-0.agg1.lax1.us.m247.com (77.243.185.149) 77.359 ms * * 12 vlan2926.as15.lax1.us.m247.com (89.44.212.37) 75.003 ms 73.769 ms 217.138.223.35 (217.138.223.35) 67.763 ms 13 * * * 14 * * * Traceroute from Groombridge to YouTube traceroute to youtube.com (216.58.195.78), 30 hops max, 60 byte packets 1 10.15.134.1 (10.15.134.1) 71.514 ms 71.502 ms 71.493 ms 2 vlan170.as15.lax1.us.m247.com (37.120.132.81) 71.810 ms 71.986 ms 72.005 ms 3 * * * 4 37.120.220.198 (37.120.220.198) 75.969 ms te-1-2-0.bb1.nyc1.us.m247.com (77.243.185.18) 76.140 ms 37.120.220.198 (37.120.220.198) 75.971 ms 5 72.14.204.180 (72.14.204.180) 76.149 ms 76.154 ms te-4-3-0.bb1.lax1.us.m247.com (82.102.29.110) 75.138 ms 6 10.252.173.62 (10.252.173.62) 78.254 ms 72.14.204.180 (72.14.204.180) 73.797 ms 73.781 ms 7 209.85.254.86 (209.85.254.86) 73.773 ms 10.252.50.62 (10.252.50.62) 73.975 ms 108.170.247.193 (108.170.247.193) 74.551 ms 8 108.170.237.114 (108.170.237.114) 73.937 ms 108.170.247.193 (108.170.247.193) 74.759 ms 108.170.247.243 (108.170.247.243) 74.214 ms 9 * 108.170.247.244 (108.170.247.244) 74.196 ms 108.170.234.124 (108.170.234.124) 74.648 ms 10 209.85.254.229 (209.85.254.229) 86.701 ms * 108.170.234.27 (108.170.234.27) 72.588 ms 11 216.239.58.214 (216.239.58.214) 80.460 ms 142.250.234.56 (142.250.234.56) 81.648 ms 172.253.70.155 (172.253.70.155) 83.700 ms 12 108.170.242.241 (108.170.242.241) 80.580 ms 66.249.94.28 (66.249.94.28) 79.787 ms 108.170.242.241 (108.170.242.241) 81.349 ms 13 72.14.239.97 (72.14.239.97) 80.326 ms 108.170.242.241 (108.170.242.241) 81.308 ms 72.14.239.43 (72.14.239.43) 84.462 ms 14 72.14.239.43 (72.14.239.43) 82.598 ms sfo07s16-in-f78.1e100.net (216.58.195.78) 80.463 ms 81.950 ms Ping to Groombridge PING groombridge.airservers.org (37.120.132.82) 56(84) bytes of data. 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=1 ttl=57 time=68.8 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=2 ttl=57 time=68.8 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=3 ttl=57 time=68.9 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=4 ttl=57 time=68.0 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=5 ttl=57 time=70.4 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=6 ttl=57 time=69.0 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=7 ttl=57 time=70.4 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=8 ttl=57 time=67.6 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=9 ttl=57 time=68.3 ms 64 bytes from 82.132.120.37.in-addr.arpa (37.120.132.82): icmp_seq=10 ttl=57 time=68.0 ms Hmm, looks suspiciously similar to me... Routes are both the same, ping is near-equal Exhibit B: "Barcelona" is really Madrid Traceroute and ping to Eridanus, allegedly in Barcelona Traceroute to Eridanus traceroute to eridanus.airservers.org (185.183.106.2), 30 hops max, 38 byte packets [Redacted my ISP's traceroute hops] 7 * * * 8 be2332.ccr32.bio02.atlas.cogentco.com (154.54.85.246) 83.833 ms 82.655 ms 83.244 ms 9 be2325.ccr32.mad05.atlas.cogentco.com (154.54.61.134) 86.389 ms 85.839 ms 86.422 ms 10 quantum-sistemas.demarc.cogentco.com (149.6.150.130) 110.559 ms 171.268 ms 118.386 ms 11 * * * 12 * * * Traceroute from Eridanus to YouTube traceroute to youtube.com (216.58.211.46), 30 hops max, 60 byte packets 1 10.16.134.1 (10.16.134.1) 89.066 ms 89.077 ms 89.072 ms 2 * * * 3 xe-1-2-3-0.bb1.mad1.es.m247.com (212.103.51.62) 89.002 ms 88.997 ms 88.992 ms 4 mad-b1-link.telia.net (213.248.95.33) 89.157 ms 89.176 ms 89.172 ms 5 google-ic-314668-mad-b1.c.telia.net (62.115.61.14) 89.168 ms 89.324 ms 89.328 ms 6 * * * 7 142.250.239.26 (142.250.239.26) 92.637 ms 72.14.233.124 (72.14.233.124) 91.657 ms 142.250.62.202 (142.250.62.202) 91.548 ms 8 108.170.234.221 (108.170.234.221) 92.059 ms 74.125.242.178 (74.125.242.178) 91.787 ms 144.397 ms 9 108.170.253.225 (108.170.253.225) 91.930 ms muc03s14-in-f14.1e100.net (216.58.211.46) 91.631 ms 108.170.253.225 (108.170.253.225) 91.934 ms Hmm, I wonder why M247's router hops in the "Barcelona" location are all labelled as "MAD1" Ping to Eridanus PING 185.183.106.2 (185.183.106.2) 56(84) bytes of data. 64 bytes from 185.183.106.2: icmp_seq=1 ttl=56 time=89.4 ms 64 bytes from 185.183.106.2: icmp_seq=2 ttl=56 time=85.9 ms 64 bytes from 185.183.106.2: icmp_seq=3 ttl=56 time=84.9 ms 64 bytes from 185.183.106.2: icmp_seq=4 ttl=56 time=85.5 ms 64 bytes from 185.183.106.2: icmp_seq=5 ttl=56 time=86.4 ms 64 bytes from 185.183.106.2: icmp_seq=6 ttl=56 time=85.0 ms 64 bytes from 185.183.106.2: icmp_seq=7 ttl=56 time=85.3 ms 64 bytes from 185.183.106.2: icmp_seq=8 ttl=56 time=87.1 ms 64 bytes from 185.183.106.2: icmp_seq=9 ttl=56 time=85.8 ms 64 bytes from 185.183.106.2: icmp_seq=10 ttl=56 time=85.3 ms Comparing this to Mekbuda, a server in Madrid M247 Traceroute to Mekbuda [Redacted my ISP's traceroute hops] 7 * * * 8 be2332.ccr32.bio02.atlas.cogentco.com (154.54.85.246) 83.761 ms 82.333 ms 82.102 ms 9 be2325.ccr32.mad05.atlas.cogentco.com (154.54.61.134) 86.121 ms 85.032 ms 86.308 ms 10 quantum-sistemas.demarc.cogentco.com (149.6.150.130) 94.879 ms 87.337 ms 88.230 ms 11 * * * 12 * * * Route from Mekbuda to Youtube traceroute to youtube.com (216.58.215.142), 30 hops max, 60 byte packets 1 10.21.198.1 (10.21.198.1) 87.692 ms 87.693 ms 87.686 ms 2 vlan29.bb2.mad1.es.m247.com (185.93.182.161) 87.696 ms 87.690 ms 87.750 ms 3 xe-1-1-0-0.bb1.mad1.es.m247.com (82.102.29.25) 87.762 ms 87.758 ms 87.753 ms 4 mad-b1-link.telia.net (213.248.95.33) 87.956 ms 88.558 ms 87.931 ms 5 google-ic-314668-mad-b1.c.telia.net (62.115.61.14) 87.836 ms 87.992 ms 87.988 ms 6 * * * 7 mad41s04-in-f14.1e100.net (216.58.215.142) 86.846 ms 74.125.242.177 (74.125.242.177) 98.934 ms 98.992 ms Ping to Mekbuda PING mekbuda.airservers.org (185.93.182.170) 56(84) bytes of data. 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=1 ttl=56 time=87.0 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=2 ttl=56 time=88.4 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=3 ttl=56 time=86.2 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=4 ttl=56 time=88.4 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=5 ttl=56 time=86.7 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=6 ttl=56 time=85.7 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=7 ttl=56 time=85.7 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=8 ttl=56 time=87.1 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=9 ttl=56 time=88.3 ms 64 bytes from 185.93.182.170 (185.93.182.170): icmp_seq=10 ttl=56 time=88.2 ms Once again, everything is near-identical, with only a slight difference in Youtube traceroute. Exhibit C: "Berlin" is really in Frankfurt First we will test ping and traceroute to Cujam, a Berlin M247 server Traceroute to Cujam [Redacted my ISP's traceroute hops] 6 * * * 7 ae-9.r20.londen12.uk.bb.gin.ntt.net (129.250.6.146) 73.904 ms ae-11.r20.parsfr04.fr.bb.gin.ntt.net (129.250.4.195) 78.812 ms 75.580 ms 8 ae-1.r21.londen12.uk.bb.gin.ntt.net (129.250.2.183) 79.099 ms ae-2.r21.parsfr04.fr.bb.gin.ntt.net (129.250.3.46) 85.715 ms ae-1.r21.londen12.uk.bb.gin.ntt.net (129.250.2.183) 78.384 ms 9 ae-16.r20.frnkge13.de.bb.gin.ntt.net (129.250.3.13) 91.553 ms ae-11.r21.frnkge13.de.bb.gin.ntt.net (129.250.5.26) 91.521 ms ae-16.r20.frnkge13.de.bb.gin.ntt.net (129.250.3.13) 94.728 ms 10 ae-0.a00.frnkge13.de.bb.gin.ntt.net (129.250.2.25) 92.855 ms 89.619 ms 90.740 ms 11 ae-8-501.a00.frnkge13.de.ce.gin.ntt.net (213.198.52.62) 91.869 ms 92.824 ms 93.136 ms 12 37.120.220.131 (37.120.220.131) 90.856 ms vlan2945.agg2.fra4.de.m247.com (193.27.15.241) 92.015 ms 37.120.220.116 (37.120.220.116) 89.007 ms 13 vlan2925.as03.fra4.de.m247.com (83.97.21.17) 88.304 ms vlan2901.as03.fra4.de.m247.com (82.102.29.155) 93.828 ms vlan2925.as03.fra4.de.m247.com (83.97.21.17) 89.713 ms 14 * * * 15 * * * Traceroute from Cujam to YouTube 1 10.11.102.1 (10.11.102.1) 89.968 ms 89.978 ms 89.972 ms 2 37.120.217.241 (37.120.217.241) 90.041 ms 90.036 ms 90.134 ms 3 vlan2925.agg2.fra4.de.m247.com (83.97.21.16) 89.915 ms 89.910 ms 89.905 ms 4 37.120.220.130 (37.120.220.130) 90.078 ms 193.27.15.240 (193.27.15.240) 89.956 ms 37.120.220.130 (37.120.220.130) 90.199 ms 5 vlan2906.bb1.ams1.nl.m247.com (37.120.128.248) 90.252 ms 90.009 ms 37.120.128.253 (37.120.128.253) 90.176 ms 6 37.120.128.253 (37.120.128.253) 90.171 ms no-mans-land.m247.com (185.206.226.71) 89.888 ms 37.120.128.253 (37.120.128.253) 89.597 ms 7 no-mans-land.m247.com (185.206.226.71) 89.851 ms 10.252.43.30 (10.252.43.30) 89.962 ms 10.252.45.126 (10.252.45.126) 89.649 ms 8 108.170.252.1 (108.170.252.1) 90.496 ms 108.170.235.248 (108.170.235.248) 89.578 ms 10.252.73.190 (10.252.73.190) 89.598 ms 9 108.170.252.83 (108.170.252.83) 90.067 ms 108.170.252.18 (108.170.252.18) 90.020 ms 108.170.252.65 (108.170.252.65) 90.430 ms 10 * * 209.85.252.77 (209.85.252.77) 90.872 ms 11 216.239.50.187 (216.239.50.187) 99.430 ms * 209.85.252.149 (209.85.252.149) 97.794 ms 12 108.170.230.210 (108.170.230.210) 98.329 ms 72.14.238.52 (72.14.238.52) 97.997 ms 97.910 ms 13 108.170.244.161 (108.170.244.161) 97.921 ms 108.170.235.98 (108.170.235.98) 98.316 ms 108.170.244.225 (108.170.244.225) 98.802 ms 14 108.170.232.125 (108.170.232.125) 97.839 ms 98.060 ms 98.173 ms 15 108.170.234.51 (108.170.234.51) 98.067 ms par10s27-in-f206.1e100.net (216.58.198.206) 97.811 ms 98.150 ms Ping to Cujam PING cujam.airservers.org (37.120.217.242) 56(84) bytes of data. 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=1 ttl=53 time=90.3 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=2 ttl=53 time=91.8 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=3 ttl=53 time=91.7 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=4 ttl=53 time=92.5 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=5 ttl=53 time=91.3 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=6 ttl=53 time=92.1 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=7 ttl=53 time=90.5 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=8 ttl=53 time=91.3 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=9 ttl=53 time=90.0 ms 64 bytes from 37.120.217.242 (37.120.217.242): icmp_seq=10 ttl=53 time=92.1 ms I wonder why there's no mention of "Berlin" in the traceroute hops, instead says FRA4 for Frankfurt.... Next we will compare this to Mirfak, a M247 Frankfurt server Traceroute to Mirfak [Redacted my ISP's traceroute hops] 5 * * * 6 if-ae-66-8.tcore1.l78-london.as6453.net (80.231.130.194) 93.049 ms if-ae-66-9.tcore1.l78-london.as6453.net (80.231.130.21) 92.427 ms if-ae-66-8.tcore1.l78-london.as6453.net (80.231.130.194) 92.662 ms 7 * if-ae-3-2.tcore1.pye-paris.as6453.net (80.231.154.142) 94.296 ms * 8 * * if-ae-11-2.tcore1.pvu-paris.as6453.net (80.231.153.49) 92.280 ms 9 * if-ae-49-2.tcore2.pvu-paris.as6453.net (80.231.153.21) 91.508 ms * 10 if-ae-55-2.tcore1.fr0-frankfurt.as6453.net (80.231.245.7) 100.752 ms 91.321 ms 92.308 ms 11 if-ae-55-2.tcore1.fr0-frankfurt.as6453.net (80.231.245.7) 88.325 ms 195.219.50.23 (195.219.50.23) 96.137 ms 94.877 ms 12 vlan2946.agg1.fra4.de.m247.com (193.27.15.243) 94.155 ms 37.120.220.116 (37.120.220.116) 93.367 ms 37.120.220.118 (37.120.220.118) 91.790 ms 13 vlan2917.as11.fra4.de.m247.com (212.103.51.191) 101.641 ms vlan2945.agg2.fra4.de.m247.com (193.27.15.241) 90.441 ms vlan2917.as11.fra4.de.m247.com (212.103.51.191) 93.836 ms 14 * vlan2917.as11.fra4.de.m247.com (212.103.51.191) 94.359 ms vlan2919.as11.fra4.de.m247.com (212.103.51.151) 96.080 ms 15 * * * 16 * * * The only difference in this traceroute is that the traffic goes through TATA instead of NTT which the Cujam server goes through, but the destination for both is the same: M247 in Frankfurt Traceroute to YouTube from Mirfak traceroute to youtube.com (172.217.17.46), 30 hops max, 60 byte packets 1 10.27.230.1 (10.27.230.1) 96.778 ms 96.764 ms 96.774 ms 2 vlan27.as11.fra4.de.m247.com (141.98.102.177) 97.067 ms 97.135 ms 97.329 ms 3 vlan2917.agg1.fra4.de.m247.com (212.103.51.190) 96.705 ms 96.704 ms 96.699 ms 4 37.120.128.148 (37.120.128.148) 97.120 ms 193.27.15.242 (193.27.15.242) 97.724 ms 37.120.128.148 (37.120.128.148) 97.107 ms 5 37.120.128.253 (37.120.128.253) 96.833 ms 96.835 ms vlan2906.bb1.ams1.nl.m247.com (37.120.128.248) 96.894 ms 6 no-mans-land.m247.com (185.206.226.71) 97.037 ms 37.120.128.253 (37.120.128.253) 95.349 ms 95.494 ms 7 no-mans-land.m247.com (185.206.226.71) 95.615 ms 10.252.45.190 (10.252.45.190) 98.342 ms 10.252.45.158 (10.252.45.158) 96.818 ms 8 216.239.47.244 (216.239.47.244) 96.897 ms 108.170.252.65 (108.170.252.65) 97.534 ms 142.250.46.244 (142.250.46.244) 96.712 ms 9 108.170.252.18 (108.170.252.18) 97.041 ms 108.170.251.144 (108.170.251.144) 97.279 ms 108.170.252.18 (108.170.252.18) 96.977 ms 10 * * * 11 209.85.244.158 (209.85.244.158) 104.649 ms * * 12 216.239.42.171 (216.239.42.171) 104.672 ms 216.239.42.102 (216.239.42.102) 116.455 ms 216.239.43.37 (216.239.43.37) 104.324 ms 13 216.239.42.171 (216.239.42.171) 104.748 ms 104.733 ms 216.239.43.37 (216.239.43.37) 115.898 ms 14 108.170.236.135 (108.170.236.135) 104.245 ms 104.183 ms 108.170.236.137 (108.170.236.137) 104.074 ms 15 ams16s29-in-f46.1e100.net (172.217.17.46) 103.791 ms 103.813 ms 102.372 ms Ping to Mirfak PING mirfak.airservers.org (141.98.102.234) 56(84) bytes of data. 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=1 ttl=53 time=89.3 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=2 ttl=53 time=89.8 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=3 ttl=53 time=89.1 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=4 ttl=53 time=90.6 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=5 ttl=53 time=89.6 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=6 ttl=53 time=89.2 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=7 ttl=53 time=90.0 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=8 ttl=53 time=90.0 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=9 ttl=53 time=87.6 ms 64 bytes from 234.102.98.141.in-addr.arpa (141.98.102.234): icmp_seq=10 ttl=53 time=88.9 ms Again, everything is near-identical, suggesting that these Berlin, Phoenix, and Barcelona locations are just falsified geolocation information and nothing more. With near-identical traceroutes, and ping values that don't differ by more than 1-2ms , it is extremely unrealistic that these servers are in the locations they claim to be. If you think my data is wrong/inaccurate, then feel free to repeat my experiment yourself, you will find the same thing. I would like to reiterate that I believe that AirVPN has no part in this falsification and that they have no ill will, I think they were duped/deceived by M247 to believe that the Phoenix, Berlin and Barcelona locations are actually real physical locations M247 has their servers located in. I think after these findings, AirVPN should have a long discussion with M247 staff about this falsification that took place.
  15. 1 point
    OpenSourcerer

    Eddie GUI and/or CLI?

    This statement is correct.
  16. 1 point
    I read a while ago that someone had their bank account locked by their bank security due to making an online card purchase while using their VPN connected to servers in say Holland for example. A little later while not on the VPN they used their card again and the account was locked due to two purchases in such a short time from two different countries. Apparently it took a while to get it sorted out. For that reason I only do banking while not being connected to the VPN.
  17. 1 point
    NaDre

    OpenVPN Config

    The order of these lines does not matter. Each can be anywhere in the config file. You can have them included in every config file at the time you generate them. In the config generator check "Advanced Mode" and then paste those lines into the " OpenVPN custom directives:" text box.
  18. 1 point
    OpenSourcerer

    Overview

    Since OMEMO is an implementation of the protocol Signal uses, yes, it's on par with Signal, barring implementation errors, that is.
  19. 1 point
    Yeah, no, this is a remnant of the old separation between eddie-ui and eddie-cli in Eddie versions before 2.18.9, I think. The latter is now called with eddie-ui --cli. I agree that it's confusing and should be changed accordingly. But yes, --login username --password password is probably also needed if there is no default.profile file in ~/.config/Eddie/. Simply append them to the command I gave you and change username and password to your own.
  20. 1 point
    grammarye

    AirVPN Suite -- Well Done

    I'll second this. I barely know my way around the deeper details of a Linux system and getting the suite going, including automatic connection on boot, was very simple. Awesome work and I completely agree on the superb documentation; so rare to see this. I'd love to see this as a package at some point. Some greater guidance on password security might not go amiss.
  21. 1 point
    OpenSourcerer

    DDNS issues

    Yes.
  22. 1 point
    Personally I'm using gufw for linux, and it works very well. However, it's important to remember that gufw is just a graphical frontend for ufw, and ufw, in turn, is just a friendlier system for manipulating IPTABLES (which is again a system for manipulating netfilter directly in the running kernel). Gufw is perhaps over simplified, which is why I find it not really that great for anything else than providing an overview of your rules and turning the firewall on an off. With regards to firestarter, I have tried it once, but I didn't really have any good experience with it, since, as you guys have already posted, it seems rather poorly coded and does some odd things when manipulating IPTABLES. What I found invaluable about ufw is its ability to specify rules based on interface and its simplictity even though its quite powerful. This was my main motivation for using it over other solutions like Firestarter, and Shorewall was too complicated for my taste. My rule approach goes like this: Allow connections OUT to AirVPN servers I use the most (for connecting/reconnecting to the AirVPN service, entry IP's, marked RED on the screenshot) Allow connections OUT FROM the tun0 interface TO anywhere (when I'm connected, this is the interface used to communicate to the Internet, marked GREEN on the screenshot) Allow connections (UDP/TCP) IN TO the tun0 interface to a specific port (to enable AirVPN's port forwarding feature, marked BLUE on the screeshot) Allow connections IN FROM the 192.168.1.0/24 network TO the eth0 interface (enable home networking. Notice how it's on a different interface, YELLOW) Allow connections OUT FROM the eth0 interface TO the 192.168.1.0/24 network (enable home networking, also on the eth0 interface, YELLOW) Block ALL other traffic (by choosing DENY/DENY in gufw) When the VPN drops (and the tun0 interface is disabled), the only connections allowed OUT from the computer are to the AirVPN server IP's (to reconnect) and the local 192.168.1.0/24 network (to still function in the LAN). And the only connections allowed TO the computer are from the local network as well. No leaks. Now, the gufw GUI doesn't allow for specifying the interface (remember, it's over simplified), so to do that, it's necessary to use ufw directly. Gufw can, however, display the rules when created by ufw. For example: "sudo allow out on tun0 from any to any" - is quite straightforward, and of course creates the rule that allows for communication TO the Internet when connected to AirVPN. "sudo allow in on tun0 from any to any port xxxxx" - enables the port forwarding feature by allowing packets to the specified port on the tun0 interface to pass through. Tips: - the order of the rules is very important - mimic mine on the screenshot attached - to add rules in a specific order from the command line, use "insert x": "sudo insert 3 allow in on tun0 from any to any port xxxxx" - inserts the rule at the 3rd position and moves rules below it downward, includin the previous rule nr 3. - when adding rules via the commandline, press F5 in gufw to force a refresh and view the newly added rule - the UFW manual is well worth reading, although you may not need any more information than offered in this post - with this approach, you're blocking multicasting addresses possibly forwarded by your router. Just a thing to have in mind in case you need it; it is of couse easily remedied by creating a new rule allowing the address(es). Let me know how this works for ya
  23. 1 point
    O.S. Sie sind der mann. What a superb explanation. I read it carefully twice, I now understand v6 addressing. I did know the history of it was due to exhaustion of v4, but beyond that I had no clue, I didn't know MAC addresses were involved (usually anyway), and I can see why that would scare people. So it should too, as you said, it's a golden ticket for targeted advertisers. Brilliant write up, thank you so much. I will turn ipv6 back on
  24. 1 point
    Staff

    Linux: AirVPN Suite 1.0.0 released

    @frpergflf Hello! SELinux correctly prevents systemd to delete the lock file. That's an illegal operation that systemd wants to perform and that tells something on how systemd is designed. Bleutit crash is caused by the fact that systemd bombards with SIGTERM Bluetit (and in general any real daemon). Under specific circumstances, i.e. when 2 or more SIGTERM signals are sent to Blueit almost simultaneously, Bluetit crashes, because the promise object has been already depleted when the 2nd or nth SIGTERM is received. Again, this incomprehensible behavior tells something about how systemd is designed, but at least it made us find a bug which might cause crashes in any other similar circumstance (imagine if you manage to send SIGTERM from two "kill" commands synced to be executed almost simultaneously). Fix will be of course implemented in the next, imminent version. Kind regards
  25. 1 point
    @GrandeGiovanni I'm pretty sure you're right, and it's fairly trivial to verify. I have a server physically located in Los Angeles, in Psychz Networks' data center. If I ping Indus from that server, I get pings as low as ~0.40ms: $ ping indus.airservers.org PING indus.airservers.org (193.37.254.26) 56(84) bytes of data. 64 bytes from 193.37.254.26 (193.37.254.26): icmp_seq=1 ttl=59 time=0.421 ms 64 bytes from 193.37.254.26 (193.37.254.26): icmp_seq=2 ttl=59 time=0.554 ms 64 bytes from 193.37.254.26 (193.37.254.26): icmp_seq=3 ttl=59 time=0.450 ms 64 bytes from 193.37.254.26 (193.37.254.26): icmp_seq=4 ttl=59 time=0.403 ms ^C --- indus.airservers.org ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 0.403/0.457/0.554/0.058 ms I don't want to post any links because I'm afraid the forum system will mark this reply as spam, but you can verify this result by searching Google for "Psychz looking glass" and going to their Los Angeles looking glass. It'll let you send pings from their LA network. I can guarantee you that you will not get <0.5ms pings to a server that's physically in another location. I can't even get pings that low from one Los Angeles data center to othrer data centers in Los Angeles (ColoCrossing and QuadraNet)! Even the best networks are limited by the speed of light. Ping times are round-trip time, so a ping of 0.4ms means it takes 0.2ms to reach the server. Even if you assume a perfect network where data can flow at the speed of light with zero delays (which in reality is not possible), 0.2ms multiplied by the speed of light is only around 60 kilometers. That's less than 1/10 of the distance from Los Angeles to Phoenix! Fremont is around the same distance from Los Angeles as Phoenix. If I ping Aquila from the same server, the results are more what you'd expect for that distance: $ ping aquila.airservers.org PING aquila.airservers.org (199.249.223.129) 56(84) bytes of data. 64 bytes from 199.249.223.129 (199.249.223.129): icmp_seq=1 ttl=57 time=10.5 ms 64 bytes from 199.249.223.129 (199.249.223.129): icmp_seq=2 ttl=57 time=10.4 ms 64 bytes from 199.249.223.129 (199.249.223.129): icmp_seq=3 ttl=57 time=9.98 ms 64 bytes from 199.249.223.129 (199.249.223.129): icmp_seq=4 ttl=57 time=9.89 ms 64 bytes from 199.249.223.129 (199.249.223.129): icmp_seq=5 ttl=57 time=10.5 ms ^C --- aquila.airservers.org ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 9.885/10.258/10.544/0.270 ms From what I've seen so far, I can pretty much guarantee you that the servers are not in that data center. I've tried traceroutes from several providers using Cogent transit. If your VPN servers were actually on Cogent's network in Phoenix, I'd expect them to reach a Cogent router in Phoenix before seeing M247 in the traceroute, as Cogent will keep the traffic in their backbone network for as long as possible. However, in every single case I've seen, the traffic is only routed to Los Angeles on Cogent's network, before moving onto M247's network. Perhaps the most telling is doing a traceroute from somewhere east of Phoenix. Here's a traceroute I did from Chicago to Indus via Cogent's looking glass: traceroute to indus.airservers.org (193.37.254.26), 30 hops max, 60 byte packets 1 gi0-0-0-15.99.agr21.ord01.atlas.cogentco.com (66.250.250.89) 0.733 ms 0.731 ms 2 be2522.ccr42.ord01.atlas.cogentco.com (154.54.81.61) 1.145 ms 1.150 ms 3 be2831.ccr21.mci01.atlas.cogentco.com (154.54.42.165) 12.541 ms be2832.ccr22.mci01.atlas.cogentco.com (154.54.44.169) 16.431 ms 4 be3036.ccr22.den01.atlas.cogentco.com (154.54.31.89) 23.957 ms be3035.ccr21.den01.atlas.cogentco.com (154.54.5.89) 23.820 ms 5 be3046.ccr21.elp01.atlas.cogentco.com (154.54.0.45) 36.725 ms be3047.ccr21.elp01.atlas.cogentco.com (154.54.1.125) 36.957 ms 6 be2930.ccr32.phx01.atlas.cogentco.com (154.54.42.77) 44.976 ms be2929.ccr31.phx01.atlas.cogentco.com (154.54.42.65) 44.659 ms 7 be2932.ccr42.lax01.atlas.cogentco.com (154.54.45.162) 56.892 ms 56.898 ms 8 be3359.ccr41.lax05.atlas.cogentco.com (154.54.3.70) 56.621 ms be3243.ccr41.lax05.atlas.cogentco.com (154.54.27.118) 56.532 ms 9 38.104.85.170 (38.104.85.170) 56.920 ms 56.904 ms 10 * * 11 vlan2909.as09.lax1.us.m247.com (193.9.115.169) 56.739 ms vlan2921.as09.lax1.us.m247.com (193.9.115.167) 56.890 ms 12 * * 13 * * 14 * * Notice how hop 7 is going from Phoenix to Los Angeles? If the server was physically in Phoenix, there would be no reason to do that. All signs point to this server being physically located in Los Angeles. There's a possibility that they terminate the network in Los Angeles and then have private backhaul (like a GRE tunnel) from LA to Phoenix, but I wouldn't bet on it, especially with the 0.4ms pings from Los Angeles.
  26. 1 point
    Argno

    Bitcoin ATMs that don't require ID?

    https://coinatmradar.com/
  27. 1 point
    I still use AirVPN. The latest version of these commands is here: https://github.com/tool-maker/VPN_just_for_torrents/wiki/Maintaining-SSH-Access-Using-a-VPN-on-a-Remote-Linux-Server The scripts there are the ones I currently use. They support IPv6 too. If you use AirVPN's client, be sure you turn off "network lock".
  28. 1 point
    Hello! We're very glad to announce that we have just released Hummingbird for Apple M1 based machines. Hummingbird is a robust, light-weight and very fast OpenVPN 3 command line tool for Linux and macOS offering DNS handling and rock solid traffic leaks prevention out of the box. It's the first time that OpenVPN 3 library and Hummingbird are available as native software in M1 based Mac computers, providing faster execution speed and higher performance. As usual Hummingbird uses our OpenVPN 3 AirVPN library fork, which includes bug fixes and very important features missing in the main branch. Please find overview, details, documentation and download link here: Kind regards
  29. 1 point
    As you can probably see, the error message is different. Ergo, open your own thread or simply search before you post. If you'd done the latter, you would probably find a post like this:
  30. 1 point
    5013965704666

    Suggestion: YubiKey MFA Support

    Hi, I wondered if alternative MFA support was on the Air team's roadmap? I'd love to see some support for YubiKey if possible.
  31. 1 point
    Sorry for the late reply. Yes, that is the solution I ended up with. Didn't want to share the solution/workaround though, as it does double the traffic on the AirVPN servers. I've tried it on Windows, ubuntu and Arch Linux. Can't remember if I also tried on debian. I didn't want to do the VirtualMachine solution and the other solutions I found online require some knowledge about networking I think. Did manage to get it working on linux though, without Virtual Machine. Using Arch Linux with Gnome and NetworkManager (with openVPN) -> Add internet connection -> Add VPN connection -> Autostart VPN on connection (nm-connection-editor) -> Install Eddie UI (airvpn-bin from AUR) -> Reboot -> PC connects automatically to VPN with NetworkManager -> Manually connect to a second VPN through Eddie UI So basically, when my computer boots it connects to a VPN through NetworkManager and autostarts Eddie UI. I then manually choose a server to connect to through Eddie. When the PC starts the exit IP is the VPN through NetworkManager. When I connect with Eddie UI the exit IP is the one I connected through Eddie. I have tested the solution by monitoring the bandwidth through the AirVPN client site showing connection statistics. I can see that I have 2 connections open and that both connections transfer the data. Also, I can monitor my network traffic at my ISP's site and I can see that the data is not downloaded twice meaning that there is not some sort of bouncing back and fourth I think.
  32. 1 point
    decided to switch on my Pfsense router just now. running a ARM Cortex-A9 r4p1 processor on the latest version: 2.5.0-DEVELOPMENT (arm) built on Fri Nov 27 06:54:52 EST 2020 FreeBSD 12.2-STABLE not having ANY performance hits so far whatsoever. if anything it seems more responsive
  33. 1 point
    Hello! We're very glad to introduce a new software suite for Linux which is ready for public beta testing. The suite includes the well known Hummingbird software, updated to the latest OpenVPN AirVPN library, and introduces for the first time a D-Bus controlled, real daemon, Bluetit, as well as a command line client, Goldcrest, to interact with Bluetit. UPDATE 11-Dec-2020: version 1.0.0 Beta 3 has been released. UPDATE 23-Dec-2020: version 1.0.0 RC 1 has been released New architecture The client-daemon architecture we introduce for the first time in our software offers a more robust security model and provides system administrators with a fine-grained, very flexible access control. Bluetit is fully integrated with AirVPN. The daemon is accessed through a D-Bus interface by providing specific methods and interface in order to give full support to OpenVPN connection and AirVPN functionality, including - but not limited to - quick automatic connection to the best AirVPN server for any specific location as well as any AirVPN server or country. New OpenVPN 3 library features Starting from version 1.0 beta 2, Hummingbird and Bluetit are linked against a new version of our OpenVPN 3 library which supports directive data-ciphers: it can be used consistently with OpenVPN 2.5 syntax in OpenVPN profiles. The directive allows OpenVPN 3 based software to negotiate a common Data Channel cipher with the OpenVPN server,, updating therefore our library to ncp-like negotiation with OpenVPN 2 branch. Hummingbird and Bluetit are already linked against the new library version, while Eddie Android edition will be updated in the near future. The new library also includes a different handling of IV_CIPHERS variable, fixing OpenVPN main branch issues causing a plethora of problems with OpenVPN 2.5. The implementation, at the same time, takes care of full backward compatibility with OpenVPN versions older than 2.5. ncp-disable directive, which to date has never been implemented in the main branch, is still supported, in order to further enhance backward compatibility with both OpenVPN profiles and servers, as well as connection flexibility with servers running older than 2.5 OpenVPN versions. Please note that if you enforce a specific Data Channel cipher by means of Bluetit configuration file, Hummingbird line option, or Goldcrest configuration file and/or line option, the enforced Data Channel cipher will override data-ciphers profile directive. Changelog 3.6.6 AirVPN by ProMIND - [ProMIND] [2020/11/02] openvpn/ssl/proto.hpp: IV_CIPHERS is set to the overridden cipher only (both from client and/or OpenVPN profile) in order to properly work with OpenVPN 2.5 IV_CIPHERS specifications. The old method of cipher overriding by means of negotiable crypto parameters is still supported in order to maintain compatibility with OpenVPN < 2.5.0 - [ProMIND] [2020/11/24] added "data-ciphers" directive to profile config .ovpn files in order to comply to OpenVPN 2.5 negotiable data cipher specifications. In case "data-ciphers" is found in the .ovpn files IV_CIPHERS is assigned to the algorithms found in "data-ciphers". In this specific case, "cipher" directive is used as a fallback cipher and, if not already specified in "data-ciphers", is appended to IV_CIPHERS Coming soon When we get out of the beta testing, we plan to document Bluetit interface to let anyone write a custom client and talk with the daemon. Furthermore, Goldcrest will evolve in the near future and will include an ncurses based TUI which will be very comfortable when you don't want to rely on command line options while a new Bluetit client, based on Qt, will be developed in the future, for those who prefer a GUI. Notes on systemd-resolved Version 1.0.0 beta 2 and subsequent versions fix a serious issue on systemd based systems running concurrently systemd-resolved and network-manager, for example Fedora 33 in its default configuration. In Fedora 33 systemd-resolved comes pre-configured to work in "on-link" mode and network-manager works together with it. This very peculiar, Windows-like setup finally kills Linux global DNS handling, adding to it those so far missing DNS leaks which made every Windows user nightmares more colorful. Any Microsoft system lacking the very concept of global DNS is now emulated, for an outstanding 30 years back time travel.. However, Hummingbird and Bluetit take care of preventing the brand new DNS leaks potentially caused by such smart setup, giving back Fedora + VPN users more peaceful nights. Also note that systemd-resolved comes pre-configured with fallback DNS (Google DNS is a systemd-resolved default fallback DNS, smart choices pile up!) which will be queried if each interface DNS server fails some resolution. In such a case, if and only if you have Network Lock enabled DNS leaks will be prevented. Supported systems The suite is currently available for Linux x86-64, i686 (32 bit distributions), arm7l (for example Raspbian and other ARM 32 bit based systems) and aarch64 (ARM 64 bit). Please note that the source code will be published with the stable release as usual. The software will be licensed under GPLv3. Overview and main features AirVPN’s free and open source OpenVPN 3 suite based on AirVPN’s OpenVPN 3 library fork Version 1.0.0 Beta 2 - Relase date 27 November 2020 Bluetit: lightweight D-Bus controlled system daemon providing full connectivity to AirVPN servers and generic OpenVPN servers Goldcrest: Bluetit client, allowing full integration with AirVPN servers, users, keys, profiles as well as generic OpenVPN servers Hummingbird: lightweight and standalone client for generic OpenVPN server connection Linux i686, x86-64, arm7l and arm64 (Raspberry) support Full integration with systemd, SysVStyle-init and chkconfig No heavy framework required, no GUI Tiny RAM footprint Lightning fast Based on OpenVPN 3 library fork by AirVPN version 3.6.6 with tons of critical bug fixes from the main branch, new cipher support and never seen before features ChaCha20-Poly1305 cipher support on both Control and Data Channel providing great performance boost on ARM, Raspberry PI and any Linux based platform not supporting AES-NI. Note: ChaCha20 support for Android had been already implemented in our free and open source Eddie Android edition Robust leaks prevention through Network Lock based either on iptables, nftables or pf through automatic detection Proper handling of DNS push by VPN servers, working with resolv.conf as well as any operational mode of systemd-resolved additional features Full documentation: README.md Download links: Linux x86-64: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-x86_64-1.0.0-RC-1.tar.gz Linux x-86-64 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-x86_64-1.0.0-RC-1.tar.gz.sha512 Linux i686: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-i686-1.0.0-RC-1.tar.gz Linux i686 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-i686-1.0.0-RC-1.tar.gz.sha512 Linux arm7l: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-armv7l-1.0.0-RC-1.tar.gz Linux arm7l sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-armv7l-1.0.0-RC-1.tar.gz.sha512 Linux aarch64: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-aarch64-1.0.0-RC-1.tar.gz Linux aarch64 sha512 check file: https://eddie.website/repository/AirVPN-Suite/1.0-RC1/AirVPN-Suite-aarch64-1.0.0-RC-1.tar.gz.sha512 Please report bugs and any problem in this thread, thank you! Kind regards AirVPN Staff
  34. 1 point
    solved. I'm unable to replicate the issue now, as this seems like an issue only at initial setup. When eddie was first run, the 'main window' is automatically shown in order to provide login credentials. This window is NOT able to be brought to focus by using the gui/mouse. No amount of clicking on the window (even quitting the program or restarting the computer) would give the window focus. Only by going to the menu bar and selecting the option 'Show main window' will give the window focus and allow me to enter the credentials. Once this was done I was able to get logged in/connected. Now, the 'main window' does not show automatically on launch. The only way to get to the window is with the menu bar selection. FYI this is the last series of intel i5 macbook prior to the M1 release running Big Sur 11.1
  35. 1 point
    @fkeriviavcxjhvjke Hello! You have three options. 1) Run AirVPN Suite 1.0.0. It will take care properly of DNS push even when systemd-resolved is configured to work in on-link mode bypassing resolv..conf and even when it works together with network-manager. Tested successfully under new Fedora 33 default settings. The suite is free and open source software by AirVPN, based also on a robust client-daemon architecture, and offers Network Lock (for traffic leaks prevention) which works fine even in Fedora 33. See here: https://airvpn.org/forums/topic/48435-linux-new-software-airvpn-suite-10-beta/ 2) Disable systemd-resolved and re-create /etc/resolv.conf file to work with global DNS as usual, instead of the questionable and dangerous per-link basis mode. After that, you can either run AirVPN Suite 1.0.0, OpenVPN with update-resolv-conf script, or Eddie. Eddie is a free and open source software by AirVPN with a GUI running in Mono. Only when systemd-resolved is disabled or re-configured to respect /etc/resolv.conf, can Eddie be used in Fedora 33. If you choose to run OpenVPN directly, remember that OpenVPN does not handle DNS push on Linux on the client side, so use the mentioned script. Please see here: https://airvpn.org/forums/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ 3) Not recommended. Run OpenVPN with script update-resolved-systemd. Again see https://airvpn.org/forums/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/ Kind regards
  36. 1 point
    hamstersearch

    AirVPN Sales - Things To Know

    Thanks for sharing this, Extremely good post
  37. 1 point
    Staff

    Wireguard plans

    @wireguard User "wireguard" is not an account with a valid AirVPN plan If you really wanted to show your support to AirVPN and prove that you are a customer, you would have written from an account with a valid plan. In reality, accounts like "wireguard" seem to be created with the only purpose to pump something and defame something else. From now on, write only from an account that has valid plan, to show that you are in good faith. Our plans about putting Wireguard into production in the near future have been published with a lot of details, albeit without a precise release date (and we have thoroughly explained why), so we will not write again for the nth time about them. About performance, please provide details as we do frequently. Currently we outperform Wireguard with our setup in AES-NI supporting systems, as you can see from our and our customers' tests, while Wireguard can outperform OpenVPN in CHACHA20 in non-AES-NI supporting systems. . When we put Wireguard into production, OpenVPN will stay, so investing in our own OpenVPN development is perfectly fine. Just a few reasons that make OpenVPN superior to Wireguard for many, different needs: it's faster than Wireguard in AES-NI supporting systems when it uses AES. Have a look here! it can be connected over stunnel, SSH, SOCKS5 and HTTP proxies, and Tor swiftly even for the above reason, for an ISP it's not so easy to block OpenVPN, while it's trivial to block Wireguard it supports TCP it supports dynamic IP address assignment it supports DNS push it does not hold in a file your real IP address when a connection is closed a significant part of our customers will not be able to use Wireguard effectively, simply because UDP is totally blocked in their countries or by their ISPs UDP blocking and heavy shaping are becoming more and more widespread among mobile ISPs, making Wireguard slower than OpenVPN in TCP even in mobile devices, or not working at all in mobility About Torvalds and Linux kernel, you only tell a part of the story. Wireguard was first put in some Linux kernel line when Wireguard was still in beta testing and no serious audit was performed, and not put in a kernel milestone release. A further note about battery draining you mentioned in one of your previous messages: our app Eddie Android edition and Wireguard, when used with the SAME bandwidth and the SAME cipher (CHACHA20-POLY1305), consume battery approximately in the same way, so that's yet another inessential point that does not support your arguments and show once more that our investments have been wise. Finally, let's spread a veil on your embarrassing considerations on ciphers, security, privacy and NSA. Let's underline only that CHACHA20.-POLY1305 is very strong, the cipher algorithm in itself (if implemented correctly) is not a Wireguard problem in any way. It would be a reason of deep concern if Wireguard needed OpenVPN defamation to convince us that it's a good software. Unfortunately various bogus accounts have been created with such assumption and purpose, and the hidden agenda is no more hidden. Kind regards
  38. 1 point
    Thank you for the quick answer. I disabled the service using those commands : $ sudo systemctl stop systemd-resolved $ sudo systemctl disable systemd-resolved Now I can use the default configuration for Eddie, and it doesn't leak DNS anymore according to ipleak.net . I'll wait for an update to use systemd-resolved in the future, which seems to bring new features. Kind regards.
  39. 1 point
    Staff

    ANSWERED Eddie Checking DNS failed.

    @McLoEa Good to know, thank you for the info. We are checking how to address the issue with systemd-resolved working in that specific mode. Kind regards
  40. 1 point
    Input file is optional, it expects stdin if no input file is presented. I was more or less just toying with the idea of piping so it would be possible to do something like "cat AirVPN.ovpn | ./airvpn_remotes.sh > AirVPN_new.ovpn". But you're right, considering some people may not care for the script's functionality of inline replacing those lines it would probably be better to handle lack of an input-file and stdin as just generating without the original config, which then the user could manually add to their config. I've made that change to the script and updated the OP (which resolves both your improvement suggestion and your remark). Other possible improvements I've considered: allowing the script to update the config's IP protocol. e.g. using IPv6 or IPv4 exclusively (I'm not well versed with OpenVPN configurations so I'd just have to compare the configs I generate from AirVPN's terminal) giving a flag for transport protocol tcp/udp to update / add that respective line more comprehensive scanning of the IPs, instead of a simple ICMP the script could also (optionally) check TCP + UDP availability on the supplied port - granted at some point this evolves from a simple availability checking script to a port scanning script which would get you flagged by your ISP, which I want to avoid. so maybe not the best idea validate the provided port against possible ports instead of requiring the user to specify the DNS query being made explicitly (should they not want the default) and requiring them to refer to AirVPN's FAQ page to figure out which FQDN they need to ping, I could instead have preset options/values. It would make it less flexible though. could add an option to query ALL vpn servers used by AirVPN (the earth.all.vpn.airdns.org record), test them, then add filtering options to either filter by maximum remotes desired (e.g. 20 by default) or by maximum ping allowed Ultimately though I made the script to accomplish my goal, and then got lost refining it to make it pretty. Most of my possible improvements provide no benefit to me and probably minimal benefit for other users, so I'll probably just keep it as is. Additionally, the script itself has the main drawback of specifically using their IPs for single servers and not their DNS records that update every 5 minutes to load balance their servers (which isn't really a drawback in a case like mine where some of their servers are completely blocked). Thanks for taking a look, the compliments, and the advice!
  41. 1 point
    agent008

    ExpressVPN: Is it worth the money?

    It's already said: the choice of VPN provider depends a lot on your personal needs and wishes. Are you a Showden or a dude who just wants to watch Netflix? For me, comparing ExpressVPN to AirVPN, the main things I like of ExpressVPN compare to AirVPN: - Third party auditing. It's always good to have an independant entity compare your promises with reality. - RAM driven servers. Simply said, this architecture means that logs CANNOT be stored. - Being based in British Virgin Islands. Although having historical and present ties to UK, they are autonomous since 1967. They are not part of the Five Eyes. What I like about AirVPN: - Eddie is open source. Anybody can compare promises with reality. - The superior kill switch, which works essentially differently than you average kill switch. As far as I know, AirVPN is the only VPN povider with such a network locking system. - Some security features are impressive and well-overthought. For example, the Diffie-Hellman key exchange with client-side lowerable re-keying interval is just unhackable. - Founded and run by activists. And I think the last one is maybe the most important. Many serious VPN providers have slightly different but decent enough technique, performance and options. All of them say "zero logs!" (while some of them have been caught logging AND handing over data). It all comes down to trust. Who would you trust more? A privacy activist with open source software or a businessman with closed source software? That being said, I wouldn't mind if AirVPN would have a third party do some auditing and go for fully RAM driven servers too. Never mind being based in 14-Eyes-Italy - it's remarkable that AirVPN doesn't have any servers (anymore) in Italy. Altogether I would choose for AirVPN, even if ExpressVPN was half price. Actually I did, and having approx. 1500 days left, with no regrets so far. It's being said that AirVPN is 'too technical' for some, but is that so? It's very possible to just install Eddie and use it out-of-the-box without studying settings and options for hours. It might be suitable for your sister as well. Why not try a one month's subscription? Please note the disclaimer: "This is my personal opinion. My advice should never be followed blindly." As for ProtonMail vs. Tutanota, I simply don't trust ProtonMail (anymore). They said it themselves at the start: accepting outside financing would mean loosing credibility. So it's simple. Since they accepted outside financing (March 2015, see https://protonmail.com/blog/protonmail-has-raised-2m-usd-to-protect-online-privacy/ ), they lost credibility. Mind you, this outside financing is done by Fongit (which is financed by the Geneva district of Switzerland) and by CRV, with eyebrow-frowning ties to US intelligence. CTemplar has the advantage of being based in Iceland, which is a pro compared to Switzerland (with an MLAT treaty with USA) or Germany (a 14 Eyes country). But also here it comes down to trust and where that trust is based upon.
  42. 1 point
    I keep reading reviews about great VPNs maxing out a user's connection, but I can't get anywhere close to what I'm reading about. After trying quite a few VPNs and being disappointed with the speeds I figured I would just go with AirVPN, since it gets such fantastic reviews, and I've seen people talking about maxing out their 50 and 100 Mbit connections. I'm on a 50 Mbit connection that usually gets around 54 Mbit, but the max I can get with AirVPN is 10 Mbit. I've tried different ports, their client vs. OpenVPN, numerous servers, and the results are the same, 2 to 10 Mbit. I'm in Vancouver, BC, and even when I'm connected to one of their Vancouver servers (Cetus, Gemma, Homam), I'm getting 2-10 Mbit speeds. It just doesn't make sense to me based on what I've read about AirVPN. Is it possible it has something to do with my ISP, Telus? Do they mess with VPN traffic? I would really like to start using a VPN regularly for privacy, but none of the speeds I've gotten will allow me to do so without being incredibly frustrated all the time. EDIT: I'm literally on AirVPN as I type this, with a download speed of 1.45 Mbit (using AirVPN's speed tester), connected to a 1 Gbit server/connection that's local, has a 29ms response time, and only has 11% capacity right now. It just doesn't make a whole lot of sense to me. EDIT 2: It seems as though the issue is with one of the main network providers in my area. If I avoid local servers and use ones that are further away, where the problem servers are bypassed, my VPN speeds double. The speeds still aren't close to what other people have talked about getting, but it may be manageable now. Thanks to everyone who helped me troubleshoot this!
  43. 1 point
    I've set up a SystemD Service (See below), which works a treat, but are there other options that I should consider adding/using? [Unit] Wants=network-online.target After=network-online.target [Service] Type=simple ExecStart=eddie-ui --cli --netlock -login=NotMyUserName -password=NotMyPassword123 -connect --batch path=/etc/airvpn/ Restart=always RestartSec=10s [Install] WantedBy=default.target
  44. 1 point
    festus8888

    Turning off sound effects

    Is there an easy way to turn off the sound effects when connecting, disconnecting, etc. ?
  45. 1 point
    Hello! Nowadays, traffic shaping is a common practice. Several ISPs have evaluated that investing in traffic shaping techniques is better than investing in infrastructure expansion. Overselling becomes easier and the devastating congestion impact gets mitigated by enforcing penalties to all protocols which are rarely used by the majority of customers or that are more onerous for the infrastructure. Protocols and traffic types are discovered in real time via SPI and DPI. A VPN impairs traffic shaping techniques because it makes both SPI and DPI impotent. Therefore, ISPs that share the above vision (wild overselling and traffic shaping) need to shape VPN themselves, unconditionally. OpenVPN has a typical fingerprint, so it's easy to identify it with DPI. However, we provide connection modes which make OpenVPN not discernible. The most effective and at the same time efficient is a connection with "tls-crypt" which encrypts the whole OpenVPN Control Channel. It is available on entry-IP addresses 3 and 4 of our VPN servers. Please test the following one (in Eddie desktop edition): - from Eddie main window select "Preferences" > "Protocols" - untick "Automatic" - select the line with entry-IP address 3, port 443, protocol TCP. The row will be highlighted in blue - click "Save" tls-crypt will circumvent specific OpenVPN shaping, while TCP will get rid of UDP shaping, which is another commonly targeted protocol. UDP might be shaped or not in your line, so it's worth that you try it too. Eddie Android edition 2.0 connects to entry-IP address 3 by default. You might anyway need to change the protocol from UDP to TCP in the "Settings" if UDP is throttled. Kind regards
  46. 1 point
    Fuck it. If you want to make a fool of yourself go right ahead. I have repeatedly told you why this thread shouldn't exist, but if you want to infer that I'm practically a book burning Nazi, then go right ahead. You can voice your opinion all you want . But you should be prepared for the rest of us to use our opinions to shit on yours.
  47. 1 point
    They explain a problem you will encounter and then (if you follow more links) ways of solving the problem. As I said in the same post, I DO this! It IS possible. If you want me to provide a customized recipe just for you here in this thread, I am going to disappoint you. UPDATE: ======= I changed my mind. Here is a recipe. I did not actually explain the problem above. The problem is that the default gateway gets changed by OpenVPN, and that breaks your current SSH connection unless you set up appropriate routes before you start OpenVPN. It is assumed here that the default gateway interface before OpenVPN is started is "eth0". This is the usual convention for Linux systems. It should ensure that when a connection to eth0 is made, even if eth0 is not the default gateway interface anymore, response packets for the connection go back on eth0 again. # set "connection" mark of connection from eth0 when first packet of connection arrives sudo iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234 # set "firewall" mark for response packets in connection with our connection mark sudo iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321 # our routing table with eth0 as gateway interface sudo ip route add default dev eth0 table 3412 # route packets with our firewall mark using our routing table sudo ip rule add fwmark 4321 table 3412=== UPDATE to UPDATE: The above works fine for me on Debian Jessie. But on an older Wheezy system I have just found that I need to add "via" to the routing table entry: # our routing table with eth0 as gateway interface sudo ip route add default dev eth0 via 12.345.67.89 table 3412There "12.345.67.89" must be the original non-VPN gateway.
  48. 1 point
    Probably because they decided not to use women and children as suicide bombers, or fire rockets indiscriminately into civilian areas. But this isn't really the place to discuss it.
  49. 1 point
    Probably because they decided not to use women and children as suicide bombers, or fire rockets indiscriminately into civilian areas. But this isn't really the place to discuss it.
  50. 1 point
    Staff

    Windows & Comodo - Prevent leaks

    Hello! Previous thread on Windows and Comodo to prevent DNS leaks and leaks in case of unexpected VPN disconnection have become very big and detailed. We invite you to consult those threads for details and support, while we publish this message as a quick, clarifying overview of the essential steps. Please note that if you don't use Windows you don't need to read this post. If you use Windows and a firewall other than Comodo, you can anyway take these rules as an example and adapt them to your firewall. This is a minimal set of instructions to prevent any leak in case of unexpected VPN disconnection and prevent, in any case, DNS leaks, on Windows system with Comodo firewall. Comodo firewall is currently the only firewall we recommend for Windows. The free version is just fine for our purposes. Never rename the rules: in case you need support, we need to see what the rules really state. 1) If you're not familiar with a firewall, read Comodo Firewall manual or guides. In particular, please see the following: https://help.comodo.com/topic-72-1-451-4773-global-rules.html https://help.comodo.com/topic-72-1-451-4884-Network-Zones.html 2) Install Comodo Personal Firewall free version available here: https://personalfirewall.comodo.com/ 3) Set the Firewall Security Level to "Custom Policy" 4) Determine or create the Network Zone of your TAP-Win32 network adapter (from now on "AirVPN"). A safe way to define it: IP Range [10.1.0.0 - 10.255.255.255] if you need OpenVPN over SSH/SSL and other alternative connection modes, see also https://airvpn.org/specs 5) Determine the entry-IP addresses of the AirVPN server(s) you wish to connect to: https://airvpn.org/topic/14378-how-can-i-get-vpn-servers-entry-ip-addresses 6) Define a "Global Rule" which blocks everything: Block And Log IP In/Out From MAC Any To MAC Any Where Protocol Is Any The logging is important for troubleshooting if necessary. 7) Put the above Global Rule in the top position. This will block completely your connectivity and let you add a whitelist of Allow global rules put BEFORE this total block global rule. All the "Allow" rules that you want to be evaluated shall be put BEFORE (i.e. higher than) the above block rule. 8) Define a"Global" rule which allows in/out communications of your TAP-Win32 adapter ("AirVPN") both In and Out: Allow IP In/Out From In [AirVPN] To MAC Any Where Protocol Is Any Allow IP In/Out From MAC Any To In [AirVPN] Where Protocol Is Any 9) Do the same for your loopback zone (IP range 127.0.0.1 - 127.255.255.254) Allow IP In/Out From In [Loopback Zone] to MAC Any Where Protocol Is Any Allow IP In/Out From MAC Any To In [Loopback Zone] Where Protocol Is Any 10) Do the same for any entry-IP address of the VPN servers you wish to connect to. For example for Leporis: Allow TCP or UDP In/Out From IP 95.211.191.33 To MAC Any Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From MAC Any To IP 95.211.191.33 Where Source Port Is Any And Destination Port Is Any For your comfort, you might define a Network Zone (for example [Air servers entry IPs]) containing only the entry-IP addresses of our servers and then set two rules like Allow TCP or UDP In/Out From In [Air servers entry IPs] To MAC Any Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From MAC Any To In [Air servers entry IPs] Where Source Port Is Any And Destination Port Is Any In this way, you will only need to add a single IPv4 address to that Network Zone in order to connect to a new server, instead of defining two additional rules for each server, which may be annoying if you switch between a lot of servers. 11) Add similar rules to allow communications of your device with your router (and within your home/office network, if you wish so). For example, if your network is [192.168.0.0 / 255.255.0.0] define a network zone with IP Range [192.168.0.0 - 192.168.255.255] (let's call it "Home Network") and set the following rules: Allow TCP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Any Allow UDP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Not 53 Allow ICMP In/Out From In [Home Network] To In [Home Network] Where ICMP Message Is Any 11a) Allow DHCP "negotiation": Allow IP In/Out From MAC Any To IP 255.255.255.255 Where Protocol Is Any 12) In order to allow "airvpn.org" resolution even when disconnected (and any other hostname you wish to be resolved even when VPN is disconnected), add to your hosts file the line: 95.211.138.143 airvpn.org Do not forget about this change! If we change our main frontend IP address, you will not be able to reach airvpn.org anymore until you remove that line. No more necessary starting with Air client edition 2 "Eddie". 13) If you use the Air client, add rules to allow communications with IP addresses 5.196.64.52 and 95.211.138.143 (two of our frontend servers), In and Out Allow TCP or UDP In/Out From IP 5.196.64.52 To MAC Any Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From MAC Any To IP 5.196.64.52 Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From IP 95.211.138.143 To MAC Any Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From MAC Any To IP 95.211.138.143 Where Source Port Is Any And Destination Port Is Any 14) You can progressively enlarge your whitelist just by adding "Allow" rules before the total blocking rule of point 6) according to your system needs. Keep in mind that there are literally dozens of ways to accomplish the same task with Comodo. Pay attention not to confuse the "-" symbol, which stands for "IP range", with the "/" symbol, which stands for IP address / NetMask. For example, [10.4.0.0 - 10.9.255.255] is correct (the IP range from 10.4.0.0 to 10.9.255.255), while [10.4.0.0 / 10.9.255.255] is NOT correct (IP 10.4.0.0 NetMask 10.9.255.255, which covers almost every existing IP address!). When you have defined all the rules, do not forget to click "Apply" and "OK" in order to store them and make them active for any new connection. Test everything and do not be afraid to experiment before you rely on the secured connection for sensitive data transmissions. Kind regards
×
×
  • Create New...