Jump to content
Not connected, Your IP: 3.143.168.172

Staff

Staff
  • Content Count

    10633
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    1774

Posts posted by Staff


  1. "3) I have seen the long threads about how to disallow any internet traffic if AirVPN goes down using Comodo, but it seems a little daunting since there are lots of steps involved which is really difficult for non-experts. Could AirVPN not just create a script that one can run with the click of a button, so that internet traffic is ONLY allowed if AirVPN is up? That would help users like me a lot."

    I have to agree...setting 14 firewall rules is daunting, especially when getting one wrong defeats the whole purpose. I think we Windows users need a new Air client to do this for us.

    Hello!

    We are not willing to offer "false solutions" which give a dangerous, false sense of security, like other services do. If we find a solution as reliable as a firewall rule, we will of course be very glad to implement it.

    Setting the rules for Comodo should take no more than 3-4 minutes, except for persons who don't know what a firewall is. In that case, reading the Comodo quick guides is useful and it is very well spent time. We repute that nobody should ignore what a firewall is nowadays. Techno-ignorance is the most powerful weapon in the hands of the censors.

    Please consider that if you just need to block a torrent client, only ONE rule is necessary (application rule for the torrent client as explained).

    Kind regards


  2. Thank you for the reply. Could you still answer to my posted questions in detail, if possible?

    1) Is it normal that PeerBlock shows the same (IP-sniffing) connection attempts with or without AirVPN running? (note: in PeerBlock I use a blocklist, not an allow-list, so any suspicious connectors are simply blocked. What surprised me that these blocked connections did not get affected by running AirVPN at all). I guess the answer is that, yes, it is normal (since AirVPN only obscures one's own IP, while not obscuring the IPs of others trying to connect to you), but I just would like to be sure that this is normal.

    Hello!

    Yes, it's totally normal.

    2) I have not opened any ports on the AirVPN website for port forwarding (and neither in my router), but I still get the green icon in mutorrent. Is this normal? Is everything all right? What advantage would I get from port forwarding since I already have the green icon (by which mutorrent indicates that one's network "works as it should")?

    No, this is important, please make sure that you don't have forwarded on your router the port your torrent client listens to.

    3) I have seen the long threads about how to disallow any internet traffic if AirVPN goes down using Comodo, but it seems a little daunting since there are lots of steps involved which is really difficult for non-experts. Could AirVPN not just create a script that one can run with the click of a button, so that internet traffic is ONLY allowed if AirVPN is up? That would help users like me a lot.

    Please see here for a clarifying explanation https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 (if you have Windows; you can find rules for other systems in the top part of the forum, in the "Announcements" section).

    4) As for reliability, if I surf/connect a lot, for me AirVPN goes down about once in 2 hours, and then takes about 5min to reconnect (sometimes it does not reconnect at all, and I have to disable their virtual adapter and re-enable it to get it back to work). During this time, my PC is connected to the internet with my real IP. This is a real security risk and should be addressed by a feature that ensures that internet can only be connected when AirVPN is up and running. Otherwise one cannot leave the computer and walk away, because data would leak out unprotected while AirVPN is down and trying to reconnect. No idea why this issue is not top priority, since this defeats the whole purpose of the VPN (as you can never know when AirVPN will suddenly disconnect and try to reconnect).

    Thanks for any answers to my questions...

    You should set firewall rules to prevent leaks in case of unexpected VPN disconnection. This is the safest solution. We don't recommend different solutions, due to security reasons.

    Kind regards


  3. OK, I am a complete newbie. I just signed up to your service. Please tell me in detail how to configure this VPN on a mac. So far I am not able to connect your system.

    Hello!

    Please follow the instructions for Mac OSX, you will be ready in 5 easy steps. Instructions are available in menu "Enter"->"Mac OSX", direct link:

    https://airvpn.org/macosx/

    Kind regards


  4. Would whitelisting those IP addresses be a privacy risk? When you say not tunneled, do you mean that the traffic will be sent not through AirVPN/OpenVPN and thus be unencrypted?

    Hello!

    That's exactly what our customer asked for.

    How do you add IP addresses to the routing table?

    Please elaborate, it's written in the message above.

    If you mean how an OpenVPN server pushes routes, then the answer is "with the push directive". A client may refuse pushes with the nopull directive, in which case a tunnel is established but nothing will be tunneled until a proper routing table is defined.

    Kind regards


  5. I've just recently started using Air VPN and everything is working great except for Netflix. When I go to Netflix it pops a bubble telling me that I'm "Travelling with Netflix" and will therefore lose some key services. I no longer have my instant que and a few other things are missing. I've looked through my Netflix settings but I couldn't find anything that seemed like it would help. Google didn't help either.

    I set up my vpn using the dd-wrt method. Is there some way to bypass the open vpn settings for certain sites?

    Hello!

    Yes, it's possible. By default our servers push routes so that all traffic is tunneled. You need to change the routing table in order to route the traffic for Netflix through your normal gateway instead of the VPN one.

    You need also to know the Netflix IP ranges.

    According to comment by "Jon" here: http://kaeding.name/articles/2010/11/15/prioritizing-netflix-traffic-with-dd-wrt/

    the IP addresses used by Netflix to serve content are many:

    208.75.76.0/22

    128.242.0.0/16

    63.97.94.0/24

    65.200.11.0/24

    96.16.0.0/15

    216.246.75.0/24

    204.0.0.0/14

    204.200.0.0/14

    184.84.0.0/14

    62.0.0.0/8

    58.0.0.0/8

    198.76.0.0/14

    4.27.0.0/16

    8.0.0.0/8

    206.32.0.0/14

    209.84.28.0/23

    209.84.24.0/22

    209.84.16.0/21

    192.221.0.0/16

    205.128.0.0/14

    4.0.0.0/8

    204.160.0.0/14

    199.92.0.0/14

    184.72.0.0/15

    208.111.128.0/18

    Now, you need to modify your routing table so that the above IP ranges do not get tunneled:

    route add -net 208.75.76.0/22 gw <your "non-VPN" gateway>
    ...
    route add -net 208.111.128.0/18 gw <your "non-VPN" gateway>

    In this way you'll obtain that all the traffic for Netflix (assuming that the above IP ranges list is correct and exhaustive) will not be tunneled.

    Kind regards


  6. EDIT: the problem is solved (provider IP db error). Please note that from now on Tauri will have a new exit-IP address.

    Hello!

    Due to problems in Tauri datacenter we have been compelled to put momentarily down Tauri.

    Although the problems are reported as resolved (see http://www.leasewebnoc.com/en/networkstatus/leaseweb-germany-network-issues) we still have major connectivity problems with Tauri.

    We'll be investigating with the help of Leaseweb technicians and we will keep you updated.

    Kind regards


  7. Oh no, I'm sure there is no problem with the push and I wasn't referring to Sirius or any specific port either, though I always use UDP443

    . It's just something I noticed lately on basically all servers I use, mostly NL/UK. The connection is fine, but sometimes the websites don't load anymore. Disconnecting solves it instantly and after reconnecting its fixed too. But pls don't worry about it, I'm happy using a public DNS, was just wondering if I have to manually change it in the tap-adapter settings.

    thank you

    Hello!

    Sure, of course you can force any DNS you like on your TAP-Win32 adapter, your query will be sent encrypted in the tunnel to our servers, forwarded to your favorite DNS server and the answer sent back encrypted to your client. No problems in resolution, no privacy problems (your ISP will NOT see the queries), however please note that in this way you will no more use our anti-ICE seizure system. Try "rojadirecta.com" for testing purposes to understand what we mean.

    Kind regards


  8. Yeah! Something is wrong with the DNS servers...pages not loading for me sometimes. Can I just use any DNS server by putting it in the TAP-Win32 Adapter V9 settings under DNS-server?

    Thank you.

    Hello!

    We don't detect any problem with DNS. Can you please check the DNS push from Sirius on port UDP 443 and send us the output of "ipconfig /all" for the TAP-Win32 adapter? If the DNS push is successful, you should see the address 10.4.0.1 as DNS server of the adapter. If not, please check that the adapter accepts the push.

    Kind regards


  9. Hello,

    I usually used port 53 but recently when I checked the 'direct_access' page I saw that AirVPN recommends port 443, so I decided to check that.

    I haven't check all the servers, but with AirVPN US Sirius UDP 443 establishes connection but web pages are not loading and ping doesn’t work, while AirVPN SE Serpentis UDP 443 and AirVPN US Sirius UDP 53 work just fine.

    Hello!

    We don't detect any problem with Sirius port 443 UDP. We have been testing the server and the port since the time of your writing. Previously and currently more than 60 OpenVPN clients have been finely exchanging data on it. Can you please check your routing table after the connection?

    Kind regards


  10. @rbuilder

    Hello! Jinsong is right, probably your ISP shapes some or all UDP ports so you get better performance with TCP. This is becoming a common practice because these ISPs see UDP packet shaping a way to:

    - increase overselling without investing in infrastructures

    - hide anti-competitive practices to make their own content and service delivery to their customers more attractive than those of their competitors (VoIP, A/V streaming etc.)

    - test their customer base for acceptance of walled-gardens, a business model aimed to dismantle the open Internet. Apple huge success, which shows that majority of people will support enthusiastically a company that actively fights to dismantle the open Internet and open source software, this model is now very attractive.

    Kind regards


  11. 443 TCP and 80 TCP had a limit of about 215-220kb/s whilst 53 UDP had a 225kb/s limit,

    Hello!

    Given your peak bandwidth without VPN (300 kB/s), the performance you obtain is normal (assuming you mean kB/s, not kbit/s). Either your ISP always caps all ports or, more probably, it does not cap at all but is incapable to give you more than 300 kB/s down.

    Kind regards


  12. did you ever figure out what casued it. my utorrent says "no incoming connections" next to the port number.

    i too have tried mutliple ports (from airvpns website) with no luck.

    Hello!

    After you have followed the instructions reported in the FAQ https://airvpn.org/faq to optimize p2p performance, please make sure that:

    - the listening port of your torrent client matches [one of] the port you have remotely forwarded from your control panel

    - the remotely forwarded port(s) are set to TCP & UDP and are not remapped to any local port

    - no firewall is blocking your torrent client on any network (this is important especially for Windows firewall: authorized applications in some networks may be not authorized to receive packets on other networks)

    Then "launch" a torrent and check whether you obtain a green token.

    If you have further issues, please send us information about the system you use, the configuration of your torrent client and the Air servers you connect to.

    Kind regards


  13. Would AirVPN work where tor and VPN proxies are banned using DPI ?

    "On June 26th, 2012 Anonymous said:

    oh.. lucky those who can make a connections on other

    country, bad luck here on thousands filipino's here in the philippines

    who's relying on tor...

    recently 2 of the biggest ISP's blocked Tor

    If I;m not mistaken through port 443.. .

    even vpn are all blocked.. .

    status now here is in back to zero.. .

    we' in our community join together in the fights against censorship..

    net cost here are so expensive &

    I guess in your country the speed that gives to us by the ISP's is just a free..

    but in a long run .. failure!"

    https://blog.torproject.org/blog/update-censorship-ethiopia#comments

    Hello!

    OpenVPN handshake has a typical fingerprint, easily identifiable with DPI (it does not look like real SSL). We are preparing a system to mitigate this problem, stay tuned in the next weeks.

    Currently you have some systems (with Air) to evade a lot of controls: connecting to port 53 UDP (all Air OpenVPN servers accept connection on 53 UDP), or (in countries/ISPs which do not block TOR) connecting Air over TOR.

    Another system is connecting Air over any public socks or http proxy which is not blocked, this system is currently quite effective.

    Kind regards


  14. I thought the whole risk of DNS leaks was for services to be able to query your ISP's DNS server and thus compromise your anonymity.

    Hello!

    Yes, such a query would be sent from your physical network card unencrypted and your ISP would know which resolutions you want to perform. A DNS leak, in our case, is an unencrypted DNS query which does not respect the routing table pushed by an OpenVPN server. Basically it happens on Windows system because every card can have its own, different DNS and svchost.exe runs with highest privileges, taking the unjustified freedom to send out DNS queries from any interface if the previous query from the correct interface does not receive an answer within a short time limit.

    If the Comodo rules do not block encrypted DNS queries, isn't there still the risk that those encrypted DNS queries will reveal the true ISP of the computer using the VPN and thus compromise the anonymity of that computer?

    Not at all. First, the encrypted DNS queries go out from your tun network card, which has a push to use the Air DNS. Second, even if you, in a momentary lapse of reason, forced the tun adapter to have your ISP DNS (we are talking only about Windows here, which is the only system which, for some reason, allows different DNS for different cards, which is the main source of all DNS leaks), and even if those queries could go out of the Air servers, and even if the ISP had completely open DNS (which is normally not the case), the ISP DNS would see the queries coming from our servers and would respond to our servers.

    Kind regards


  15. sorry for asking but how should i do that? - is there a specific way within windows or should i do that from openvpn?

    Hello!

    If you use the Air client, after you have picked a server please select the "Modes" tab, pick a port and click "Enter". Please see the instructions for additional details.

    If you use OpenVPN directly or the OpenVPN GUI, please generate the appropriate configuration file with our configuration generator (menu "Member Area"->"Access without our client") and follow the instructions for OpenVPN for Windows.

    https://airvpn.org/windows

    Kind regards


  16. So i was using the vpn but i noticed a performance drop vs having no VPN (i kinda expected that) but it seems to be locked at 225kb/s whilst normally its around 300kb/s and i was wondering if there is anyway to improve that at all?

    Hello!

    A "lock" on bandwidth is a strong hint suggesting traffic shaping. If you notice a constant maximum bandwidth, chances are that the outbound port you're connected to is shaped by your ISP. Please try connections on different ports: 443 TCP, 80 TCP, 53 UDP to check.

    Kind regards


  17. Would there be any possibility of an application besides svchost.exe trying to query the DNS server? If there is, would the global Comodo rule be enough to prevent that query from going through?

    Hello!

    The Comodo global rules (not the application rules, of course) we recommend in order to prevent leaks do not block DNS queries from svchost.exe or from any other application. They prevent any packet to go outside your internal network, including therefore DNS queries, if and only if there is no connection to one of the Air servers. Nothing in the rules prevents to send out encrypted DNS queries in the tunnel by any application when the device is connected to an Air server.

    Please do not hesitate to contact us for any further information.

    Kind regards


  18. Don't know if this is the OP's problem, but am connected to Castor and am seeing latencies in the range of 2000-2800ms on all the EU servers .... except Sweden and the US servers which are 1-2ms ... did a trace to 8.8.8.8 and hop latency is 800-1200ms ... also seems intermittent with occasional drops in the EU servers back to normal latencies ... any insight ... and yes the latencies make it slow for me and short of connecting to US (NO) changing servers will not help ...

    cheers

    Hello!

    From inside Castor:

    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

    64 bytes from 8.8.8.8: icmp_req=1 ttl=51 time=16.5 ms

    64 bytes from 8.8.8.8: icmp_req=2 ttl=51 time=16.7 ms

    64 bytes from 8.8.8.8: icmp_req=3 ttl=51 time=16.8 ms

    64 bytes from 8.8.8.8: icmp_req=4 ttl=51 time=16.8 ms

    64 bytes from 8.8.8.8: icmp_req=5 ttl=51 time=16.8 ms

    64 bytes from 8.8.8.8: icmp_req=6 ttl=51 time=17.0 ms

    64 bytes from 8.8.8.8: icmp_req=7 ttl=51 time=16.8 ms

    64 bytes from 8.8.8.8: icmp_req=8 ttl=51 time=17.6 ms

    64 bytes from 8.8.8.8: icmp_req=9 ttl=51 time=17.0 ms

    64 bytes from 8.8.8.8: icmp_req=10 ttl=51 time=17.0 ms

    64 bytes from 8.8.8.8: icmp_req=11 ttl=51 time=17.9 ms

    64 bytes from 8.8.8.8: icmp_req=12 ttl=51 time=16.7 ms

    64 bytes from 8.8.8.8: icmp_req=13 ttl=51 time=16.7 ms

    64 bytes from 8.8.8.8: icmp_req=14 ttl=51 time=16.8 ms

    which might hint at a problem somewhere between you and Castor, not between Castor and 8.8.8.8.

    Kind regards

×
×
  • Create New...