Staff

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

Hello! Not at all. As long as the zones are correctly defined, it makes no difference using an IP range or an IP / NetMask, it's just a matter of tastes and convenience. Kind regards

Hello! They are correct: Huntergather defined the correct IP / NetMask. However, in this particular case the Network Zones are not relevant because they were not used neither in the Global Rules nor in the Application Rules. A useful tool to perform quick calculations: http://www.subnet-calculator.com/cidr.php Kind regards

Hello! Please make sure that you have enabled logging for the block rule (tick the box "Log as a firewall event when this rule is fired") and that your hosts file has been modified according to the instructions (see step 12). Then please send us: - your network zones - your global rules - your application rules - Comodo Firewall events logs Kind regards

Hello! Thank you for all the logs. From the ipconfig we can see that your router is a DHCP server. In the Global Rules, DHCP is not allowed, so your computer can't communicate with it to get an IP address, gateway etc. etc. To allow DHCP communications please add the rule (above the block all rule) specified in step 11a: Allow IP In/Out From MAC Any To IP 255.255.255.255 Where Protocol Is Any Kind regards

Hello! You can put them anywhere as long as they are above the block rule, as you correctly write, because Comodo (like many other firewalls) evaluates rules from top to bottom. Kind regards