Jump to content
Not connected, Your IP: 54.236.62.49

go558a83nk

Members2
  • Content Count

    1899
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    25

Reputation Activity

  1. Thanks
    go558a83nk got a reaction from bama in pfsense / SSL Tunnel specific guide?   ...
    you don't need to import any cert for stunnel to work.

    1) install stunnel package from package manager
    2) Create the stunnel tunnel here in services>stunnel.  /pkg.php?xml=stunnel.xml
    Select client mode use 127.0.0.1 as listening IP listen on port doesn't matter but you'll just use whatever you put here in the openvpn client setup certificate is default redirect IP is found in the .ssl file that you can download for stunnel in the config generator redirect port is also found in that ssl file (in the name of the file too) save the stunnel tunnel your status_logs.php should show stunnel activity to let you know it's running 3) Create or edit an openvpn config for AirVPN keeping everything the same as usual but changing the following protocol is TCP only interface is any server address is 127.0.0.1 server port is what you setup as listening port for the stunnel tunnel in the custom options box input route <server IP address> 255.255.255.255 net_gateway;   where <server IP address> is the same as in point 5 above Now in my experience it'll connect then disconnect, perhaps a few times before finally staying connected.  Just be patient.
  2. Like
    go558a83nk got a reaction from Duckie in Route Plex Remote Outside VPN   ...
    For plex remote access you either need to forward the port through the VPN or you need to setup, in eddie, plex.tv to go outside the VPN tunnel.
  3. Like
    go558a83nk reacted to Staff in Upgrade: Ain becomes a 10 Gbit/s server (SE)   ...
    Hello!

    We're very glad to inform you that a server located in Stockholm (SE) has been upgraded: Ain. Server is now connected to a 10 Gbit/s line and port, while the motherboard has been replaced with a more powerful CPU. IP addresses remain the same. You don't need to re-generate configuration files, even if you don't run our software.

    As usual the server includes load balancing between daemons to squeeze as much bandwidth as possible from the 10 Gbit/s line.

    The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP.

    Just like every other Air server, Ain 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/Ain

    Do not hesitate to contact us for any information or issue.

    Kind regards and datalove
    AirVPN Team
  4. Like
    go558a83nk reacted to Staff in New 10 Gbit/s server available (CH)   ...
    Hello!

    We're very glad to inform you that a new 10 Gbit/s server located in Zurich (CH) is available: Xuange. It's the first server we propose with a dedicated 10 Gbit/s line and port. As we have now circumvented several computing limits through load balancing and improved optimization, it's time to gradually test larger bandwidth.

    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, Xuange 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/Xuange

    Do not hesitate to contact us for any information or issue.

    Kind regards and datalove
    AirVPN Team
  5. Thanks
    go558a83nk reacted to Aristotle Skotos in My POV as a newbie here   ...
    As a long time GNU/Linux enthusiast & evangelist I am very privacy & net neutrality concerned, and care a lot about the software I run.
    Eddie is the very first VPN client I happily run on my Manjaro box.
    Though I still enjoy personally adding & managing VPN configurations thru the Network Connection Manager, I now see why a VPN client might be interesting: Eddie simply works out of the box and does not make a GNU/Linux user feel a 2nd class citizen (eg, network lock feature included by default), & provides detailed info on latency & load.

    What about transparency? Simply astonishing.
    In this world where money is the only religion, transparency is often an abused concept of the past. Not here. When geographic location is not mandatory, I love operating from the currently fastest server available and not overload the others..

    The number of locations seems to be low and the servers number a bit odd, but it works well. A well balanced infrastructure indeed with access points in strategic places all over the world. I love the servers names! As time passes, they become close friends.

    What about sponsorship? The fact that the company cares about some of the most important open source projects & organizations is definitely a plus.

    Not to mention that the community simply looks great.
    Thank you!
  6. Thanks
    go558a83nk reacted to GrandeGiovanni in Is M247 falsifying server locations?   ...
    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.
  7. Like
    go558a83nk reacted to Staff in CHACHA20-POLY1305 on all servers   ...
    Hello!



    We're very glad to announce all VPN servers progressive upgrade to Data Channel CHACHA20-POLY1305 cipher and TLS 1.3 support.
    UPDATE 18-Nov-2020: upgrade has been completed successfully on all AirVPN servers.

    The upgrade requires restarting OpenVPN daemons and some other service. Users connected to servers will be disconnected and servers during upgrade will remain unavailable for two minutes approximately. In order to prevent massive, simultaneous disconnections, we have scheduled a progressive upgrade in 15 days, starting from tomorrow 5 Nov 2020. Please see the exact schedule at the bottom of this post, in the attached PDF file. Servers marked as "OK" have been already upgraded and you can use CHACHA20-POLY1305 with them right now.
     
    When should I use CHACHA20-POLY1305 cipher on OpenVPN Data Channel?   In general, you should prefer CHACHA20 over AES on those systems which do not support AES-NI (AES New Instructions). CHACHA20 is computationally less onerous, but not less secure, than AES for CPUs that can't rely on AES New Instructions. If you have an AES-NI supporting CPU and system, on the contrary you should prefer AES for higher performance.
      How can I use CHACHA20-POLY1305 on AirVPN?
    CHACHA20-POLY1035 on Data Channel is supported by OpenVPN 2.5 or higher versions and OpenVPN3-AirVPN library.
    In Eddie Android edition, open "Settings" > "AirVPN" > "Encryption algorithm" and select CHACHA20-POLY1305. Eddie Android edition will then filter and connect to VPN servers supporting CHACHA20-POLY1305 and will use the cipher both on Control and Data channels.

    In our web site Configuration Generator, after you have ticked "Advanced Mode", you can pick OpenVPN version >=2.5, and also select "Prefer CHACHA20-POLY1305 cipher if available". If you're generating a configuration file for Hummingbird, select OpenVPN3-AirVPN: the configuration file needs to be different, because some new directives of OpenVPN 2.5 are not supported in OpenVPN3, and Hummingbird is based on OpenVPN3-AirVPN.

    In Eddie desktop edition, upgrade to 2.19.6 version first. Then select the above mentioned option. However, most desktop computers support AES-NI, so make sure to check first, because using CHACHA20-POLY1305 on such systems will cause performance harm when you go above 300 Mbit/s (if you stay below that performance, probably you will not notice any difference). Also note that if your system does not have OpenVPN 2.5 or higher version you will not be able to use CHACHA20-POLY1305.

    If you wish to manually edit your OpenVPN 2.5 profile to prefer CHACHA20 on Data Channel when available: delete directive cipher add the following directive: data-ciphers CHACHA20-POLY1305:AES-256-GCM

    Pending Upgrade Server Schedule


    Kind regards and datalove
    AirVPN Staff


     
  8. Like
    go558a83nk got a reaction from Lee47 in WINTUN replacement for Windows TAP driver   ...
    Interesting thing I came across.  Surprised to see no talk of this in the forum yet.

    https://lists.zx2c4.com/pipermail/wireguard/2019-September/004580.html
  9. Like
    go558a83nk reacted to Clodo in Wireguard response from Mullvad   ...
    It is not mandatory to wait for next Debian version: we are already testing up to date WireGuard version.
    When we'll make WireGuard available to customers, it will be on all servers.
     


    Exactly, it's unavoidable.
     


    With OpenVPN that's currently correct.

    However, with WireGuard we need to keep it, because it's written in .conf file generated via Config Generator and stored by users. See below for users' option to change or invalidate it.

     

    Some of our competitors do this. 
    Some accept only their official client software because of the issue. That's neither good nor acceptable for us, as we don't want to lock user into our software.
    Therefore the change you mention might be an Eddie's additional feature but we will try to make Wireguard main branch as secure as Eddie's, whenever possible.
     
     


    Yes, we still use ifconfig-pool-persist in OpenVPN.  It's very different than Wireguard's addresses binary mapping, especially under a legal point of view.

    When a client is connected, OpenVPN daemon necessarily needs to link clients' public and VPN IP addresses. As soon as the client disconnects the link is lost.
    One of WireGuard controversies is that client's real IP address remains visible with 'wg show' even after client's disconnection. The issue is resolved by removing and re-adding the peer after a disconnection (disconnection in WireGuard is basically a handshake timeout).

     


    Some current testing implementation features are:
    Unique WireGuard IPv4 and IPv6 subnets across servers which don't conflict with OpenVPN subnets Assigning a non-conflicting, pseudo-random, local IP address  for each customer's device (for AllowedIPs), similar to remotely forwarded port assignments Users can renew a local IP address for a device anytime. WireGuard .conf manually used in official client would become invalid. Eddie will automatically update. The same happens when a user regenerates OpenVPN client certificate and key pair: the action invalidates any previously stored OpenVPN profile.
    We will offer an API to automate the above, letting users write a script that performs HTTPS calls to change local IP address, download updated .conf, and then wg-quick. 

    An API to obtain a .conf file (Config Generator without UI) is already in production for OpenVPN and it will be of course available for WireGuard too.

    When a device's WireGuard local IP address changes, up to a 10 seconds wait is required. It's the time required to propagate device key onto all VPN servers, in order to update the AllowedIPs peer node.

    No other solution allowing us to let our customers use the official WireGuard client with a simple .conf file and, at the same time, preserve their privacy currently exists.

    Please keep the above information as a proposal: we are currently studying pros and cons and something may change before WireGuard public beta support in our VPN servers is available.
     
  10. Like
    go558a83nk reacted to SumRndmDude in pfSense/OpenVPN   ...
    Nothing is more frustrating or satisfying simultaneously than answering your own questions. Apologize for another thread clogging up the forums unnecessarily, but I had been at this for a while and saw no mention of the issue. Turns out that pfSense's OpenVPN wizard for creating a server puts the allow inbound traffic firewall rule on the main OpenVPN tab, rather than the actual newly created server's LAN. So it was hijacking all traffic on any interface or LAN using OpenVPN, including my AIr connections. As many times as I had plugged away at this issue, I only just now realized it did that. Moving it over to the actual server's LAN resolved it.

    FWIW, I appreciate the reply to at least say you had read my question.
  11. Thanks
    go558a83nk got a reaction from rkid in Router recommendations   ...
    Solid wifi performance does not equal solid openvpn performance.

    If you want good openvpn performance get the asus AC86 (eighty six) and install Merlin firmware.  It's got an AES-NI CPU so it'll rock openvpn.
  12. Confused
    go558a83nk reacted to Hoox in How To Set Up pfSense 2.3 for AirVPN   ...
    I did a new install in pfsense 2.4.5 following this guide. Everything looks good, but I cant seem to get ip from DHCP server on VLAN20 (VPN).
    This is from the log:
    Jul 4 14:22:09 dhcpd   DHCPOFFER on 10.0.20.100 to 94:de:80:f8:59:d4 (VPN-PC) via igb2.20 Jul 4 14:22:09 dhcpd   DHCPDISCOVER from 94:de:80:f8:59:d4 (VPN-PC) via igb2.20 So it seems like the DHCP server sees the client and offer an IP in the correct subnet, but there is no DHCPACK from the client afterwards. I tried with different machines also. 
    Other VLANs works fine. Clients gets IPs.
    Something I forgot for VLAN20? Some firewall rule?
  13. Like
    go558a83nk reacted to MrFricken in Guide - Configure pfSense VLAN with IPv6   ...
    I just added in IPv6 support on my pfSense box, using AirVPN and a VLAN. Note that I already had the VPN VLAN setup and working correctly with IPv4, so this guide is only about what needed to be changed to add in IPv6 support.
     
    Recently, AirVPN has implemented IPv6 across their servers. Provided you are running a recent version of OpenVPN (>= 2.4), and you adjust your client configuration properly, you will be assigned an IPv6 address along with the typical IPv4 address.
     
    In my setup, I’m using pfSense as my firewall / router, and have several VLANs configured for various purposes. One of these VLANs is specifically for VPN usage.
     
    So the question becomes, how to take the single IPv6 address assigned from AirVPN and make it usable on a VLAN, for multiple hosts. This setup is severely sub-optimal, as IPv6 was designed to avoid NAT (there are what, 3.4x10^38 available addresses?). Given that the design of the protocol and AirVPN’s implementation are at odds, there are some problems that you will encounter. The most annoying being that browsers don’t want to use your IPv6 address, and you will continue to use IPv4, despite having everything setup “correctly.” It may be possible to overcome this with some per-host modifications (on Linux, look to /etc/gai.conf), but that is perhaps not maintainable in the long run.
     
    This problem stems from the fact that the address Air is providing is a Unique Local Address (ULA), which, by definition, is not globally routable. This address gets translated at Air’s servers into a normal, globally routable, address. But what the software on your machine sees is a ULA, and since that isn’t a globally routable IP address, the software will prefer the IPv4 address, where it is understood that NAT will probably be used.
     
    Given this implementation, I am not convinced it is worth it to setup IPv6 in this type of configuration.

    Having said all that, here is how I configured things to get IPv6 “working” with AirVPN on a pfSense VLAN:
     
    1: Get an IPv6 address from AirVPN
    Assuming you are running a recent release of pfSense, you should have the necessary OpenVPN version for this to work (I’m on pfSense 2.4.4, which is using OpenVPN 2.4.6).
    Go into your OpenVPN client configuration and
    set “Protocol” to “UDP IPv4 and IPv6 on all interfaces (multihome)”
    scroll down to “Custom options” and make sure you have these 2 lines:
    push-peer-info;
    setenv UV_IPV6 yes;
    Save, and possibly restart the service. You should now have both IPv4 and IPv6 addresses assigned to your VPN connection
     
    2: Create a new Gateway
    I can’t remember if the gateway was automatically created at this point. If not, Add a new gateway. If one was auto created, edit it. Then
    Make sure Interface is set to the VPN
    Address family is IPv6
    Give it a name (VPN1_WAN_IPv6 in my case)
    I’ve left everything else at default settings, then set a description, and
    Save and reload
     
    3: Modify your VPN VLAN
    From the “Interfaces” menu, select your VPN VLAN entry, then
    Set “IPv6 Configuration Type” to “Static IPv6”
    Scroll down to the “Static IPv6 Configuration” section and set an address and prefix.
    I chose a “random” ULA (FDxx:xxxx:xxxx:10::1). Obviously, choose hex characters in place of the “x”s and the “10” matches my vlan number. Set the prefix to /64
    Leave the “use IPv4 connectivity” unchecked and the gateway set to “None”
    Save and reload
     
    4: Configure Router Advertisements and/or DHCPv6
    From the “Services” menu, select “DHCPv6 Server & RA” - then choose your VLAN. In my setup, I’m not bothering with DHCP, just using SLACC, so I go directly to the “Router Advertisements” tab.
    Set Router Mode to unmanaged
    Priority to Normal
    You may choose to put your IPv6 DNS server into the DNS configuration section (I believe Air’s server is fde6:7a:7d20:4::1
    Leave everything else as is (blank)
    Save and reload
     
    5: Set NAT Rules
    From the “Firewall” menu, select “NAT”, then go to the “Outbound” tab
    Click the second “Add” button
    Set “Interface” to your VPN gateway
    “Address Family” is “IPv6”
    Source type is “network”
    Source network is the ULA you setup earlier (“Fdxx:xxxx:xxxx:10::/64”) I did this using an alias.
    Note that the subnet drop down doesn’t list anything above a /32 (it’s meant for IPv4), so I left it at /32. Seems to work anyway.
    The Translation Address should be set to “Interface Address”
    Add in a description, if you wish, and
    Save and reload
     
    6: Set Firewall Rules
    From the “Firewall” menu, select “Rules” and then the appropriate VLAN tab
    Click the second “Add” button
    “Action” is “Pass”
    “Interface” is your VLAN
    “Address Family” is “IPv6”
    Set the rules appropriately for your situation. In my case, just to get things working, I set
    “Protocol” to “Any”
    “Source” to “[VLAN] net”
    Click the “Display Advanced” button
    Scroll down to “Gateway” and select your previously configured VPN IPv6 gateway
    Save and reload
    NOTE: Be sure to move the rule you just created into the correct spot in your rules list! Remember, the rules are checked in order, so if you have a deny rule above your new pass rule in the list, it won’t work.
     
    At this point I rebooted pfSense and my VPN client machine. I now have an IPv6 address, assigned from the ULA block I setup. Visiting https://ipleak.net shows I have both IPv4 and IPv6 connectivity. Going to https://test-ipv6.com gives me a 10/10, but with the note that the browser is avoiding using the IPv6 address. See the note from AirVPN Staff about this: https://airvpn.org/topic/25140-the-issue-your-browser-is-avoiding-ipv6/
     
    Hopefully this is helpful to someone out there.
     
    MrFricken
     
     
     
     
     
     
  14. Like
    go558a83nk reacted to Thrace in AsusWRT - OpenVPN Port Forwarding   ...
    Thanks for your time.
    I have added iptables rules and all good now

    I had entware at my stock asus router system for deluge torrent.
    I guess i can run a script at router boot with entware to add those iptables.

    Cheers

    Edit: I accomplished to add those iptables rules automatically after boot at stock AsusWRT.
    So now my router forwards my AirVPN opened ports to my PC.

    I had a 2 day trial to test it out.
    And few mins ago i purchased for 3 years

    Thanks again.
  15. Like
    go558a83nk reacted to NoiselessOwl in Wireguard response from Mullvad   ...
    This is, again, subjective. WireGuard don't have TCP protocol support, it only use UDP protocol to transmit (according to WireGuard's website). The problem with it is that UDP tend to be blocked often than TCP. K-12 and Higher Education Institutions usually have their network to block UDP and some ISPs put a block on UDP as well. It is worthless to use WireGuard if the network have UDP blocked. WireGuard will not be a new king on platforms if it doesn't support plethora of protocol. On the other hand, OpenVPN have ranges of protocol it can use to transmit which make it versatile to use. 
  16. Like
    go558a83nk reacted to Staff in AirVPN 10th birthday celebrations   ...
    Hello!

    Today we're starting AirVPN tenth birthday celebrations!
     
    From a two servers service located in a single country providing a handful of Mbit/s, the baby has grown up to a wide infrastructure in 22 countries in three continents, providing now 240,000+ Mbit/s to tens of thousands of people around the world.

    In 2019 and 2020, software development enhancement has paid off: now AirVPN develops on its own an OpenVPN3 forked library which resolves various problems from the main branch and adds new features. The library is used in Hummingbird, a free and open source software for Linux and Mac, known for its speed and compactness, in Eddie Android edition and in a new software which will be announced in June. Hummingbird has been released even for ARM based Linux devices, and runs fine for example in Raspberry PI.

    Eddie Desktop edition has been extensively rewritten to improve performance, reliability and security. Now anything not related to the user interface is written in C++ and a lot of security hardening has been implemented. Total compatibility with macOS Catalina, Windows 10 and latest Linux distributions has been achieved, and specific packages for various, widespread Linux distributions are available for easier installation.

    Eddie can act as a GUI for Hummingbird in Linux and Mac, while in Windows, Eddie can also be easily configured to run OpenVPN 2.5 with the wintun driver to achieve remarkable OpenVPN performance boost and put Windows on par with other systems OpenVPN throughput ability. Furthermore, the wintun driver resolves various problems which affected TAP-Windows driver.

    Development for OpenBSD and FreeBSD has been unfortunately re-planned but we're glad to announce here that it will continue, starting from summer 2020.

    All AirVPN applications and libraries are free and open source software released under GPLv3.

    We think that it's somehow surprising that AirVPN not only survived, but even flourished for 10 years, in an increasingly competitive market and increasingly privacy hostile environment.

    No whistles and bells, no marketing fluff, no fake locations, no advertising on mainstream media, a transparent privacy policy, no trackers on the web site or in mobile applications, no bullshit of any kind in our infrastructure to sell your personal data to any personal data merchant, and above all a clear mission that is the very reason which AirVPN operates for https://airvpn.org/mission , are probably, all together, the factors which allowed such a small "miracle" and maybe make AirVPN unique.

    Thank you all, you users, customers, members of the community, moderators, developers: the small "miracle" happened because of you, because you saw something in AirVPN.

    Kind regards and datalove
    AirVPN Staff
     
  17. Like
    go558a83nk got a reaction from Lee47 in pfsense 2.4.5 on qotom Q375G4 with AirVPN and Virgin Media   ...
    those are old settings.  AES-256-GCM is faster. and SHA512 is for tls-crypt configs.

     
  18. Like
    go558a83nk reacted to sudoopenvpn in Wireguard response from Mullvad   ...
    Quite perplexed by the use of the wg protocol, to be honest. I can say that I saw good speeds with a debian iso but that was something out of the ordinary. IVPN, a provider praised for their speeds, has been nothing but a bummer for me. Torrents are around 7MB/s and with another I am at 20 MB/s. On IVPN I used wg and on the other it was ovpn.

    But I cannot say that I don't understand the hype that wg goes through. But for me it is ovpn all the way. If you look at all the security issues and how providers are supposedly "fixing" them, I can only walk around with a huge question mark over my head. Why's wg needed anyway? What can it do that ovpn cannot do for us privacy minded folks? Why "fix" it when ovpn is still working as intended and always has? Surely, you wouldn't try to apply the use-case of an Volkswagen to an F1 car. With that said, I always liked AirVPN's approach to wg and that AirVPN kept prioritizing ovpn over wg.

    Anyway, everybody can do as he likes, I for one will stick to ovpn in the meantime.
     
  19. Thanks
    go558a83nk got a reaction from deguito18090 in IPLeak show only one DNS   ...
    not at all.  what that's showing, and it's normal when using openvpn GUI on windows, is that when you use openvpn GUI instead of Eddie you have a DNS leak which is ruining some of the privacy you gain by using a VPN.

    you want just the one (or two with ipv6) airvpn servers showing up as DNS servers.
  20. Thanks
    go558a83nk got a reaction from bluesjunior in WINTUN replacement for Windows TAP driver   ...
    yes, without the quotes
  21. Like
    go558a83nk reacted to Clodo in WINTUN replacement for Windows TAP driver   ...
    Hi to all, the latest Eddie 2.18.8 experimental released today, works with wintun, please test if interested.

    Go to https://openvpn.net/community-downloads/, at bottom "OpenVPN 2.5_git wintun technology preview", click the "here" link and install.
    If you already have the right "openvpn.exe", use it directly: Eddie will install the wintun driver when needed, and also create the adapter.

    Eddie -> Settings -> Advanced -> OpenVPN Custom Path -> choose your "openvpn.exe" from 2.5, if already installed probably it is "C:\Program Files\OpenVPN\bin\openvpn.exe".

    At this point, Eddie will use OpenVPN 2.5 (but still with standard TUN driver).

    Eddie -> Settings -> OVPN directives -> Custom directives, add "windows-driver wintun".

    At this point, Eddie will use the OpenVPN 2.5 with the newest Wintun driver.
  22. Like
    go558a83nk reacted to arteryshelby in SARS-CoV-2: precautionary measures taken by AirVPN   ...
    Please stay healthy everyone!
  23. Thanks
    go558a83nk reacted to Staff in SARS-CoV-2: precautionary measures taken by AirVPN   ...
    Hello!

    We would like to inform you that we have made every effort to ensure AirVPN full and efficient operation during the pandemic caused by SARS-CoV-2.
     
    In order to reduce hazard and safeguard health, AirVPN staff and personnel work exclusively from home and worked from home well before the current situation appeared clearly as a pandemic Each member has a landline and one or more mobile lines, when possible in different infrastructures, to maximize likelihood to stay connected to the Internet 24/7 AirVPN system is more efficiently automated and basic functioning requires no manual interventions, even for several months (if kernel upgrades hadn't been necessary, we would have had servers uptime of 4 years or more) AirVPN inner staff members have now overlapping competences. Therefore if a key member, including a founder, is forced to stop working, the other ones can carry out his/her functions Emergency funds already secured in the past in different facilities as well as banks remain unaltered and ensure AirVPN financial health for a very long time even in very harsh scenarios. However, we would like to assure you that they are not needed at all currently, quite the contrary. In the last 10 days we have experienced a substantial increase in the growth of our customer base We have been informed by our most important partners and providers of housing and hosting in Europe, America and Asia they they are, and expect to, remain fully operational
    Kind regards
    AirVPN Staff

     
  24. Like
    go558a83nk got a reaction from Lee47 in WINTUN replacement for Windows TAP driver   ...
    Interesting thing I came across.  Surprised to see no talk of this in the forum yet.

    https://lists.zx2c4.com/pipermail/wireguard/2019-September/004580.html
  25. Like
    go558a83nk got a reaction from Stan464 in Which is better for Pfsense setup?   ...
    Yes, even the i3 should be plenty.  Just be sure to enable cryptographic hardware here /system_advanced_misc.php and then select that hardware in your openvpn config you create.  Then AES-NI plus whatever else is on the CPU is in use.
×
×
  • Create New...