Staff

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

Hello! This will help you: http://openvpn.net/archive/openvpn-users/2004-11/msg00044.html Ping the entry-IP address of the server you wish to connect to in order to have a quicker approximation of the size you need to set with mssfix. Kind regartds

Hello! Excellent, thank you for the information. You can fine-tune the parameter trying to lower (or increase) it in small steps and test each time whether the performance improves or gets worse. Do not exceed 1500, of course. Our servers are configured with default OpenVPN MTU size in order to provide best performance with UDP in case of no or low packet loss/fragmentation. Probably a guide is necessary for clients which have fragmentation issues in order to mitigate the issue on the client side only, we'll be working on it (not difficult, the OpenVPN community wrote a lot about it). Kind regards

Hello! Some DNS servers listen to ports 53 UDP and port 53 TCP as well. If Windows sent out queries toward port 53 TCP, the above rules would not prevent DNS leaks and the TCP rule should be modified into "Allow TCP In/Out From In [Home Network] ... Where Destination Port Is Not 53". However, from Microsoft documentation this is not the case, queries are sent always toward 53 UDP. After step 3, Windows was resolving the names through the DNS Resolver Cache filled during step 1, 2, 3 (and possibly before). When you tried resolutions of names that were not in the resolver cache, your system was unable to send out a proper DNS query to the VPN DNS, or was unable to receive the reply from the server (did it happen with all servers?). In order to ascertain the reasons, you should check whether the OpenVPN server DNS push is accepted correctly by your client. If this does not help, monitor the DNS queries with Comodo. If you need deeper analysis, you can use Wireshark. Please note that in some OpenVPN releases there were some bugs pertaining to the TAP-Win32 Adapter which may cause this problem. The bugs affected only Windows and have been fixed with 2.2.2. Please note that if you upgraded to 2.2.2 but the installer failed to upgrade the adapter driver, you might still have issues. http://openvpn.net/index.php/open-source/documentation/change-log/425-changelog-for-openvpn-22.html Good workaround. It would be interesting to see what happens in your system if you force the VPN DNS on your physical card (for example 10.4.0.1 if you connect to 443 UDP, see https://airvpn.org/specs). Kind regards

Hello! Can you please make sure that in your hosts file you have the line 85.17.207.151 airvpn.org On a standard Windows installation the hosts file is located in the directory C:\Windows\system32\drivers\etc You can edit it with any text editor like NotePad. You need to launch the editor with administrator privileges. When you add the line, make sure to press ENTER at the end of it. Also, please check that your home network IP range is correct (if in doubt, you can safely expand it in the rules to [192.168.0.0 - 192.168.255.255]) Also, you might like to delete the rule Allow IP In/Out From In [192.168.1.1 - 192.168.255.254] To In [192.168.1.1 - 192.168.255.254] Where Protocol Is Any and replace it with the three rules reported in step 11 here: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142#3405 in order to prevent possible DNS leaks. The other rules are just fine. Please feel free to report whether the above solves the problem. Kind regards

Hello! Thank you for your post. However, the quoted part is not correct. The recommended Comodo rules will prevent even in this case leaks, see step 11 on https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142#3405 The crucial rules are: Allow TCP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Any Allow UDP In/Out From In [Home Network] To In [Home Network] Where Source Port Is Any And Destination Port Is Not 53 Allow ICMP In/Out From In [Home Network] To In [Home Network] Where ICMP Message Is Any Probably you have missed the editing of the post to include this case some time ago. EDIT: to avoid confusion, the original guide has been modified and the problematic rule has been deleted, because the three above rules can be applied anyway. Also, even without those rules, it's incorrect to state that "any DNS queries will go from your adapter (= your real IP) to the router". This will happen only when Windows "leaks", that is when it does not respect the routing table and its metric pushed by our servers, sending (or possibly duplicating) a DNS query outside the tunnel. Thank you again. Kind regards

Hello! Some references: http://dmca.cs.washington.edu Kind regards

Hello! Yes, of course. In case of problems, you can also rely on switching Comodo back to "Safe Mode" or disable it completely. Also, the Firewall Event Logs are very useful for troubleshooting, in order to check whether Comodo is blocking something that you meant not to be blocked (just enable the logging for every block rule). If your DHCP server IP address coincides with all the DNS IP addresses configured/pushed for your computer physical network card(s) (you should check this both for primary and secondary DNS) and your DHCP server is your router then your computer will suffer no DNS leaks. We're sorry, we're not in the position to suggest an antivirus. The first thing you should check is the compatibility of an antivirus with Comodo. Some antivirus for Windows come in suites which might conflict with Comodo Defense+ and/or firewall. According to our experience we highly recommend both Comodo Firewall and Comodo Defense+ so it may be desirable to pick an antivirus that runs nicely with them. Comodo lets you run programs in a sandbox and Defense+ set to "Paranoid Mode" is a good defense for a Windows system. Comodo Antivirus obviously does not conflict, but we don't know anything about its effectiveness. Thank you! This forum is getting more and more interesting thanks to a fantastic community. Kind regards

Hello! So speedtest.air is correctly resolved and reachable, but the browser can't fetch it... can you please try also wget speedtest.air in order to see what happens to http requests inside the VPN... ...and outside: ping google.com ping 173.194.67.104 wget google.com Let's see the above http requests to determine if it's a problem related to the browser only (which browser is it? can you try another one?). We're looking forward to hearing from you. Kind regards

Hello! While you're connected to Virginis, can you please perform the following tests (from a shell) and send us the output of the commands? ping 10.4.0.1 ping speedtest.air Also, try to open speedtest.air with a browser. Additionally, can you please make sure that you have nothing that might block communications with Virginis from/to the tun0, such as LittleSnitch, some firewall rules... Kind regards

Hello! Linux-based systems are not affected by DNS leaks (as long as their OpenVPN client accepts the push from our OpenVPN server), since they have a global DNS. The "DNS leak" is a problem which normally torments only Windows systems which lack the concept of a global DNS. Anyway, you might like to secure your OpenVPN connection in Linux against any leak, including leaks in case of unexpected VPN disconnections: https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=1713&limit=6&limitstart=30&Itemid=142#2010 Kind regards

Hello! You have probably blocked communications with your DHCP server. If so, this method has another significant side effect besides the ones you noticed, which may be good or annoying according to your tastes, that is your computer will not be able to get any connectivity at the boot (it will not even be able to connect to your router), because it can't communicate with any DHCP server. If you don't like this, you can anyway set a suitable static IP address for your computer network adapter. Make sure that you pick it inside your home net IP range and that it does not overlap with any other address in the network. Generally speaking, be aware that this method does not necessarily prevent DNS leaks, so if you set a static IP and static DNS servers to render DHCP pushes superfluous, re-check carefully for these leaks while you're connected to the VPN. Yes, it is necessary because the Air client needs to resolve airvpn.org in order to handle the login, display the list of servers and download files before giving control to OpenVPN. But with the recommended Comodo rules we have blocked DNS queries outside the tunnel. And the tunnel is not yet existing. So we need to allow "airvpn.org" resolution internally, that is exactly the purpose of the hosts file on any system. Playing with the hosts file is not dangerous, as long as you know what you're doing. On the contrary it becomes an extremely dangerous issue if some malware is playing with your hosts file, because it can hijack your connections (you type a hostname, you think you are accessing a certain service or website, while in reality you're on a fake one). So having a look at the hosts file after all is beneficial, not dangerous. Kind regards

Hello! Try to force your router to use the VPN DNS as primary, for example 10.4.0.1 if it connects to 443 UDP https://airvpn.org/specs Kind regards

Hello! This is very puzzling, because you can connect and exchange data without problems on any other server, and Virginis configuration is just the same. Can you please tell us whether you see in the logs this very same line (near the DEBUG lines) when you connect to a server that works for you? *Tunnelblick client.up.tunnelblick.sh: ServerAddresses '10.4.0.1' ignored because ServerAddresses was set manually Kind regards