Staff

Hello! Apparently something is blocking outgoing OpenVPN packets. Please make sure that the new openvpn.exe you are running is not blocked by your firewall or any other program. Kind regards

Hello! Just run OpenVPN directly (no GUI, no wrapper) https://airvpn.org/linux If you access the server from a ssh, you might like to launch OpenVPN from a "screen" session. Kind regards

Hello! OpenVPN, offering (besides other features) exactly what you define a coding on layers 4-7, does protect you against DPI. DPI can only understand that you're using OpenVPN, nothing else. In order to prevent even that, we'll be launching OpenVPN over SSL and over SSH in the next weeks, so that DPI will identify your traffic as "SSL" or "SSH", not OpenVPN. Kind regards

Hello! The output shows that your connection is successful and your system correctly exchanges packets with our VPN servers. Also, your system is able to resolve names. Kind regards

Hello! No problems at all are showed by all the data you sent us. Try to set 10.4.0.1 as primary (preferred) DNS IP address in your physical network card. Leave the secondary (alternate) DNS IP to your favorite DNS in order to allow names resolution when disconnected from the VPN. Kind regards

Hello! Which Tunnelblick version and which OS X version are you running? Kind regards

Hello! Can you please send us, just after your system has connected to the VPN, your client connection logs and the output of the commands (issued from a command prompt): ping 10.4.0.1 tracert google.com tracert 8.8.8.8 Kind regards

Hello! Please send us your client logs (just after a connection to the VPN) at your convenience. What do you mean with "Google the IP address"? Kind regards

Hello! The explanation is basically correct if you can't dig into technical details. About her confusion, you should make clear that the OpenVPN connection ports have absolutely nothing to do with ports inside the virtual private network. Let her consider them as belonging to two completely different sets of ports in different networks. Going just slightly into more technicalities, OpenVPN encrypts and encapsulates all the traffic (so you can have all combinations such as UDP over TCP, TCP over UDP, UDP over UDP, TCP over TCP...). The real incoming/outgoing packet headers and payloads are still/already encrypted when they pass through her physical network interface. Her ISP will see only traffic to/from one IP and one port (again, a port which has nothing to do with the ports inside the virtual network), because the real underlying outgoing packet headers and payloads are encrypted by her client and decrypted by our servers, while incoming packets headers and payloads are encrypted by our servers and decrypted by her OpenVPN client AFTER they have passed through her computer physical interface. NAT is performed transparently by OpenVPN server and client through the tun adapter (a network interface used by OpenVPN). This gives the huge advantage to allow to use any higher-layer protocol over OpenVPN without having to configure programs. Kind regards

Hello! Yes. Yes: already established connections will not be tunneled. Make sure to launch the applications you want to be tunneled AFTER you have connected to the VPN. It is safer, yes, against potential attacks which try to correlate different activities of yours on the Internet and potentially creating a link between your real IP address and the VPN IP address. It can happen, it is not uncommon that ISPs have short-time black-outs and dynamic IP re-assignments. We have guides to prevent any leak in case of unexpected VPN disconnection. Kind regards

Hello! Usually that error is triggered by PayPal security systems which check your IP address, are you trying to perform the payment while connected to PayPal from a proxy, TOR, I2P or a VPN? Kind regards

Hello! There's no difference. To no program in particular, they are General Rules that will be evaluated for every and each packet. Our OpenVPN servers push default gateway and routes so that all the traffic in the device where the OpenVPN client runs will be tunneled. The rules are global, therefore they are evaluated for every and each packet. Kind regards

Hello! Maybe some program is blocking incoming packets for Vuze. Can you test with your firewall disabled? Check also any other program which might interfere (antivirus, PeerGuardian, PeerBlock...). Kind regards

Hello! Please bind Vuze only to eth9 (TAP-Windows Adapter V9), this will also prevent leaks in case of unexpected VPN disconnection. Kind regards

Hello! The port is correctly forwarded, both TCP and UDP, so the packets are forwarded to your system. Can you please check: - that the configured port in Vuze matches the remotely forwarded port - that Vuze has a bind to the correct interface (the tun adapter) Kind regards

Hello! Ok, now a port is forwarded, can you please test again? Kind regards

Hello! At the moment of this writing there are no forwarded ports for account "stkkts". Can you please forward a port, configure it in Vuze, and try again? Kind regards

Hello! Apparently everything is ok. Your home network Ip range does not seem to overlap with the VPN one (can you please confirm that it is 10.102.0.0/255.255.0.0 ?). Can you please send us also the output of the following commands (while connected to the VPN): tracert 10.4.0.1 tracert airvpn.org tracert google.com Kind regards

Hello! The logs are fine. After the connection is established, from a command prompt can you please issue the commands: ipconfig /all route print and send us the output? Kind regards

Hello! Yes, 10.4.0.1 is the correct DNS IP address pushed by our servers when you connect to port 443 UDP. See also https://airvpn.org/specs Setting a different DNS on your tun interface is ok (the DNS queries will be encrypted and tunneled), but you will not use Air DNS, so you will not access internal services (currently only http://speedtest.air ), you will not bypass ICE censorship and you will not be able to use our experimental service aimed to prevent geo-IP based discriminations (for example with our DNS you can use BBC iPlayer even from non-UK servers; or access CBS from non-US servers). Kind regards

Hello! The DNS push from the server is correct. Try to set 10.4.0.1 as primary (preferred) DNS of your physical network adapter, this has proved to fix the issue on several Windows systems. Kind regards

Hello! If you get packet fragmentation yes, you should correct the issue on the client side. If not, you don't need any modification. Please send us again your client connection logs (after some minutes the connection is established) if you still experience packet fragmentation, so that we can suggest you how to optimize the connection. Kind regards

Hello! Yes, it is! Kind regards

Hello! It's written in the page ("Only about online users"). Tables are compiled with current active session data. Logs are not necessary to compile them, obviously (and the OpenVPN logs are directed to /dev/null). While an account is connected, the OpenVPN servers know all those details, including the IP address the connection come from (which is published ONLY on the account details page). That's just how the Internet works, otherwise you could not even connect to a VPN server, perform a TLS re-keying every 60 minutes, notify the server about account connection and disconnection etc. etc. Every and each detail is lost forever at the moment of the account disconnection. The published tables provide very precious information to all users in order to evaluate servers performance and stability, verify our commitment to no overselling and provision of minimum allocated bandwidth, without weakening in any way the anonymity layer. Kind regards

Hello! No logs at all are necessary for those tables. No, not at all, how did you come out with this strange idea? No, not at all. Kind regards