Staff

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

Hello! That's fine, we're glad to know it. Probably so. Or maybe your ISP had a temporary problem. Just in case you'll need it in the future (hopefully not) when you perform ping tests with different packet sizes toward the entry-IP of a VPN server to determine the optimal value (if necessary) for mssfix, you don't need to be connected to that VPN server, and even if you're connected to that server, it's not relevant removing the mssfix directive because packets to/from the entry-IP will not be tunneled of course. In general, you need to perform the test while you are not connected to any VPN server. [EDIT - for readers' comfort and future reference, an excerpt from OpenVPN 2.2.2 manual] --mtu-test To empirically measure MTU on connection startup, add the --mtu-test option to your configuration. OpenVPN will send ping packets of various sizes to the remote peer and measure the largest packets which were successfully received. The --mtu- test process normally takes about 3 minutes to complete. --fragment max Enable internal datagram fragmentation so that no UDP datagrams are sent which are larger than max bytes. The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. The --fragment option only makes sense when you are using the UDP protocol ( --proto udp ). --fragment adds 4 bytes of overhead per datagram. See the --mssfix option below for an important related option to --fragment. It should also be noted that this option is not meant to replace UDP fragmentation at the IP stack level. It is only meant as a last resort when path MTU discovery is broken. Using this option is less efficient than fixing path MTU discovery for your IP link and using native IP fragmentation instead. Having said that, there are circumstances where using OpenVPN's internal fragmen? tation capability may be your only option, such as tunneling a UDP multicast stream which requires fragmentation. --mssfix max Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes. The default value is 1450. The max parameter is interpreted in the same way as the --link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. The --mssfix option only makes sense when you are using the UDP protocol for Open? VPN peer-to-peer communication, i.e. --proto udp. --mssfix and --fragment can be ideally used together, where --mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP), --fragment will internally fragment them. Both --fragment and --mssfix are designed to work around cases where Path MTU dis? covery is broken on the network path between OpenVPN peers. The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage. Kind regards

@huntergatherer Hello! We can see only the application rules. Please send us at your convenience: - your network zones - your global rules - Comodo Firewall events logs - the output of the command "ipconfig /all" (launch this from a command prompt) Kind regards

Hello! On Mac OS X it does. Tunnelblick and Viscosity implement different kexts and scripts, they "wrap" OpenVPN differently, in the respect of the configuration file of course. Viscosity price is 9 $ but they offer 30 days free trial which is perfect for testing purposes and determine whether foole's problem is caused by Tunnelblick or not. It should not take a long time to test Viscosity, once installed you can just click on the Air configuration file(s) already used by Tunnelblick to invoke Viscosity and start the connection. A slightly annoying thing is that if you switch from Viscosity to Tunnelblick you might need to unload Viscosity kext (which Viscosity does not unload) which conflicts with Tunnelblick kexts (anyway it's just a command line). On the contrary Tunnelblick behaves politely, keeping the kexts loaded only when it runs. But the "OpenVPN GUI" is for Windows only. The only other OpenVPN GUI/wrapper for Mac OS X 10.7 and 10.8 we're aware of is Shimo, which is more expensive than Viscosity. Yes, we don't detect any problem on Virginis as well, so we suspect that foole's problem is on client end. The puzzling thing is that foole does not experience any problem with any other server and ICMP packets correctly flow in and out the VPN to/from his client in Virginis. Kind regards

Hello! Have you tried, from your home, different servers and ports? Can you please send us the logs of your client? Kind regards

Hello! Sorry for the lack of information. Viscosity is another OpenVPN GUI (but not open source, except in the OpenVPN binaries of course) for Mac OS X and Windows. http://www.sparklabs.com/viscosity/ Kind regards

Hello! Please report the problem on the Tunnelblick Discussion Group. Include all the tests (all pings and curl) performed so far and the logs. Underline that you have no problems on several servers and that all the OpenVPN servers have the very same configuration. Tunnelblick Discussion Forum In the meantime, you might try a connection with Viscosity, to see whether it solves the problem. Thank you. Kind regards

@foole Hello! Sorry, wget is not included by default by Apple. Try these: curl -0 -L http://speedtest.air -o test1 curl -0 -L http://www.gooogle.com -o test2 and please send us the output of the commands (you can subsequenly delete test1 and test2 if curl was able to connect to the websites). Kind regards

@huntergatherer Hello! Please send us at your convenience: - your network zones - your global rules - your application rules - Comodo Firewall events logs - the output of the command "ipconfig /all" (launch this from a command prompt) Kind regards