Jump to content
Not connected, Your IP: 216.73.216.167

Staff

Staff
  • Content Count

    11554
  • Joined

    ...
  • Last visited

    ...
  • Days Won

    2046

Everything posted by Staff

  1. Hello! You need to run OpenVPN directly: you can use the executable we compiled for OS X directly from the original OpenVPN source code (tested on Mountain Lion), available here https://airvpn.org/topic/9325-development-of-os-x-airvpn-client/?do=findComment&comment=9555 Kind regards
  2. Hello, sporadic bad packets IDs in UDP mode can be totally normal. If they are very frequent, they are a symptom of either a poor line quality or a replay attack https://airvpn.org/topic/3773-pls-help-strange-logs/?do=findComment&comment=3784 Kind regards
  3. Hello! Please try UDP mode to ports 53 and 80. Furthermore, disable "NAT-PMP Port Mapping" in uTorrent. Kind regards
  4. Hello, can you please publish the Air client logs taken just after a connection has been allegedly established? Please right-click on the Air tray icon (a white cloud), select "Logs", click "Copy to clipboard" and paste into your message. Kind regards
  5. Hello, it is explicitly forbidden by the Terms of Service, article 4, point 6. Kind regards
  6. Hello! It should be openvpn_if="tun"but that does not really matter, it will be overridden by the configuration file. Maybe it's just a DNS issue, what is the content of resolv.conf? Also, please read here:https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf You can quickly determine whether it's a DNS issue by trying the following commands: ping -c 4 10.4.0.1 ping -c 4 google.com ping -c 4 8.8.8.8 so that you can immediately see whether the traffic is tunneled and/or names are resolved or not. If in doubt do not hesitate to post the output of the aforementioned commands. Finally, keep in mind that our service does not support IPv6. Of course. This is correct: the authentication is based on double certificate and secret key (embedded in the .ovpn file) not on login/password. Kind regards
  7. Hello, that's just fine. The 54... IP address you see is used by one of our failover servers. On this one, a frontend web server runs as well. That's why you can see our web site. Kind regards
  8. Hello, the section "News & Announcements" is dedicated to that. Kind regards
  9. Hello, as we said this feature will be implemented on the next client version. We're very near to a first alpha-release. Under a technical and security point of view it's a bad defect, not a good thing, that you must rely on a proprietary software from the same provider of the VPN service you use. You should always be able to choose to connect to a service with some software that does not come from the service provider itself. It's also not true that you need script files to prevent leaks, you can just use one (ONE) command that you can issue in 2 seconds or configure carefully firewall rules (which is a task that has some very important, good side effects on your network know-how). Kind regards
  10. Hello, the .NET framework version that's required by the Air client is specified in the instructions for Windows (menu "Enter"->"Windows" in our web site). To keep the minimal amount of software in the VM, do not install the framework and do not run the Air client, the OpenVPN GUI is just fine. Kind regards
  11. @refresh In order to discern whether the problem lies in pfSense or not, try a connection from one of your computer and check whether the same thing occurs. If so, might it be that your ISP "leases" your IP address for a definite time frame (and therefore DHCP-re-assigns it every x hours or at some fixed time of the day)? Just speculation but it's worth a check. If it happens, your OpenVPN connection needs necessarily to be re-established, because of course the OpenVPN server has no way to know "your" new IP address until the client re-contacts. To answer to the thread topic question: no, the Air servers keep the connection alive even when this connection is "inactive". Kind regards
  12. Hello, this is an English-only forum, we're sorry. Kind regards
  13. Hello, very probably our answers to FAQ can help you. Please read this https://airvpn.org/topic/9161-you-provide-remote-port-forwarding-what-is-it first, then read this https://airvpn.org/topic/9170-do-you-allow-p2p-how-can-i-optimize-performance-of-emule-and-bittorrent-with-airvpn Feel free also to use the Forum "Search" function, which is powerful and can be very helpful, after years there's a good knowledge base on this forum, thanks to the invaluable contribution of the community. In case of any issue, anyway, do not hesitate to open a ticket. Kind regards
  14. Hello, no, that's perfectly normal and does not compromise security in any way. One of our services runs and listens to port 88 of the VPN servers exit-IP addresses. Packets are not forwarded to th Virtual Private Network or to the VPN nodes. The fact that our system replies to ping is deliberate, and it must be so, otherwise we could not gather reliable data for the Ping Matrix that you can access through our Servers Monitor, see https://airvpn.org/status and https://airvpn.org/pingmatrix Actually what GRC web site states ("of YOUR system...") is technically wrong. It is in many cases true just for the coincidence that a long ago, when IPv4 addresses were still available, NAT and VPN were relatively uncommon. The GRC system sends packets not to your system, but to the exit-IP address of our VPN servers, i.e., so to say, "the IP address your node is visible on the Internet". This assumption is quite trivial and it is probably the reason for which it is not clarified by the GRC web site, but we understand that it can be confusing for a network-unexperienced user. By default, all accounts ports are closed. Each account can anyway remotely forward up to 20 ports, in which case the system will properly forward packets to the VPN, to the appropriate client VPN IP address. Kind regards
  15. Hello, according to your description it seems just a YouTube IP geo-location database error (inaccurate database, a common problem). Kind regards
  16. Hello, what happens if you set your browser language to English (it is currently set in German) and disable HTML5 geo-location (if it's enabled)? Kind regards
  17. Hello, it makes sense on a particular circumstance: if you wish to connect to a VPN server from the Windows machine, with the Air client and with the Windows machine unable (for example because it is "secured" against any leak) to resolve names via DNS queries. Kind regards
  18. Hello, after the thread was written a "Disconnect Now" button in the web site and a "Disconnect" API service were implemented. Please see here https://airvpn.org/topic/9612-what-is-api Kind regards
  19. Hello! What happens if you set as static DNS 2 a public DNS? What is the output of the command (from the router and while the router is connected to the VPN): dig @10.4.0.1 skydrive.live.com Kind regards
  20. Hello, yes, 10.0.0.0/8 IP addresses are private addresses. This solution: Static DNS 1: 10.4.0.1 Static DNS 2: 50.116.23.211 Static DNS 3: (optionally another OpenNIC DNS server) looks perfect. It will let your device use the VPN DNS when it's in the VPN and a public and trusted DNS when it's not. Kind regards
  21. Hello, we confirm that, it's an old problem with network-manager. It does not pass explicit-exit-notify directive to OpenVPN. Therefore when OpenVPN client in UDP mode ends, the server has absolutely no way to know that the client disconnected until the timeout. When you run OpenVPN in UDP mode via the network-manager, please allow 2 minutes for a server switch (i.e. wait for 2 minutes after you disconnect from the first server before trying to connect to the a different one). Alternatively please run OpenVPN directly to solve the issue completely. Kind regards
  22. Hello, 10.4.0.1 etc. are private IP addresses which can be reached only inside the VPN. In your case you can either set, in the router OpenVPN client configuration, the entry-IP address of the server you wish to connect to (so that it does not need any name resolution) or use a public DNS as a secondary DNS after 10.4.0.1. Keeping 10.4.0.1 as primary and a public DNS as secondary will allow you to use the secondary DNS when the router is not in the private network, and VPN DNS when the router is in the VPN. Kind regards
  23. Hello! Please see this guide: https://airvpn.org/windows_autostart (it is linked at the bottom of the Windows instructions page). However, you will need to enter your login and password anyway. If you need to connect your computer at the boot and before that any user logs in the system you need to run OpenVPN as a service. Kind regards
  24. Hello, skydrive.live.com is correctly resolved by our DNS and the web site is accessible from the VPN servers we have tested (NL and IT). Therefore the problem should be something else. Kind regards
  25. Hello! The DNS IP address in the VPN is 10.4.0.1 for every server. It is reachable regardless the port you connect to. It is a private address, you can't access it from outside the virtual network. Kind regards
×
×
  • Create New...