Staff

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

@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

Hello, this is an English-only forum, we're sorry. Kind regards

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

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

Hello, according to your description it seems just a YouTube IP geo-location database error (inaccurate database, a common problem). Kind regards

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

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

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

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

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

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

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

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

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

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

Hello, while the router is connected to the VPN, can you ping 10.4.0.1 from a computer connected to the router? And from the router itself? Kind regards

Hello, just for readers' information and in order to close this topic, together with hogboy cooperation a support staff member detected the problem and solved it some hours ago. It was not a bug: the system was behaving correctly. As a general recommendation to anyone (not specifically to hogboy) we remind you that you should not use the same password on different services and that you must not give to anyone your user.key. An adversary in possession of your user.key and the certificates can NOT decrypt your traffic flow (not even if he/she wiretaps your Internet line), BUT can connect to a VPN server with your account. Also, please use passwords at least 12 characters long, randomly generated and not containing dictionary words in any language. Include in the password a random series of characters included in the ranges [a-z], [A-Z], [0-9]. Include at least 2 characters for each of those ranges. As a final recommendation, do not use the same username you picked for other services in our web site. Kind regards

Hello! It might be a DNS issue. Please check whether you can ping IP addresses but names can't be resolved. If so, make sure that your nameservers list in /etc/resolv.conf (or equivalent in Raspberry) includes 10.4.0.1 (i.e. a line "nameserver 10.4.0.1" in resolv.conf file) so that you enable Raspberry to query the VPN DNS. Please see also here https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf If it's not a DNS issue, please feel free to publish your OpenVPN logs. Kind regards

Hello, we don't know if this helps: sometimes that error occurs if you connect from behind TOR or a proxy or anyway when PayPal sees you from an IP address that triggers risk management and security systems. Kind regards

Hello, we had a momentary, very short issue, it should have been fixed just a few minutes after you wrote your message, can you confirm? Kind regards

Hello, yes, that's a valid and good method to prevent leaks. You can compare with Nadre's posts and guides, here https://airvpn.org/topic/9787-the-pros-and-the-cons/?do=findComment&comment=11501 (please check out the "UPDATE 2" with care at the bottom of the post) and on the "How-To" section of the forum. Kind regards

Hello, packets to exit-IP:88 are not forwarded to the VPN. That port is used for services on the exit-IP address, outside the VPN. Kind regards

Hello, in "Forums"->"How-To" section you can find guides for ipfw and pf, the default pre-installed packet filtering tools according to your OS X version. Kind regards

Hello! You've probably missed the part in the instructions for Linux where it is explained how to achieve your purpose. In the Configuration Generator please tick "Advanced Mode" then tick "Separate certs/keys from .ovpn files". By default the Configuration Generator embeds .ovpn files with certificates and key. Kind regards