Staff

Hello, sorry for the mistake, "fragment" needs to be implemented on server side too, therefore it is not a viable option. Operate only with mssfix (start for example with "mssfix 1400" then lower the value progressively at steps of 50 if necessary). Kind regards

Hello, try to test again with routes check disabled: untick "Check if the tunnel effectively works" in client menu "AirVPN" -> "Preferences" -> "Advanced" and click "Save". Try a new connection and if it is established browse to airvpn.org. Verify whether the central bottom box is green or red. Do the above both with no custom directives and with the following directives: fragment 1400 mssfix to see whether there's any difference. Kind regards

Hello, please see if this helps and please continue there: https://airvpn.org/topic/14141-ubuntu-1504-potential-issue/ Locked. Kind regards

I have an update in this case. I've confronted my ISP with this problem and had a chat with a high positioned technican. He immediately knew what I was talking about and he assured that my ISP does not do things like that. He also assured that the don't block any ports, services ect. But he said I could try to "Increase the MTU to 1.000 in openvpn". The hell I don't know what he was talking about! Anyway I wanted to share it with you air-team and wanted to know what are you thinking about it? At least if you also think it is a good idea to increase the MTU, how can I do it???? Hello! MTU: https://en.wikipedia.org/wiki/Maximum_transmission_unit Our OpenVPN servers have a default setting of 1500 so the technician meant to decrease it, not increase it. You can't change MTU size on the client size only (this size must match on both parties), so that's not an option. You can however operate with "mssfix" (for TCP wrapped in the tunnel) and/or "fragment" (for UDP) directives to handle MTU size problems. You can add custom directives in "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN directives". For example: fragment 1400 Then click "Save" and restart a VPN connection. See below an extract from the OpenVPN manual. This thread can help: https://airvpn.org/topic/9773-receiving-packets-larger-than-1500-bytes/?do=findComment&comment=11446 Kind regards From OpenVPN manual: --fragment max Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes. The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ). --fragment adds 4 bytes of overhead per datagram. See the --mssfix option below for an important related option to --fragment. It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead. Having said that, there are circumstances where using OpenVPN's internal fragmentation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation. --mssfix max Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. The default value is 1450. The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. The --mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e. --proto udp. --mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them. Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers. The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage. If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option. Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options: --tun-mtu 1500 --fragment 1300 --mssfix

Hello! So it was never a DNS leak. Linux just sent DNS queries to the specified nameservers and it tunneled them. A DNS leak is when a DNS query is sent in clear text, outside the tunnel. Generally even with disrespect to your configuration. Unless you tweak Linux in a way to have specific nameservers for each interface and you define multiple routing tables, it is impossible to cause "DNS leaks", simply because there are global nameservers. Kind regards

Hello! There's no need to open a Coinbase account to pay to us via Coinbase and actually we see no compelling reason for a customer to keep an account or a wallet in their systems. Additionally you can add a strong anonymity layer to your Bitcoin client by running it behind Tor. The alleged problems that have been reported in the linked Reddit page pertain to those who keep accounts and even wallets on external systems. This does not appear to be a good way to use Bitcoin in absolute terms, not only with Coinbase. Kind regards

Hello! Just to understand whether the problem is related or not to UDP in your system and/or in your ISP settings, do you see any difference in performance if you establish a VPN connection in TCP (we're assuming that your current connection is on UDP)? Kind regards

Hello! As you can see incoming and outgoing IPv6 packets to/from any interface except lo are dropped. What IPv6 address is detected via ipleak torrent check? Kind regards

Hello, can you explain what you mean with DNS leaks? We ask because there can't be any DNS leak on Linux by definition. What Eddie version are you running? Kind regards

Thank you. When the client is running and Network Lock is enabled, can you please send us the output of the command: ip6tables -L --verboseissued from a root terminal? Kind regards

Hello, which Eddie version are you running? Kind regards

Hello! There is no problem: have you read the thread? Kind regards

Hello! Can you please try again and report back at your convenience? Kind regards

Hello! We're very glad to inform you that a new 1 Gbit/s servers located in Spain is available: Brachium. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). Brachium accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Brachium supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

Hello! We're very glad to inform you that a new 1 Gbit/s servers located in the United Kingdom is available: Dabih. The AirVPN client will show automatically the new server, while if you use the OpenVPN client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). Dabih accepts connections on ports 53, 80, 443, 2018 UDP and TCP. Just like every other Air server, Dabih supports OpenVPN over SSL and OpenVPN over SSH. As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses. Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Team

So can anyone explain why choosing Port 443 under SSL Tunnel worked and nothing else did? I'm in a tiny hotel in southern France, not some corporate behemoth! I'd really like to understand this better. Also is there a tool that might have hinted at this choice as the only one not being blocked? Protocol TCP Port 443 did not work. Port 443 under SSL Tunnel did. Hello! OpenVPN puts additional information in the headers for purposes of packets re-ordering. This represents a typical fingerprint which makes OpenVPN traffic recognizable with proper header analysis. When you tunnel OpenVPN over stunnel you encrypt OpenVPN packets headers and your traffic is pure SSL/TLS. Kind regards

Hello! Please upgrade to Eddie 2.9 Experimental. In Eddie 2.8.8 there is an issue with ip6tables: IPv6 outgoing traffic is not blocked. This has been fixed in Eddie 2.9 Experimental. Make sure to activate Network Lock and verify that the issue is fixed. Kind regards

Unlikely, they offered to re-provision our very same machine immediately. However, this is not the first time, but even if it was the first time, we can't go on with this provider. Kind regards

Hello! You can't, because the VPN DNS servers are accessible only inside the VPN. Kind regards

Hello! Can you please upgrade to version 2.8.8 or 2.9.2 Experimental? Kind regards

Hello, hey watch out, this is a kind of "false solution", because in this way you will not use VPN DNS. See https://airvpn.org/topic/14141-ubuntu-1504-potential-issue for an effective solution. Kind regards

Hello, Eddie must be able to connect to VPN servers even without DNS at all. There was a version with a bug which prevented connection when there was no DNS at all, which Eddie version are you running? Kind regards

Hello! Finally we got a response from Zaurak datacenter. They wiped out the server by mistake. We do not wish to comment at the moment. Kind regards

Hello! We installed a fresh Ubuntu 15.04, and installed Eddie 2.8.8 .deb edition. Unity -> AirVPN icon, on click it shows: Eddie automatically detects privileges and relaunches itself, with gksu. Automatically. As a discerning proof, we ran airvpn from terminal. We see logs in terminal that Eddie automatically restarts itself: Eddie main window never shows up if Eddie doesn't have the root privileges. Two separate issues in this topic: Ubuntu 15.04 DNS issue and your 'gksu/beesu' issue. Please continue here about the gksu/beesu issue, and in this topic: https://airvpn.org/topic/14141-ubuntu-1504-potential-issue for the Ubuntu 15.04 DNS issue. Kind regards

Ubuntu 15.04 possible issue We have a some tickets that notify us about an issue with Ubuntu 15.04. Symptoms: - Eddie with a loop on connection, caused by failed DNS checking - /etc/resolv.conf doesn't contain our DNS (10.4.0.1 or similar) after the VPN connection. It seems that resolvconf package doesn't push correctly the DNS. Workaround with Eddie - AirVPN client Use Preferences -> Advanced -> General or DNS tab -> DNS Switch Mode -> set Renaming method. ------------------------ Currently we can't reproduce the issue with our test environment. Our fresh installation of Ubuntu 15.04 works as expected. However, various users have this issue. Please help us: if you use Ubuntu 15.04, reply in this topic to the following questions: - Do you connect without problems (with Eddie and/or with OpenVPN / Network Manager / etc)? We need to understand how many Ubuntu 15.04 users have this issue. - If you have the issue, did you perform a fresh Ubuntu installation or did you upgrade from older version? Kind regards