Re: Comodo Firewall Settings

[itsmeprivately 14]

Hi jjac,

for what it is worth, below is a more detailed list of instructions for the Comodo setup explicitely for Windows XP, on a 192.168.x.x home network with the router (192.168.0.1) acting as a DHCP server. It is of course mainly the instructions provided by admin here, but is more detailed:

https://airvpn.org/index.php?option=com_kunena&func=view&catid=3&id=3405&Itemid=142

Once you have correctly configured Comodo to prevent any IP or DNS leaks, AirVPN is a great service with superb customer support, and I'm really glad I chose them.

So here are the detailed instructions:

1) If you're not familiar with a firewall, read Comodo Firewall manual or guides

2) Install Comodo Personal Firewall free version available here: personalfirewall.comodo.com/ In the first installation window, unselect "Comodo SecureDNS Servers" and unselect "Cloud Based Behavior Analysis". Don't click on "Agree and Install" yet, first click on "Customize Installer". There unselect "GeekBuddy" in the Installation Options. Also unselect "Defense+" and unselect "Do NOT show alerts...." in the Configuration Options.

After installing Comodo Personal Firewall, your computer needs to be restarted. After restarting, the Windows Firewall should already have been disabled by Comodo. If not, just do it manually. If Codomo detects your home network, just select that you are "at Home", but don't use encryption with Comodo's "TrustConnect" (just say "continue unencrypted"). Comodo will call this network zone by default "Home #1".

Open Comodo (right-click on Icon and select "Open...").

3) Set the Firewall Security Level (Firewall -> Firewall Behavior Settings) to "Custom Policy". You can also do this by right-clicking directly on the Comodo icon and choosing the appropriate setting. Leave the other two ("Defense+" and "Sandbox") disabled, which is the default.

Open the Air VPN client and when asked by Comodo, allow it to connect to the internet. Also allow Open VPN in the same way. When asked by Comodo, select this again as a network "at Home". Comodo will call this network zone by default "Home #2".

4) Define the Network Zone of your TAP-Win32 network adapter (let's call it "AirVPN"). A safe way to broadly define it is to use IPv4 Address Range [10.4.0.0 - 10.9.255.255]. You can do this by simply redefining your "Home #2" network zone, for example.

5) Determine the entry-IP addresses of the AirVPN server(s) you wish to connect to. You can get this info from the *.ovpn configuration files (open only with NOTEPAD), which can be

generated on the AirVPN website (https://airvpn.org) at the page called OpenVPN Configuration Generator (direct link: https://airvpn.org/direct_access/). To reach this page from the main AirVPN website (https://airvpn.org), click on the following: Enter -> Choose your System (Windows) -> "Access without client" -> (here you are!)

6) Define a "Global Rule" in Comodo which blocks everything:

Block And Log IP In/Out From MAC Any To MAC Any Where Protocol Is Any

The logging is important for troubleshooting if necessary.

Do this by Global Rules -> Add (Action: Block + Log as a firewall event, Protocol: IP, Direction: In/Out, Description: (leave blank), Source Address: Any Address, Destination Address: Any Address, IP Details: IP Protocol Any.

7) Put the above Global Rule in the top position. This will block completely your connectivity and let you add a whitelist of "Allow-global-rules" put BEFORE this total block global rule. All the "Allow" rules that you want to be evaluated shall be put BEFORE the above block rule.

(Note: all rules that were in Comodo by default are of course now BELOW this global block rule, and are therefore irrelevant and can be deleted)

8) Define a"Global" rule which allows in/out communications of your TAP-Win32 adapter ("AirVPN") both In and Out:

Allow IP In/Out From In [AirVPN] To MAC Any Where Protocol Is Any

Allow IP In/Out From MAC Any To In [AirVPN] Where Protocol Is Any

9) Do the same for your loopback zone (redefine broadly as IPv4 range 127.0.0.0 - 127.255.255.255):

Allow IP In/Out From In [Loopback Zone] to MAC Any Where Protocol Is Any

Allow IP In/Out From MAC Any To In [Loopback Zone] Where Protocol Is Any

10) Do the same for any entry-IP address of the VPN servers you wish to connect to. For example for Castor:

Allow TCP or UDP In/Out From IP 95.211.169.3 To MAC Any Where Source Port Is Any And Destination Port Is Any

Allow TCP or UDP In/Out From MAC Any To IP 95.211.169.3 Where Source Port Is Any And Destination Port Is Any

10a) OPTIONAL: When mutorrent is running, there may be occasional "Windows Operating System" connection attempts with protocol ICMP 11.1 from the Home Network directly to the VPN server. Their cause and purpose is unknown. These will be blocked anyway by the "block everything-rule" number 6. Note that it is good that they get blocked, because when AirVPN is up, the only application connecting directly from the real network card (Home Network = 192.168.x.x) [i.e. bypassing the tunnel] to the outside should be openvpn.exe [and that connection must only go to the VPN server]. You can verify this by opening the "View Active Connections" in Comodo. All other active connections to the outside must have as the source IP address an IP address of the TAP-Win32 adapter network zone (AirVPN = 10.x.x.x). Although the above-mentioned ICMP connection attempts are blocked anyway, let's block them explicitely without logging, so that the blocks don't clog up our Firewall Event logs. If Castor is the VPN server, for example:

Block ICMP Out from In [Home Network] to IP 95.211.169.3 Where ICMP Message Is 11.1

11) Add similar rules to allow communications of your device with your router (and within your home/office network, if you wish so). For example, if your network is [192.168.0.0 / 255.255.0.0] define a network zone with IP Range [192.168.0.0 - 192.168.255.255] (let's call it "Home Network") and set the following rule:

Allow IP In/Out From In [Home Network] To In [Home Network] Where Protocol Is Any

EDITED by Admin

A better set of rules which replace the above rule (which may allow DNS leaks under some circumstances) is:

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

These three rules replace the above rule, which you should delete

Note that the above rule allows unencrypted communication of your PCs pyhsical network adapter (f.ex., 192.168.0.185 = your real IP) with the router (f.ex., 192.168.0.1), which is of course vital, otherwise it would not be possible to communicate with the router at all. But this makes it necessary to eliminate DNS leaks through the router. One way to do this is to configure *fixed* DNS server addresses for your physical adapter. To do this, proceed as follows:

Under Settings -> Network Connections, select your PC's physical network adapter (for example your WLAN adapter, or LAN adapter), and under Internet Protocol (TCP/IP) Properties, choose "Use the following DNS server addresses" (here for example from the Swiss Privacy Foundation):

Preferred DNS server: 87.118.104.203

Alternate DNS server: 62.141.58.13

Note that, as long as AirVPN and Comodo are running, any (!) fantasy addresses could in fact be chosen here, since DNS queries to these addresses from your physical adapter are blocked anyway by the Comodo block-all rule. But the good thing is that the query is never sent to the router this way. After being blocked by Comodo, the query is then subsequently sent through the next available network adapter, which is the AirVPN TAP-adapter, and the DNS query thus goes through the VPN tunnel to 10.4.0.1 (i.e., encrypted to the AirVPN DNS, and after preliminary resolution, AirVPN later routes them to Google DNS).

So you *could* just use fantasy DNS server addresses, but in order to keep DNS queries working even when AirVPN and Comodo are *NOT* running (maybe for testing purposes), better use good working DNS server addresses. The above two DNS server addresses chosen are the DNS servers of the "Swiss Privacy Foundation" since they don't log or block.

11a) If your router acts as a DHCP server, allow DHCP "negotiation":

Allow IP In/Out From MAC Any To IP 255.255.255.255 Where Protocol Is Any

11b) OPTIONAL: If your Home Network communicates with the router for SharePort, UPnP, Multicast or other announcements, you can allow that, too. The IP addresses used for this are all in the "host group addresses" range (from 224.0.0.0 to 239.255.255.255, not part of the internet). First define a network zone with IP Range [224.0.0.0 - 239.255.255.255] (let's call it "Host Group Addresses") and set the following rules:

Allow IP In/Out From In [Home Network] To In [Host Group Addresses] Where Protocol Is Any

Allow IP In/Out From IP 0.0.0.0 To In [Host Group Addresses] Where Protocol Is Any

(The second rule just covers the rare case that the PC takes 0.0.0.0 as its "dummy" IP when it is not even able to connect to any TCP/IP network.)

12) In order to allow "airvpn.org" resolution even when disconnected (and any other hostname you wish to be resolved even when VPN is disconnected), add to your hosts file (c:\windows\system32\drivers\etc\hosts) the line

85.17.207.151 airvpn.org

13) If you use the Air client, add rules to allow communications with hostname airvpn.org or IP 85.17.207.151, In and Out

Allow TCP or UDP In/Out From IP 85.17.207.151 To MAC Any Where Source Port Is Any And Destination Port Is Any

Allow TCP or UDP In/Out From MAC Any To IP 85.17.207.151 Where Source Port Is Any And Destination Port Is Any

14) You can progressively enlarge your whitelist just by adding "Allow" rules before the total blocking rule of point 6) according to your system needs.

[itsmeprivately 14]

As a supplement to my post above, here is still some background info about possible choices for fixed DNS server configurations in your physical network adapter.

Note that, like my previous post, this is specifically for WinXP with a 192.168.x.x home network, where the router (192.168.0.1) acts as a DHCP server.

Why it it important to use fixed DNS servers in your physical network adapter, and not just leave the default setting "Obtain DNS server address automatically"? Because if you leave the default setting, then your router 192.168.0.1 will automatically be chosen (by DHCP push) as the DNS server. And any DNS queries will go from your adapter (= your real IP) to the router, and from the router unencrypted out to your ISPs DNS server, who will then see your real IP and what DNS you query. Codomo would not prevent this, since the Comodo Rules (running only on the PC with the physical adapter) allow unencrypted communications within the Home Network, and thus to the router. On the router itself, no Comodo is running, of course.

Such DNS leaks through the router can be prevented by setting fixed DNS server addresses in your physical network adapter (f.ex. WLAN adapter), which replace the default router address. Then your adapter will always send DNS queries directly to the fixed address(es), and (even if this fails) never to the router.

Now suppose AirVPN and Comodo are running. A DNS query from your physical adapter (directly to the fixed DNS address) will be blocked by Comodo, since it would be traffic to the internet (not within Home Network) outside the VPN tunnel. Since this query does not work, Windows (by default) then (permanently) chooses the next available adapter (which is the AirVPN TAP-adapter whose traffic always goes through the tunnel) for the query, and the same query will now be sent to the DNS server address configured for this adapter. By TAP-adapter-default ("Obtain DNS server address automatically") this is 10.4.0.1. So the query would go there through the tunnel and not be blocked by Comodo. At this DNS server (10.4.0.1), AirVPN first makes a resolution attempt in order to bypass DOJ / ICE censorship and then routes the query to Google DNS servers, who then answer the query.

Now suppose AirVPN and Comodo are not running, and the computer is used normally without a VPN (for example for testing purposes). Then these fixed DNS server addresses will actually be used for DNS queries, so therefore it is important to choose good servers.

Finally note: Of course, you can also set the same fixed DNS server addresses in your AirVPN TAP-adapter, which would then replace the default address 10.4.0.1. If you do this, you would no longer use AirVPN's DNS server setup (= pre-resolution and then routing to Google DNS) when AirVPN and Comodo are running, but would use the fixed DNS server address instead. Note that in this case, the AirVPN internal speed test (speedtest.air) will NOT work, since this is *only* resolved by the AirVPN DNS server 10.4.0.1.

Here are some choices for DNS servers:

The German-Swiss Privacy Foundation (does not log and does not censor any DNS)

-----------------------------------------------------------------------------------------------------

http://server.privacyfoundation.de/index_en.html

http://www.privacyfoundation.ch/

Preferred DNS server: 87.118.104.203

Alternate DNS server: 62.141.58.13

Telecomix DNS Project (also good)

-------------------------------------------

http://werebuild.telecomix.org/wiki/DNS

Preferred DNS server: 91.191.136.152

Alternate DNS server: 85.229.85.109

Codomo Secure DNS servers (policies unknown)

-----------------------------------------------------------

http://www.comodo.com/secure-dns/

Preferred DNS server: 8.26.56.26

Alternate DNS server: 156.154.70.22

Google DNS servers (very good net neutrality, but not good privacy)

----------------------------------------------------------------------------------

https://developers.google.com/speed/public-dns/

Preferred DNS server: 8.8.8.8

Alternate DNS server: 8.8.4.4

[Staff 9972]

Why it it important to use fixed DNS servers in your physical network adapter, and not just leave the default setting "Obtain DNS server address automatically"? Because if you leave the default setting, then your router 192.168.0.1 will automatically be chosen (by DHCP push) as the DNS server. And any DNS queries will go from your adapter (= your real IP) to the router, and from the router unencrypted out to your ISPs DNS server, who will then see your real IP and what DNS you query. Codomo would not prevent this, since the Comodo Rules (running only on the PC with the physical adapter) allow unencrypted communications within the Home Network, and thus to the router. On the router itself, no Comodo is running, of course.

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

[itsmeprivately 14]

Hello admin,

thanks a lot for the quick reply and the correction !!

I still have a question about the fixed DNS issue:

Can you imagine any situation where the rules

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

may *not* work?

The reason I'm asking: I have tried this before, and I think I did everything right, but it did not work for me. What happened was:

1. First I used just the original Home Network rule (allow all trafic within Home Network)

2. I tried the DNS leak site: http://www.dnsleaktest.com/index.php and it showed a DNS leak to my real ISP IP through the router.

3. I deleted the original Home Network rule and used the 3 rules above instead.

4. I browsed again to the DNS leak site and there were no leaks.

5. I browsed to some other sites I had visited before switching to the 3 rules, and could reach them no problem (so everything seemed ok).

6. I browsed to a *new* site I had not visited in a while. And then I could *not* reach it. I tried more new sites, and any site that I had not visited recently was *not* reachable.

7. I did not know what else to do to make it work. So then I went back to the original Home Network rule (allow all traffic) and configured my physical adapter with fixed DNS server addresses. This fixed everything.

Do you know why this might be the case?

[huntergatherer 0]

Hi,

Just wondering if you could give me a hand. I've tried following your instructions but when I try to connect through the Air VPN client, it says "Unable to connect to the remote server".

I have included a screenshot of the global rules. If you need any more info just let me know. I have a basic understanding of computers but am a bit of an idiot when it comes to this.

Any help would be much appreciated!

[itsmeprivately 14]

To admin: I just tried the 3 new rules for the Home Network again to make sure. I can confirm that, for me, it does not work. As soon as I apply the rule that blocks UDP port 53, no DNS can be resolved on my system anymore (when physical adapter is configured to "obtain DNS servers automatically"). The only way it works for me is if I do it exactly as described in my original post (before your edit), i.e., use the original single Home Network rule (allow all traffic), and configure the physical adapter with fixed DNS addresses. I don't think my system is special in any way, so probably this should be investigated.

To huntergatherer: Your Home Network zone is defined too narrowly, please read the instructions again carfully for the Home Network definition.

(EDIT: I just noted that you had included Serpentis - sorry it was my mistake when I said that this is missing in your rules).

Also, did you change your host file, according to the instructions, and did you specify fixed DNS servers for your physical adapter?

I would also recommend specifying the Network Zones explicitly with *clear* names, so that in the Global Rules, things are much clearer (then it's easier to spot mistakes). I have attached a screenshot of my Network Zones, and of my Global Rules. *First* define the Network Zones, and *then* the Global Rules (this way you can *choose* the Network Zones in the Global Rules when specifying in what IP range a Global Rule should apply.)

[Staff 9972]

Hi,

Just wondering if you could give me a hand. I've tried following your instructions but when I try to connect through the Air VPN client, it says "Unable to connect to the remote server".

I have included a screenshot of the global rules. If you need any more info just let me know. I have a basic understanding of computers but am a bit of an idiot when it comes to this.

Any help would be much appreciated!

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

[itsmeprivately 14]

(same post again... last time the attached screenshot was too large)

To admin: I just tried the 3 new rules for the Home Network again to make sure. I can confirm that, for me, it does not work. As soon as I apply the rule that blocks UDP port 53, no DNS can be resolved on my system anymore (when physical adapter is configured to "obtain DNS servers automatically"). The only way it works for me is if I do it exactly as described in my original post (before your edit), i.e., use the original single Home Network rule (allow all traffic), and configure the physical adapter with fixed DNS addresses. I don't think my system is special in any way, so probably this should be investigated.

To huntergatherer: Your Home Network zone is defined too narrowly, please read the instructions again carfully for the Home Network definition. Also, did you change your host file, according to the instructions, and did you specify fixed DNS servers for your physical adapter?

I would also recommend specifying the Network Zones explicitly with *clear* names, so that in the Global Rules, things are much clearer (then it's easier to spot mistakes). I have attached a screenshot of my Network Zones, and of my Global Rules. *First* define the Network Zones, and *then* the Global Rules (this way you can *choose* the Network Zones in the Global Rules when specifying in what IP range a Global Rule should apply.)

[Staff 9972]

Hello admin,

thanks a lot for the quick reply and the correction !!

I still have a question about the fixed DNS issue:

Can you imagine any situation where the rules

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

may *not* work?

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.

The reason I'm asking: I have tried this before, and I think I did everything right, but it did not work for me. What happened was:

1. First I used just the original Home Network rule (allow all trafic within Home Network)

2. I tried the DNS leak site: http://www.dnsleaktest.com/index.php and it showed a DNS leak to my real ISP IP through the router.

3. I deleted the original Home Network rule and used the 3 rules above instead.

4. I browsed again to the DNS leak site and there were no leaks.

5. I browsed to some other sites I had visited before switching to the 3 rules, and could reach them no problem (so everything seemed ok).

6. I browsed to a *new* site I had not visited in a while. And then I could *not* reach it. I tried more new sites, and any site that I had not visited recently was *not* reachable.

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

7. I did not know what else to do to make it work. So then I went back to the original Home Network rule (allow all traffic) and configured my physical adapter with fixed DNS server addresses. This fixed everything.

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

[huntergatherer 0]

Hi,

Thank you for your reply. I have made the proposed changes but the connection says that there is limited connectivity.

I changed the wireless adaptor ipv4 to manually select the Swiss DNS servers given but that just gave me "The DNS server is not responding".

Any other possible solutions?

Cheers

[Staff 9972]

@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

[itsmeprivately 14]

Thanks, admin for the reply!

"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."

I use OpenVPN 2.2.2 (never re-installed, just one single install), and the DNS push to 10.4.0.1 also showed up correctly in ipconfig /all

However, I just tried again today, and now the 3 new/modified rules *do* work for me! This is indeed strange, and I will keep an eye on it, since yesterday (and also a few days back) it did definitely not work. Maybe the PC just needed a good fresh restart?

Anyway, I'm happy that it works now, and that I even have two ways to make it work (either the 3 new Home Network rules, or the single old Home Network rule PLUS setting fixed DNS for the physical adapter). And I learned a lot in the process, too!!

Thanks again for the great customer support!!

[huntergatherer 0]

Basically if the firewall is enabled, the internet connection is unsuccessful. If I connect first, then enable the firewall, I can access the internet and connect to the VPN. However, browsing etc doesn't work.

Here are the logs etc.

[Staff 9972]

@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

[huntergatherer 0]

Global Rules

[huntergatherer 0]

Network rules

[huntergatherer 0]

Firewall events

[huntergatherer 0]

Ipconfig

[Staff 9972]

Basically if the firewall is enabled, the internet connection is unsuccessful. If I connect first, then enable the firewall, I can access the internet and connect to the VPN. However, browsing etc doesn't work.

Here are the logs etc.

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

[dogeyes7 0]

Hi

Aren't the loopback zone,home 1 & home 2 in the network Rules attactchment that Huntergather has posted wrong?,there set as subnet mask instead of ip address range format.

Or am I missing something?

Cheers D

[Staff 9972]

Hi

Aren't the loopback zone,home 1 & home 2 in the network Rules attactchment that Huntergather has posted wrong?,there set as subnet mask instead of ip address range format.

Or am I missing something?

Cheers D

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

[dogeyes7 0]

Hi

I have my loopback zone and home zone setout in the ip address range format unlike Huntergather,does this restrict me in anyway?

Cheers D

[Staff 9972]

Hi

I have my loopback zone and home zone setout in the ip address range format unlike Huntergather,does this restrict me in anyway?

Cheers D

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

[huntergatherer 0]

Hi,

I have made the change. I can connect to my router and the internet (turns off occassionally). I can't however use the browser or connect to tor (using the sock proxy). Here are the firewall logs that didn't seem to get posted last time.

[huntergatherer 0]

firewall events

FirewallEvents.txt