Staff

Hello! The connection looks fully successful, our VPN DNS IP is reachable, and yet your system does not appear to send proper queries to our DNS. We met this problem in the last few days with some Windows 7 systems. Try to force the following DNS on your physical network card: 10.4.0.1 (our internal DNS) 87.118.104.203 (German Swiss Privacy Foundation primary DNS) In order to do so, open Start->Control Panel->Network and Internet->Network and Sharing Center->Change Adapter Settings. Right-click on your physical network card (cable of WiFi, named usually "Local Area Connection" and "Wireless Network Connection") and select "Properties". Highlight Internet Protocol Version 4 (TCP/IPv4) and click on Properties. In the subsequent window enter 10.4.0.1 as Preferred DNS and 87.118.104.203 as Alternate DNS. In case of issues in the above steps please see http://www.sevenforums.com/tutorials/15037-dns-addressing-how-change-windows-7-a.html Please feel free to let us know at your convenience if all of the above solves your problem. Kind regards

Hello! Can you please determine whether it's a DNS problem? Try from a command prompt (while you are connected): ping airvpn.org ping 212.117.180.25 ping 10.4.0.1 and send us the output. Kind regards

Hello! In this case the firewall will not block anything because of the following lines: which must be replaced in any case with the proper AirVPN IP ranges. Please see https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=2935&Itemid=142#4481 Kind regards

Hello! You can't know in advance the TOR entry node which your system will connect to, so this set of rules is inadequate. Kind regards

Hello! Can you please send us the output of the command "ipconfig /all" before the connection, and while the connection is still up? Kind regards

Hello! Thank you for your inquiry, can you please check your inbox again? Is the e-mail address associated with "xdroid" good? Kind regards

Hello and thank you! If you a see a lot of these: in your logs and the bandwidth goes down a lot, then you can try a connection to a TCP port. Please do not hesitate to contact us for any further information. Kind regards

@anetis Hello! The logs do not show problems. Can you please try different servers and TCP ports and let us know the outcome? Also, while you're connected to Vega port 443 UDP (as in your reported log), please open a command prompt and issue the following commands: ping airvpn.org ping 212.117.180.25 ping 10.4.0.1 ipconfig /all and please paste here the output. Kind regards

Hello! Assuming that you use Windows: If you use the Air client: - right click on the Air dock icon, select "Logs", click on "Copy to clipboard" and paste here If you use OpenVPN GUI: - right-click on the OpenVPN GUI dock icon, select -->View Log. A text editor will open the log file, select all the text, copy & paste. Kind regards

Hello! Can you please send us your client logs? You subscribed some months ago, has this problem occurred recently? Kind regards

Hello! When you're connected, and before the ping timeout occurs, can you ping the entry-IP of the server you're connected to? For example (in your Serpentis case): ping 178.248.30.131 Just in case, are you running PeerBlock on your system? Is the problem occurring even with any firewall and antivirus (and PeerBlock) disabled? After you have checked that, try a connection to a different server. Also, try a connection to a TCP port. We're looking forward to hearing from you. Kind regards

Hello! Great, glad to know it. According to your reports no improvement is necessary. For your comfort, you might define a Network Zone (for example [Air servers entry IPs]) containing only the entry-IP addresses of our servers and then set two rules like Allow TCP or UDP In/Out From In [Air servers entry IPs] To MAC Any Where Source Port Is Any And Destination Port Is Any Allow TCP or UDP In/Out From MAC Any To In [Air servers entry IPs] Where Source Port Is Any And Destination Port Is Any In this way, you will only need to add a single IPv4 addresse to that Network Zone in order to connect to a new server, instead of defining two additional rules for each server, which may be annoying if you switch between a lot of servers. Kind regards

Hello! Ok, situation now is much clearer. The rule: Allow TCP or UDP In/Out From MAC Any To IP 192.168.0.254 Where Source Port Is Any And Destination Port Is Any will allow at least DNS leaks, please delete it. The rule: Block And Log TCP or UDP In/Out From MAC Any To MAC Any Where Source Port Is Any And Destination Port Is Any is sub-optimal because prevents only TCP or UDP leaks, please modify it into: Block And Log IP In/Out From MAC Any To MAC Any Where Protocol Is Any (this will expand the total block to layer 3). We're looking forward to hearing from you. Kind regards

Hello! Unfortunately you renamed your Global Rules, so we can't see what they really state. It's not your fault, it's ours, we did not specify in the guide NOT to rename the rules, because renaming them makes troubleshooting impossible. We'll modify the guide accordingly. Anyway, from what we can see on the Comodo firewall event logs, it looks like you were not connected to an Air server, because there is a suspiciously high number of blocks from 192.168.0.31 to several different IP addresses. From your description, the DHCP rule is wrong, it should allow communications toward IP 255.255.255.255, because before the DHCP negotiation your computer can't know the address of your router or even the subnet of your network, see RFC 1541 and RFC 2131 or http://support.microsoft.com/kb/169289 Can you please delete your customized rules names, re-send the Global Rules and send us also the logs of your client and the output of the command "ipconfig /all"? It should take no more than a couple of seconds... Kind regards

Hello! We're sorry for the inconvenience. If some of our clients is sending out viruses through Serpentis it is violating our ToS. Please be aware that ToS violations will lead to investigations and account termination. Of course, it might also be just a false positive from CloudFlare. Kind regards

Hello! No problems, you can put all the files in a single zip archive or send them via mail to info@airvpn.org. Kind regards

Hello! In order to allow us to provide you with proper support please see https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142#3512 Kind regards

Hello! We confirm that bitshare blocks Tauri. Perhaps they are trying to make their service capable to track their users for legal concerns (it would be understandable after all the troubles occurred to file hosting services) or because they are hostile to privacy, who knows. At the moment it's possible to access bitshare at least from Herculis and Virginis. Kind regards

Hello! Splitting traffic on a ports basis within a subnet requires NAT filtering. An alternative method is splitting traffic on a destination IPs basis. See https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3721&Itemid=142#3724 but beware that the reported IP ranges are wrong, you'll need to discover Netflix IP ranges (and you'll have to elaborate a complementary solution - the message covers the case for which Netflix access is NOT tunneled - in your message it's unclear whether you want it to be tunneled or not). If you have more than one device connecting to the router, you can implement Policy Based Routing on the DD-WRT (which supports it) so that a certain device (the one that you wish to use for Netflix) will be or will not be tunneled over the VPN: http://www.dd-wrt.com/wiki/index.php/Policy_Based_Routing [EDIT] Please see also here: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=711921 Kind regards

Hello! You should translate rules from here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142 Outpost should be able to support all the reported rules. Kind regards

Hello! This is a symptom that you did not allow DHCP communications, please see step 11a of our guide: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142#3405 In case of further issues please see the following post so that you know what you can do to receive proper and quicker support: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142#3512 Kind regards

Hello! From your firewall events it's visible that you did not set the rule that allows DHCP, probably you missed this message: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=4919&limit=6&limitstart=18&Itemid=142#4964 In case of further issues please send us ALL the required information in order to receive proper support. Kind regards

Hello! Just in case, are you running PeerBlock on your system? Is the problem occurring even with any firewall and antivirus disabled? Can you please send us the OpenVPN logs with firewall, antivirus (and PeerBlock, if you use it) disabled? Kind regards

Hello! Readable screenshots are just fine. Kind regards

Hello! The IPFire Wiki has a lot of pages about it: http://wiki.ipfire.org/en/configuration/services/openvpn Kind regards