Leaderboard

I've had problems with IPv6 error as described and also Network Lock function since upgrading to 2.19.7 on Windows 10 Home. Tried thoroughly uninstalling and downgrading to an older version of Eddie but it didn't improve. Then tried uninstalling Eddie and installing OpenVPN 2.5 instead. Still had errors. Therefore Eddie was not the problem. Something in the log led me to try "Reset Network TCP/IP Stack" which I found at Open VPN's Community Wiki. It fixed my problem. Seems there are other ways to reset Window's network stack if you search for it. Below is taken from the Open VPN Wiki. Good luck! Windows Vista, 7, 8, 10 Search for Command Prompt > Run As Administrator > Enter the following commands one at a time > Restart computer. netsh winsock reset catalog netsh int ipv4 reset reset.log netsh int ipv6 reset reset.log

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.

Of course not. All traffic is routed through the VPN. In comes the connection from 1.2.3.4 (your ISP), out goes the answer on 5.6.7.8 (VPN server). Your router/firewall doesn't expect a connection from 5.6.7.8 and silently drops whatever comes from there. You can avoid this by excluding your ISP IP from being routed on the remote machine. That way, the answer will be sent to 1.2.3.4 if it comes from 1.2.3.4.

Ok now! Thx a bunch. regards

It's oke now...thanks

Hello! We're glad to inform you that AirVPN Suite 1.1.0 RC 3 is now available. Download URLs have been updated in this thread first message. AirVPN Suite 1.1.0 RC 3 aims at addressing RC 2 Bluetit problem or regression suffered in D-Bus message handling and found out (unfortunately not reproduced on our systems) by our community testers @pjnsmb @leori and @colorman Please keep testing RC 3! Version 1.1.0 RC 3 - 16 April 2021 - changelog [ProMIND] Updated to OpenVPN 3.7 AirVPN [ProMIND] vpnclient.hpp: avoid netFilter setup in case NetFilter object is not private [ProMIND] dbusconnector.cpp: fine tuned D-Bus wait cycle in R/W dispatch. Implemented a thread safe wait in order to avoid D-Bus timeout policy Kind regards

Activate where, on your machine or remote?

Same at opensuse leap15.2 2021-04-16 14:02:36 Maximum rate: In 28,16 Mbit/s, Out 1,21 Mbit/s ^C2021-04-16 14:03:26 Caught SIGTERM signal. Terminating.

Confirmed : no elegant shut-down RC2 ubuntu 20.04 : Caught SIGTERM signal. Had to kill zombie. kill -9 $(ps -A -ostat,ppid | grep -e '[zZ]'| awk '{ print $2 }') restore network via goldcrest

@Staff Real trouble using RC2 1# on goldcrest command : peter@desktop:~/Desktop/VPN$ goldcrest --air-connect --air-server Alathfar normal start of server but on using CTRL +C to terminate the last line shows : ^C2021-04-15 15:40:30 Caught SIGTERM signal. Terminating. but that is where it stops............ and the server remains connected. Full log : peter@desktop:~/Desktop/VPN$ goldcrest --air-connect --air-server Alathfar 2021-04-15 15:24:54 Reading run control directives from file /home/peter/.config/goldcrest.rc Goldcrest 1.1.0 RC2 - 14 April 2021 2021-04-15 15:24:54 Bluetit - AirVPN OpenVPN 3 Service 1.1.0 RC2 - 14 April 2021 2021-04-15 15:24:54 OpenVPN core 3.6.7 AirVPN linux x86_64 64-bit 2021-04-15 15:24:54 Bluetit is ready 2021-04-15 15:24:54 Bluetit options successfully reset 2021-04-15 15:24:54 Bluetit successfully set to command line options 2021-04-15 15:24:54 Requesting AirVPN connection to Bluetit 2021-04-15 15:24:54 Network filter and lock are using nftables 2021-04-15 15:24:54 Successfully loaded kernel module nf_tables 2021-04-15 15:24:54 Network filter successfully initialized 2021-04-15 15:24:54 Session network filter and lock successfully enabled 2021-04-15 15:24:54 AirVPN bootstrap servers are now allowed to pass through the network filter 2021-04-15 15:24:54 Logging in AirVPN user pjnsmb 2021-04-15 15:24:55 AirVPN user pjnsmb successfully logged in 2021-04-15 15:24:55 Selected user key: DESKTOP 2021-04-15 15:24:55 Starting connection to AirVPN server Alathfar, Maidenhead (United Kingdom) 2021-04-15 15:24:55 Starting VPN Connection 2021-04-15 15:24:55 TUN persistence is enabled. 2021-04-15 15:24:55 CIPHER OVERRIDE: CHACHA20-POLY1305 2021-04-15 15:24:55 Network lock set to 'nftables' by Bluetit policy 2021-04-15 15:24:55 Ignore DNS push is enabled by Bluetit policy 2021-04-15 15:24:55 OpenVPN core 3.6.7 AirVPN linux x86_64 64-bit 2021-04-15 15:24:55 Frame=512/2048/512 mssfix-ctrl=1250 2021-04-15 15:24:55 UNUSED OPTIONS 6 [resolv-retry] [infinite] 7 [nobind] 8 [persist-key] 9 [persist-tun] 10 [auth-nocache] 11 [verb] [3] 12 [explicit-exit-notify] [5] 2021-04-15 15:24:55 EVENT: RESOLVE 2021-04-15 15:24:55 Local IPv4 address 192.168.0.6 2021-04-15 15:24:55 Local IPv6 address 2a02:c7f:cc09:d900:e8e0:78ab:dbaa:b120 2021-04-15 15:24:55 Local IPv6 address fdda:2d87:d69a:0:66c2:963b:c4e3:9f3c 2021-04-15 15:24:55 Local IPv6 address fe80::154d:4265:bdaf:3d0 2021-04-15 15:24:55 Local interface enp3s0 2021-04-15 15:24:55 Setting up network filter and lock 2021-04-15 15:24:55 Allowing system DNS 127.0.0.1 to pass through the network filter 2021-04-15 15:24:55 Adding IPv6 server 2a01:a500:320:52a4:a5b8:604b:f9ee:869 to network filter 2021-04-15 15:24:55 Network filter and lock successfully activated 2021-04-15 15:24:55 Contacting [2a01:a500:320:52a4:a5b8:604b:f9ee:869]:443 via UDP 2021-04-15 15:24:55 EVENT: WAIT 2021-04-15 15:24:55 net_route_best_gw query IPv6: 2a01:a500:320:52a4:a5b8:604b:f9ee:869/128 2021-04-15 15:24:55 sitnl_route_best_gw result: via fe80::3e89:94ff:fef6:ead1 dev enp3s0 2021-04-15 15:24:55 net_route_add: 2a01:a500:320:52a4:a5b8:604b:f9ee:869/128 via fe80::3e89:94ff:fef6:ead1 dev enp3s0 table 0 metric 0 2021-04-15 15:24:55 Connecting to [2a01:a500:320:52a4:a5b8:604b:f9ee:869]:443 (2a01:a500:320:52a4:a5b8:604b:f9ee:869) via UDPv6 2021-04-15 15:24:55 EVENT: CONNECTING 2021-04-15 15:24:55 Tunnel Options:V4,dev-type tun,link-mtu 1522,tun-mtu 1500,proto UDPv4,comp-lzo,cipher CHACHA20-POLY1305,auth [null-digest],keysize 256,key-method 2,tls-client 2021-04-15 15:24:55 Peer Info: IV_VER=3.6.7 AirVPN IV_PLAT=linux IV_TCPNL=1 IV_PROTO=30 IV_CIPHERS=CHACHA20-POLY1305 IV_LZO_STUB=1 IV_COMP_STUB=1 IV_COMP_STUBv2=1 IV_IPv6=1 UV_IPV6=yes IV_GUI_VER=Bluetit - AirVPN OpenVPN 3 Service 1.1.0 RC2 IV_SSL=OpenSSL 1.1.0l 10 Sep 2019 2021-04-15 15:24:55 VERIFY OK: depth=1, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=airvpn.org CA/emailAddress=info@airvpn.org, signature: RSA-SHA1 2021-04-15 15:24:55 VERIFY OK: depth=0, /C=IT/ST=IT/L=Perugia/O=airvpn.org/CN=Alathfar/emailAddress=info@airvpn.org, signature: RSA-SHA512 2021-04-15 15:24:55 SSL Handshake: peer certificate: CN=Alathfar, 4096 bit RSA, cipher: TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD 2021-04-15 15:24:55 Session is ACTIVE 2021-04-15 15:24:55 EVENT: WARN TLS: received certificate signed with SHA1. Please inform your admin to upgrade to a stronger algorithm. Support for SHA1 signatures will be dropped in the future 2021-04-15 15:24:55 EVENT: GET_CONFIG 2021-04-15 15:24:55 Sending PUSH_REQUEST to server... 2021-04-15 15:24:55 OPTIONS: 0 [comp-lzo] [no] 1 [redirect-gateway] [ipv6] [def1] [bypass-dhcp] 2 [dhcp-option] [DNS] [10.5.46.1] 3 [dhcp-option] [DNS6] [fde6:7a:7d20:12e::1] 4 [tun-ipv6] 5 [route-gateway] [10.5.46.1] 6 [topology] [subnet] 7 [ping] [10] 8 [ping-restart] [60] 9 [ifconfig-ipv6] [fde6:7a:7d20:12e::101d/64] [fde6:7a:7d20:12e::1] 10 [ifconfig] [10.5.46.31] [255.255.255.0] 11 [peer-id] [2] 12 [cipher] [CHACHA20-POLY1305] 2021-04-15 15:24:55 PROTOCOL OPTIONS: cipher: CHACHA20-POLY1305 digest: NONE ncp enabled: no key-derivation: OpenVPN PRF compress: LZO_STUB peer ID: 2 control channel: tls-crypt enabled 2021-04-15 15:24:55 EVENT: ASSIGN_IP 2021-04-15 15:24:55 WARNING: ignoring server DNS push request for address 10.5.46.1 2021-04-15 15:24:55 WARNING: ignoring server DNS push request for address fde6:7a:7d20:12e::1 2021-04-15 15:24:55 net_iface_mtu_set: mtu 1500 for tun0 2021-04-15 15:24:55 net_iface_up: set tun0 up 2021-04-15 15:24:55 net_addr_add: 10.5.46.31/24 brd 10.5.46.255 dev tun0 2021-04-15 15:24:55 net_addr_add: fde6:7a:7d20:12e::101d/64 dev tun0 2021-04-15 15:24:55 net_route_add: 0.0.0.0/1 via 10.5.46.1 dev tun0 table 0 metric 0 2021-04-15 15:24:55 net_route_add: 128.0.0.0/1 via 10.5.46.1 dev tun0 table 0 metric 0 2021-04-15 15:24:55 net_route_add: ::/1 via fde6:7a:7d20:12e::1 dev tun0 table 0 metric 0 2021-04-15 15:24:55 net_route_add: 8000::/1 via fde6:7a:7d20:12e::1 dev tun0 table 0 metric 0 2021-04-15 15:24:55 TunPersist: saving tun context: Session Name: 2a01:a500:320:52a4:a5b8:604b:f9ee:869 Layer: OSI_LAYER_3 Remote Address: 2a01:a500:320:52a4:a5b8:604b:f9ee:869 [IPv6] Tunnel Addresses: 10.5.46.31/24 -> 10.5.46.1 fde6:7a:7d20:12e::101d/64 -> fde6:7a:7d20:12e::1 [IPv6] Reroute Gateway: IPv4=1 IPv6=1 flags=[ ENABLE REROUTE_GW DEF1 BYPASS_DHCP IPv4 IPv6 ] Block IPv6: no Add Routes: Exclude Routes: DNS Servers: 10.5.46.1 fde6:7a:7d20:12e::1 [IPv6] Search Domains: 2021-04-15 15:24:55 Connected via tun 2021-04-15 15:24:55 LZO-ASYM init swap=0 asym=1 2021-04-15 15:24:55 Comp-stub init swap=0 2021-04-15 15:24:55 EVENT: CONNECTED [2a01:a500:320:52a4:a5b8:604b:f9ee:869]:443 (2a01:a500:320:52a4:a5b8:604b:f9ee:869) via /UDPv6 on tun/10.5.46.31/fde6:7a:7d20:12e::101d gw=[10.5.46.1/fde6:7a:7d20:12e::1] 2021-04-15 15:24:55 Connected to AirVPN server Alathfar, Maidenhead (United Kingdom) 2021-04-15 15:25:54 ---------------------- 2021-04-15 15:25:54 Connected to AirVPN server Alathfar (Maidenhead, United Kingdom) 2021-04-15 15:25:54 Users 55 - Load 27% - Bandwidth 276.03 Mbit/s - Max 1 Gbit/s 2021-04-15 15:25:54 Connection time: 00:01:01 2021-04-15 15:25:54 Transferred data: In 1.76 MB, Out 676.97 KB 2021-04-15 15:25:54 Current rate: In 177.52 Kbit/s, Out 71.04 Kbit/s 2021-04-15 15:25:54 Maximum rate: In 496.43 Kbit/s, Out 88.97 Kbit/s 2021-04-15 15:26:54 ---------------------- 2021-04-15 15:26:54 Connected to AirVPN server Alathfar (Maidenhead, United Kingdom) 2021-04-15 15:26:54 Users 55 - Load 27% - Bandwidth 276.03 Mbit/s - Max 1 Gbit/s 2021-04-15 15:26:54 Connection time: 00:02:01 2021-04-15 15:26:54 Transferred data: In 5.61 MB, Out 2.85 MB 2021-04-15 15:26:54 Current rate: In 5.91 Kbit/s, Out 8.25 Kbit/s 2021-04-15 15:26:54 Maximum rate: In 697.65 Kbit/s, Out 99.17 Kbit/s 2021-04-15 15:27:54 ---------------------- 2021-04-15 15:27:54 Connected to AirVPN server Alathfar (Maidenhead, United Kingdom) 2021-04-15 15:27:54 Users 55 - Load 27% - Bandwidth 276.03 Mbit/s - Max 1 Gbit/s 2021-04-15 15:27:54 Connection time: 00:03:01 2021-04-15 15:27:54 Transferred data: In 7.23 MB, Out 4.84 MB 2021-04-15 15:27:54 Current rate: In 8.57 Kbit/s, Out 21.22 Kbit/s 2021-04-15 15:27:54 Maximum rate: In 697.65 Kbit/s, Out 99.17 Kbit/s ^C2021-04-15 15:40:30 Caught SIGTERM signal. Terminating. 2# If I stop bluetit : root@desktop:~# systemctl stop bluetit root@desktop:~# systemctl status bluetit ● bluetit.service - AirVPN Bluetit Daemon Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Thu 2021-04-15 15:58:38 BST; 5s ago Process: 15853 ExecStart=/sbin/bluetit (code=exited, status=0/SUCCESS) Process: 117468 ExecStop=/bin/kill -- $MAINPID (code=exited, status=0/SUCCESS) Main PID: 15855 (code=killed, signal=KILL) CPU: 33.284s Apr 15 15:58:17 desktop bluetit[15855]: Received SIGTERM signal. Terminating Bluetit. Apr 15 15:58:17 desktop bluetit[15855]: Stopping OpenVPN3 connection thread Apr 15 15:58:17 desktop bluetit[15855]: Connection statistics updater thread finished Apr 15 15:58:38 desktop systemd[1]: bluetit.service: State 'stop-sigterm' timed out. Killing. Apr 15 15:58:38 desktop systemd[1]: bluetit.service: Killing process 15855 (bluetit) with signal SIGKILL. Apr 15 15:58:38 desktop systemd[1]: bluetit.service: Killing process 18314 (bluetit) with signal SIGKILL. Apr 15 15:58:38 desktop systemd[1]: bluetit.service: Main process exited, code=killed, status=9/KILL Apr 15 15:58:38 desktop systemd[1]: bluetit.service: Failed with result 'timeout'. Apr 15 15:58:38 desktop systemd[1]: Stopped AirVPN Bluetit Daemon. Apr 15 15:58:38 desktop systemd[1]: bluetit.service: Consumed 33.284s CPU time. 3# If I restart bluetit : root@desktop:~# systemctl restart bluetit root@desktop:~# systemctl status bluetit ● bluetit.service - AirVPN Bluetit Daemon Loaded: loaded (/etc/systemd/system/bluetit.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2021-04-15 16:01:51 BST; 3s ago Process: 126229 ExecStart=/sbin/bluetit (code=exited, status=0/SUCCESS) Main PID: 126231 (bluetit) Tasks: 2 (limit: 9362) Memory: 1.4M CPU: 22ms CGroup: /system.slice/bluetit.service └─126231 /sbin/bluetit Apr 15 16:01:51 desktop bluetit[126231]: Reading run control directives from file /etc/airvpn/bluetit.rc Apr 15 16:01:51 desktop bluetit[126231]: IPv6 is available in this system Apr 15 16:01:51 desktop bluetit[126231]: System country set to GB by Bluetit policy. Apr 15 16:01:51 desktop bluetit[126231]: Bluetit successfully initialized and ready Apr 15 16:01:51 desktop systemd[1]: Started AirVPN Bluetit Daemon. Apr 15 16:01:51 desktop bluetit[126231]: Bluetit did not exit gracefully on its last run or has been killed. Apr 15 16:01:51 desktop bluetit[126231]: Run recover network procedure or restore system settings saved in /etc/airvpn Apr 15 16:01:51 desktop bluetit[126231]: AirVPN Manifest updater thread started Apr 15 16:01:51 desktop bluetit[126231]: AirVPN Manifest update interval is 15 minutes Apr 15 16:01:51 desktop bluetit[126231]: Updating AirVPN Manifest Apr 15 16:02:51 desktop bluetit[126231]: AirVPN Manifest successfully retrieved from local instance Apr 15 16:03:40 desktop systemd[1]: Stopping AirVPN Bluetit Daemon... Apr 15 16:03:40 desktop bluetit[126231]: Received SIGTERM signal. Terminating Bluetit. Apr 15 16:03:40 desktop bluetit[126231]: AirVPN Manifest updater thread finished Apr 15 16:03:40 desktop systemd[1]: bluetit.service: Succeeded. Apr 15 16:03:40 desktop systemd[1]: Stopped AirVPN Bluetit Daemon. It takes nearly two minutes to stop the server and the goldcrest log still shows 'terminating' UPDATE closing terminal and reopening a new terminal shows : eter@desktop:~/Desktop/VPN$ goldcrest --air-connect --air-server Alathfar 2021-04-15 16:19:41 Reading run control directives from file /home/peter/.config/goldcrest.rc Goldcrest 1.1.0 RC2 - 14 April 2021 2021-04-15 16:19:41 DBusConnectorException: DBusConnector: not primary owner (2) UPDATE TWO I cannot stop goldcrest using htop either. Restarting the computer results in a 30 second delay on shutdown with : 'A stop job is running for session 1 of user peter' showing in close down terminal

I found the always-on vpn setting and disabled it, which fixed the problem. Thanks!

Legendary 6 and a half years necromancy. Though its been 3 weeks now without an answer. It would be good to hear an official response. I will bump and add my thoughts: Forwarded, yes. Forwarded ports are globaly unique for AirVPN and it's possible to know whose account it's currently forwarded on. I think the question to ask you what scenario you are trying to avoid was very on point. I very much doubt they'd give out your information to any small fish without a court order (that would be illegal, a violation of GDPR). And if it's a court order it'd need to be in Italy or be enforcable there (ianal). Basically until someone (not you obviously) angers some very big pockets, the privacy should be safe. If you want to be sure, rotate the forwarded port every 24 hours. Better yet, every time you connect (assign port) and disconnect (remove port). AirVPN has an API, use this unique feature to your advantage. As requested though. A Scenario: Let's say I host a website on a non-default port (port-forwarded) with satire and comedy of a certain Winnie Pooh and R. Dogan political leaders. Somehow they visited my funny comedic website but didn't find my short stories and comics about them funny and cried (a lot). They decide to sue AirVPN for identifiable information. The port is still tied to my account. Obviously AirVPN has no obligation to respond to Winnie Pooh's country's court system, but what if Mr. Dogan manages to get a court within the EU to issue an order? What if that order is issued in Italy vs. Non-Italy (EU member state)? In what case will AirVPN cause indirect harm to an aspiring comedian and disclose information? Can the comedian hope to be notified by AirVPN of this fact? (A non-question: can an AirVPN admin miss the button and accidentally click "unbind port" instead of "pwn user" button? Mistakes can happen, right?)

This way of thinking would only hurt AirVPN. The reason 'all other providers' are crap isn't because they can't better, it's their business decision. iirc AirVPN said their 'allocation' is 2 mbits per customer, now I can't say how that is applied but you can see very clearly thanks to transparency how many people are connected and how much bandwidth each server is currently using up. Scaling up is no problem, but it must be a business decision. If needed I'm sure they could fire up 10s of new servers within days etc. But an 'explosion' ain't gonna happen because they don't waste money on advertising, instead if you want to help - just help. Why are other VPN so bad? Because of overselling. There's a difference whether your servers run at 30% capacity or 80% (aka overloaded), it's money for the business and quality of service to the customer. If servers run at more than 70-80% then your latency will suffer, packet drops etc. The reason why AirVPN is solid is because they chose to. The reason why some other providers are shit is because they chose to (or are incompetent in addition to this). @NoiselessOwl says to rely on 'word-of-mouth' but then doesn't personally advertise AirVPN at all (I understand user's own word-of-mouth)? That goes against that idea. Users advertising themselves is the breeze of air that keeps AirVPN alive. Otherwise old customers would slowly drop out and no newcomers join. You can't singlehandedly make AirVPN become like a mainstream provider. I believe them to increase capacity when needed. Hell I doubt even a big youtuber or anything of sorts would make a dent if they were to advertise once (for free or not). I disagree strongly with the previous poster and want to say: Advertise AirVPN as best as you can (casually, it aint a chore nor a job)! If you want to see greatness, you need to help spread greatness. Don't leave less knowledgable users stuck to the shitty mainstream VPN services. PS: Does any other VPN out there pay as much close attention to the legal framework of server countries as AirVPN does? It's one of the main goals of a VPN provider! To ensure the security of your data!

Hi, [no!] Other than me there was only one other user who commented on using AirVPN. I want more people to know about our AirVPN and its awesome service. Should we/staff do something to make AirVPN more popular? Should staff contact the famous youtubers for testing out AirVPN to make it more popular?

Worth pointing out that the Hummingbird client works very nicely on M1 Macs (natively, without Rosetta), so consider that if you're comfortable with the command line. https://airvpn.org/forums/topic/48969-macos-apple-m1-hummingbird-111-released/

You're welcome.

Pause does not destroy the tunnel, only disconnect does. Are you sure you did not enable Always-On VPN in Android settings? This prevents all traffic on a system level unless the specified VPN app establishes a VPN connection.

so i cant add a ca file as everyone may know in pfsenses stunnel package manager under services without a certificate, meaning i need you guys to add a private key to the stunnel.crt file per config generator so i can create a proper certificate for my ca , need this to get stunnel proper encrypted thanks

So, Eddie now connects without issues?

Thanks for the reply. Don't worry, next time I wont post any thing/comment related to AirVPN anywhere.

would appreciate the help

I'm having problems with Hummingbird. My idea is to have a common TCP/443 .ovpn config file and specify the server on the command line. Here's the .ovpn config file (which, incidentally, works fine without any overrides): client dev tun remote bg3.all.vpn.airdns.org 443 resolv-retry infinite nobind persist-key persist-tun auth-nocache route-delay 5 verb 3 push-peer-info setenv UV_IPV6 no remote-cert-tls server cipher AES-256-GCM comp-lzo no proto tcp With server and port override: user@air-eur:~$ sudo hummingbird --server europe3.vpn.airdns.org --port 443 /etc/airvpn/tcp_443.ovpn Hummingbird - AirVPN OpenVPN 3 Client 1.1.2 RC 1 - 7 April 2021 Thu Apr 8 19:34:39.716 2021 System and service manager in use is systemd Thu Apr 8 19:34:39.736 2021 Network filter and lock are using iptables-legacy Thu Apr 8 19:34:39.750 2021 Successfully loaded kernel module iptable_filter Thu Apr 8 19:34:39.778 2021 Successfully loaded kernel module iptable_nat Thu Apr 8 19:34:39.796 2021 Successfully loaded kernel module iptable_mangle Thu Apr 8 19:34:39.816 2021 Successfully loaded kernel module iptable_security Thu Apr 8 19:34:39.837 2021 Successfully loaded kernel module iptable_raw Thu Apr 8 19:34:39.863 2021 Successfully loaded kernel module ip6table_filter Thu Apr 8 19:34:39.888 2021 Successfully loaded kernel module ip6table_nat Thu Apr 8 19:34:39.899 2021 Successfully loaded kernel module ip6table_mangle Thu Apr 8 19:34:39.909 2021 Successfully loaded kernel module ip6table_security Thu Apr 8 19:34:39.918 2021 Successfully loaded kernel module ip6table_raw ERROR: eval config error: ERR_PROFILE_GENERIC: option_error: error parsing protocol: tcp-client If I comment out the remote bg3.all.vpn.airdns.org line, it segfaults: user@air-eur:~$ sudo hummingbird --server europe3.vpn.airdns.org --port 443 /etc/airvpn/tcp_443.ovpn Hummingbird - AirVPN OpenVPN 3 Client 1.1.2 RC 1 - 7 April 2021 Thu Apr 8 19:42:18.195 2021 System and service manager in use is systemd Segmentation fault

@OpenSourcerer & @benfitita Thank you for your reply! I'm gonna stick with your suggestions with the config generator for now.

Really? Is this documented anywhere, including which settings are honoured / ignored? With respect, this is not a sensible approach. If a setting is not specified in either bluetit.rc or goldcrest.rc, the setting in the OpenVPN configuration file should be honoured. To selectively ignore some settings from the .ovpn files makes little sense.

@Staff, I tested the beta 2 after an uninstall of beta 1 and the bluetit daemon hasn't crashed anymore when the bandwidth is on high load. The problem seems indeed to be resolved. Well done ! 😉 Grts, Tom

Air runs some 100 MBit/s relay nodes and funds exit nodes. I think it was me writing the above in the past at various points, but it's not the case. I'd have gone back to the posts and corrected this misinformation if I found those threads again. 8 years of being here does leave an impressive yet difficult to skim through collection of one's own posts.

It's not so easy. People can mostly do what they like behind the VPN, including setting up Tor exits. I'm regularly speaking against doing so because the implications for other AirVPN users are greater than the gain for the Tor community. Also, nothing says that a "good" server will not turn bad at some point. Plus, it's not like a subset of servers are blocked everywhere and another is not; if that was the case, all people would always use good ones. No, it depends on the service you want to access. Some block Tor exits forever, others only bad IPs for some time only.

You're not artificially being throttled by Air. That's just the way things are with openvpn with limitations by CPU, network, internet, etc. A client on the usual 1gbit/s server will see only about 500mbit/s download max because the server throughput limit is 1gbit/s inbound and outbound combined. Air does have at least 1 server that's 10gbit/s. Try it to see if it's any better for you.

Tech support says no, and its not a bug its a feature. Apparently, closing Eddie first is required for an orderly PC shutdown. I dont buy it. My PC is now back on 2.16.3 for whats left of my licence. I shall be checking out blockchain VPNs as a replacement.

You will note that I wrote this earlier in reference to Linux: But, glad you found a workaround.

Yeah it's pretty much impossible these days. Even if you do somehow avoid all Google services, lots of other sites and apps are using Google Analytics (including server-side analytics, which you can't block client-side), and lots of companies use Google Cloud Platform for hosting.

I am also curious about the ultimate rule set. Also Linux can be nice and forgiving like linuxmint or ubuntu. Btw I "discovered" this nice website:https://sunknudsen.com/privacy-guides You can learn a lot and sometimes you can use it linux to ;-) GReetings,Casper

If Eddie detects a configuration error of IPv6, as in, it couldn't use native IPv6 to connect somewhere, it's completely blocked instead to rule out IPv6 address leaks. After all, it could be an intermittent error on Eddie's side while the system as a whole actually does have IPv6 connectivity. This option is ticked by default because, and it pains me to write this, most of the world's devices still don't use IPv6 whereas issues with IPv4 are practically nonexistent. You can say, the world is still running on IPv4.

The CLI is included in the Eddie-UI executable, so no.

Thank you for your answer. I understand how it works now. I tried to reach my mediaserver with the VPN turned off and it didnt work aswell so I figured out something was wrong with my local port forwarding. Got it to work now.

Well, if you are speaking of a laptop, then yes, mine disconnects (or Network Lock activates) until it wakes up. I was told way back when that this is normal. On my iMac, it will do the same thing if I allow the hard drive to sleep. If I don't allow it to sleep and only use my screen saver (on iMac) then it's fine and it d/l's in the background. Unfortunately, I only really use my MacBook Pro for emergencies, like if my iMac dies or has some kind of problem. If there is a simple workaround on a laptop, I don't know what it is. Anyone else??

Newest I could find off the cuff https://www.vpnuniversity.com/routers/use-selectivepolicy-routing-kill-switch-asuswrt-merlin

If you are able to find a used Netgear R7800 (X4S Nighthawk) at a reasonable price (new ones are pricey), that is pretty universally agreed in the dd-wrt forums these days to be the least troublesome router with solid speed for use with dd-wrt. Supposedly it runs OpenVPN at around 100 Mbps, and there are flashing instructions in the forum at https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614. The AirVPN setup how-to is at https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321856, though note it has not been updated yet for OpenVPN 2.5. Find general dd-wrt OpenVPN guidance, including notes on changes needed for OpenVPN 2.5, at https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327398. You'll need to register as a forum user and be logged in to download the pdfs. The forum that discusses the R7800 and related routers is at https://forum.dd-wrt.com/phpBB2/viewforum.php?f=28, and it's important to check the new-build thread there for any build you are considering flashing, just to make sure R7800 owners are not having trouble with it. There is a dd-wrt router database that is referenced in a million online how-to articles outside the dd-wrt forums. Ignore it. Its build recommendations are poor, sometimes disastrously so. Usually the latest build is the right one for that router. Re solutions other than dd-wrt, I do know that those Asus routers running AsusWRT offer OpenVPN, though they use Broadcom wifi hardware rather than the generally preferred Atheros wifi hardware. If you go that way, pick a model that is supported by (with many users) AsusWRT-Merlin (see https://www.asuswrt-merlin.net/), so that you will have the option of eventually upgrading your firmware to it. AsusWRT-Merlin is much less aggressive than dd-wrt with adding exotic features. It fixes bugs in the original AsusWRT and extends router capabilities in certain areas in a relatively gentle way. I believe I remember that OpenVPN Policy Based Routing (routing some but not all clients through the VPN) is one of its additional features. You'll either want PBR or two routers, one for VPN and one for bypassing it, in any practical router-VPN setup. I know little about other options so will let others comment. Good luck.

Glad to hear it's on the roadmap for 2021, just got a new Macbook Air M1. ☺️

This is exactly what any serious ISP should do. Trust is earned and lost thru actions. BTW: I still do not understand how I have not discovered AirVPN services before!

I can confirm it is coming. Even though wg matured a bit, it's still got technical and privacy caveats Staff will make very clear when the first experimental servers hit the scene. However, I cannot say when. Stay tuned for more info on the Announcements forum.

@arteryshelby We do not log and/or inspect our customers' traffic. Since 2010 you can't produce any single case, and not even the slightest clue, in which the identity of an AirVPN customer has been disclosed through traffic log and/or inspection and/or any other invasive method. It means a lot, given that various younger VPN services have been caught lying (ascertained court cases) and that AirVPN is now the oldest still active VPN service, with the exception of a minor service which anyway changed ownership twice in the last 12 years. By the way we have never asked our customers to blindly believe in our words. We do not block Tor and we even integrate its usage in our software, so you can be even safer if you can't afford to trust us OR some datacenter. For example you can use Tor over OpenVPN, to hide Tor usage to your country and ISP, and at the same time hide your traffic real origin, destination, protocol etc. to us and the datacenter the server is connected into. Last but not least, we invest a lo of money in Tor infrastructure and in 2017, 2018 and 2019 more than 2.5% of global world Tor network traffic transited on Tor exit-nodes paid by AirVPN. It is an important achievement we're proud of, and it hints to good faith. Kind regards

On my 350 line, I'm getting 200mbit/sec over encrypted vpn tunnel. Try the following... Preferences > Protocols ... set it to 'SSL 443' or 'Automatic' Preferences > Networking ... set both send/receive buffers to '256' or '512 KB' Preferences > OVPN directives ... insert 'mssfix 1442' as Custom command Save these settings and reconnect. Also, what is the CPU processor's spec on on your computer? Computer's CPU matters for speeds over encrypted tunnel.

If you decide to start over with a new router, look at a Netgear R7800 with dd-wrt and AirVPN. (The R7800 has by far the best dd-wrt support.) The relevant guides: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321856

https://restoreprivacy.com/wireguard/ AirVPN has also chimed in over WireGuard’s implications for anonymity, as explained in their forum: Wireguard, in its current state, not only is dangerous because it lacks basic features and is an experimental software, but it also weakens dangerously the anonymity layer. Our service aims to provide some anonymity layer, therefore we can’t take into consideration something that weakens it so deeply. We will gladly take Wireguard into consideration when it reaches a stable release AND offers at least the most basic options which OpenVPN has been able to offer since 15 years ago. The infrastructure can be adapted, our mission can’t. In their forums, AirVPN further explained why WireGuard simply does not meet their requirements: Wireguard lacks dynamic IP address management. The client needs to be assigned in advance a pre-defined VPN IP address uniquely linked to its key on each VPN server. The impact on the anonymity layer is catastrophic; Wireguard client does not verify the server identity (a feature so essential that it will be surely implemented when Wireguard will be no more an experimental sofware); the impact on security caused by this flaw is very high; TCP support is missing (third party or anyway additional code is required to use TCP as the tunneling protocol, as you suggest, and that’s a horrible regression when compared to OpenVPN); there is no support to connect Wireguard to a VPN server over some proxy with a variety of authentication methods. Despite these concerns, many VPN services are already rolling out full WireGuard support. Other VPNs are watching the project and are interested in implementing WireGuard after it has been thoroughly audited and improved. In the meantime, however, as AirVPN stated in their forum: “We will not use our customers as testers.”

hi there, although I am using openvpn with the config files from airvpn, I am recently leaking my IP. didn't do that before. has this something to do with newly incorporated ipv6 support? using: openvpn 0.6.73 android 7.0 firefox 57.0.4 with ublock origin; webRTC disabled airvpn linux config files EDIT: I mean IP leak not DNS leak (cannot change post title). DNS show two servers but seem to be airvpn's. however the ipv6 IP shows my country of origin.

Hello ! AirVPN is just legendary haha!

AirVPN does more than just purchase a server, route all traffic and count the money. They are actually interested in the privacy, which makes me to subscribe every year again.

They also reserve the right to kill anyone with a drone strike at the push of a button. No trial needed.

Hello! No. No. However, remotely forwarded ports are kept in the database, otherwise it would be impossible to reserve them to the appropriate accounts and dynamically forward them according to the server the customer's client connects to. Ports are deleted when the user un-forward them from the control panel. By default no port is remotely forwarded. The database is not on the web site servers. The current e-mail address is stored (on the db servers, not on the web site servers). This is essential to guarantee some services such as password reset, but a user is not forced to associate a real e-mail address to an account. Of course the best solution is picking an e-mail address that can't be exploited to disclose an identity. No. No. Remotely forwarded ports, if not deleted, can indeed compromise privacy under certain conditions. Even if deleted, they can expose the customer to correlation attacks, if a customer forwards them both on the VPN and on his/her system physical network interface(s) or router(s) etc (as clearly underlined in the FAQ). Before we can answer completely, we need that you elaborate your question. In particular, what crimes in which legal framework would you commit in this hypothetical scenario, which government and which force do you refer to? As clearly stated in the Terms of Service, a direct or indirect violation of any fundamental right (as enshrined in the ECHR) and some other acts (described in ToS art. 4) are a violation of our Terms of Service, REGARDLESS of the fact that the infringement is a crime or not according to the legal framework of the country which the customer infringes the ECHR from. On the other hand, a fact that is considered a crime according to some out of jurisdiction country legal framework has no relevance for us/is not our concern, since we (quite obviously) do not recognize the authority of any entity or the validity of any law that are out of jurisdiction. That matter will have to be faced by that country authorities without any cooperation from Air owners. Kind regards