Blocking all non-VPN traffic (Windows)

[2maggie 1]

OK

[2maggie 1]

After restarting doesn't seems to be working.

Started new Topic with this particular problem.

[2maggie 1]

Yes, sunnymorning, I did add "46.105.19.36 airvpn.org" into Windows\system32\drivers\etc\hosts file and verified a few times that its there...

[2maggie 1]

maggieairvpn wrote:

Dear admin,

You wrote: "and system applications (especially svchost.exe, to prevent DNS leaks) with the above rule."

When I apply "Block TCP or UDP Out From IP Not In [10.4.0.0-10.9.255.255] To MAC Any Ports Any" for Comodo SNCHOST.EXE Application Rules,

after restarting Win7 I'm getting Unidentified Network for my primary LAN and No Internet for your service to Connect & Check at all.

Any solution?

Thank you

Hello!

EDIT First of all please make sure that you refer to svchost.exe because snchost.exe is a trojan/backdoor

That's correct, because your system must not be able to send out DNS queries when you're not connected to the VPN. You have three options:

1) If you use the Air client, add to your hosts file the line:

46.105.19.36 airvpn.org

then connect to the VPN to restore your connectivity

2) If you use OpenVPN GUI (or OpenVPN directly), just connect to a VPN server to restore your connectivity

3) (not practical, unless you use the VPN rarely) put back svchost.exe to trusted application (or delete the rule) then reinstate the rule once connected to the VPN

Kind regards

______________________

Checking your options:

1. hosts file is not working (Win7, 64bit) properly when LAN adapted is blocked by Comodo. Tried CMD Ping, no connection to airvpn

2. Same thing with OpenVPN GUI, no connection when network is "Undentified"

Thank you

[Staff 9972]

maggieairvpn wrote:

Checking your options:

1. hosts file is not working (Win7, 64bit) properly when LAN adapted is blocked by Comodo. Tried CMD Ping, no connection to airvpn

2. Same thing with OpenVPN GUI, no connection when network is "Undentified"

Thank you

Hello!

Please delete the rule for svchost.exe and follow these instructions:

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

Kind regards

[2maggie 1]

Did it. Exactly. Step by step. Line by line.

Can't attach any files for you to verify.

When my LAN adapter is "Unidentified" after restarting, even GUI won't connect. Both adapters DNS TCP/Ipv4 = OpenVPN (208.67.222.222-208.67.220.220)

Please help

[Staff 9972]

Did it. Exactly. Step by step. Line by line.

Can't attach any files for you to verify.

Hello!

You can attach jpeg, doc, txt, gif and some other formats. If you are unable to do that, please send them via mail to info@airvpn.org

Also, a screenshot of your "Global Rules" would be helpful.

When my LAN adapter is "Unidentified" after restarting, even GUI won't connect. Both adapters DNS TCP/Ipv4 = OpenVPN (208.67.222.222-208.67.220.220)

Please help

Did you follow precisely all the 14 points described in the above linked post? Please send also details about your internal network and your implementation of point 11.

Kind regards

[itsmeprivately 14]

I have followed the detailed Comodo-procedure as described here by the admin:

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

and everything works well, thanks a lot for this. However, while it works for me for Castor (which was used as an example in the procedure linked above), it does NOT work for me when I try to use Serpentis.

In other words, if I replace the IP of Serpentis (178.248.30.132) for the IP of Castor in the below text, it does NOT work for me. I can log in to AirVPN, and choose Serpentis to enter, but then it just says "Connecting ...." forever. But it never connects.

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

Does anybody know why? Does it have to do with entry-IP and exit-IP and am I maybe using the wrong IP for Serpentis somewhere? Do I need a more elaborate global rule for Serpentis, than the one for Castor above?

Thanks for any help!

[Jinsong 5]

Looks like you've entered the wrong IP address. That was the IP address of the old Swedish server (Draconis) which is no longer in service.

What I usually do is create a less restrictive application rule for OpenVPN instead; that way I don't have to worry about keeping track of the inevitable changes/additions to the list of VPN server IP addresses.

For example:

Application Rules > [path]\openvpn.exe

Allow TCP Or UDP Out From MAC Any To MAC Any Where Source Port Is Any And Destination Port Is Any

Otherwise if you prefer to stick with the "Global Rules" method, you can just go to the Open VPN Configuration Generator page ( https://airvpn.org/direct_access/ ) to get the latest list of IP addresses from the *.ovpn config files and update your firewall rules accordingly. The only inconvenience of doing it this way is that you'll have to remember to update your rules periodically whenever a new server IP address is added, or else your firewall is going to block connection attempts to those unrecognized IP addresses by default.

[itsmeprivately 14]

Looks like you've entered the wrong IP address. That was the IP address of the old Swedish server (Draconis) which is no longer in service.

 

Oops, my bad. Thanks a lot!

[itsmeprivately 14]

Thanks for the help last time!

I have two more questions, any help on this would be great:

1)

I'm using the global rules method in Comodo as described here

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

(Note: BELOW the Global "totalblock" rule, I deleted all the *default* global rules with "Block ICMP..." that existed just after installation of Comodo, I hope this is ok, since they would not become relevant anyway, as they are below the total-block rule)

At first glance, everything seems to work as it should. But when I look in Comodo's

"Firewall Events", there are TONS of blocked events from "Windows Operating System" (Comodo just says: Application = Windows Operating System, it doesn't give the details about *what* application it is). Every few seconds there is a new blocking event like this, even if AirVPN is nicely connected, and everything (browsing, torrenting) works smoothly. These blocked "Windows Operating System" events want to go out to all kinds of different destination IPs (but can't because they are blocked). I am quite worried about this, since the global method should allow *all* traffic as long as the VPN is connected, right? Or is this not correct? But if it should allow all traffic, why do I get the blocked events in Comodo? Note that there are no popup windows on the desktop or anything, I just noticed this when peeking into Comodo's "Firewall Events" log.

2)

About once in 2 hours, AirVPN looses the connection and reconnects

automatically, which takes about 5 minutes.

When I click on My Computer -> Manage -> Event Viewer -> System,

I can see that during these disconnects there first is an event ID 1003

(Type: Warning) "Your computer was not able to renew its address from

the network (from the DHCP) server) for the network card with network

address <address>. The following error occurred: The operation was

cancelled by the user. Your computer will continue to try and obtain an

address on its own from the network address (DHCP) server"

The above event is repeated several times.

Finally (about 5 min after the initial event), there is an event ID 1002 (Type: Error)

"The IP address lease 10.4.x.y for the network card with network

address <address> has been denied by the DHCP server 10.4.x.(y-1)

(The DHCP Server sent a DHCPNACK message)".

After this last event, AirVPN is again nicely connected and works fine.

What does this all mean? Is this expected? (Of course, I would prefer not to have

any connection losses at all....)

[Staff 9972]

@itsmeprivately

1) It just means that Comodo is doing its job. By checking source and destination IP address you can see if you wish to authorize that traffic outside the tunnel or not.

2) Losing connection so often is not normal, probably you have connectivity issues with your ISP. Once you are disconnected, you should be able to reconnect immediately, but only if the ISP is giving you back full connectivity.

Kind regards

[itsmeprivately 14]

Thank you for the help!!! You guys are great!

I still have a few questions about the Firewall Events in Comodo,

when using the Global Rules Procedure, any info is appreciated:

1)

When I open mutorrent, I always get a (blocked) Firewall Event

from "Windows Operating System" with Protocol IGMP with

Source IP 192.168.0.198 to Destination IP 224.0.0.22

(no Ports are indicated in Comodo Firewall Events, the

fields in the table are blank) This event happens

exactly once. And when I close mutorrent

it again happens exactly once. Does this get blocked

by the Global Rules Procedure since 224.x.x.x is not

a legitimate (or normal) IP address?

2)

Also, while mutorrent is running, I keep getting (blocked)

Firewall Events from "Windows Operating System" every 5 seconds with

Protocol: ICMP, Source IP 192.168.0.198, Source Port: Type(11),

Destination IP: 95.211.169.3 (Castor), Destination Port: Code(1)

I guess they are blocked since in the Global Rules Procedure,

only TCP or UDP Protocols are allowed to Castor. Are these ICMP events

important and should I allow them?

3)

I noticed in my Firewall Events, there were short (blocked) UDP broadcasts

to 239.255.0.1 port 9303 every 10 seconds, and short (blocked) UDP broadcasts

to 239.255.255.250 port 1900 every 15 minutes from my Home Network.

I googled and found that these are announcements for my router SharePort

utility and for my router UPnP utility. I was surprised that these

events were blocked by the Global Rules Procedure. Why? Is it

because these are not normal (or legitimate) IP addresses?

To allow these events, I defined a network zone "Router SharePort

and UPnP" with the IP range 239.0.0.0 to 239.255.255.255,

and then added the following global rules rules ABOVE the block-all rule:

Allow IP In/Out From In [Home Network] To In [Router SharePort and UPnP] Where Protocol Is Any

Allow IP In/Out From In [Router SharePort and UPnP] To In [Home Network] Where Protocol Is Any

This eliminated the blocking of the events described above.

Is it safe to do this this way or am I allowing too much traffic that

could leak data in the worst case?

[Staff 9972]

Thanks for the help last time!

I have two more questions, any help on this would be great:

1)

I'm using the global rules method in Comodo as described here

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

(Note: BELOW the Global "totalblock" rule, I deleted all the *default* global rules with "Block ICMP..." that existed just after installation of Comodo, I hope this is ok, since they would not become relevant anyway, as they are below the total-block rule)

Hello!

Thank you for your nice words.

Yes, it's ok, the block rule we published blocks everything, so any other subsequent (i.e. "lower") block rule does not need to be evaluated.

At first glance, everything seems to work as it should. But when I look in Comodo's

"Firewall Events", there are TONS of blocked events from "Windows Operating System"

They are ok. They may be blocks of DNS leaks or UPnP attempts etc. If you wish to support UPnP, share printers etc., you can allow communications to and from the IP addresses you report on point 3). About sharing devices on your local network, if you don't update regularly your Windows OS, please carefully read this before allowing those connections in Comodo:

http://technet.microsoft.com/en-us/security/bulletin/MS10-061

2)

About once in 2 hours, AirVPN looses the connection and reconnects

automatically, which takes about 5 minutes.

When I click on My Computer -> Manage -> Event Viewer -> System,

I can see that during these disconnects there first is an event ID 1003

(Type: Warning) "Your computer was not able to renew its address from

the network (from the DHCP) server) for the network card with network

address

. The following error occurred: The operation was

cancelled by the user. Your computer will continue to try and obtain an

address on its own from the network address (DHCP) server"

This shows that you lost connectivity with your ISP and/or with your router. If it happens regularly every 2 hours, chances are that your ISP is losing connection regularly or that your DHCP settings on your DHCP server (typically your router) are not correct (see also DHCP lease time) and/or the DHCP settings of your ISP are grossly misconfigured.

You might like to read this:

http://www.tcpipguide.com/free/t_DHCPLeaseLifeCycleOverviewAllocationReallocationRe.htm

Kind regards

[itsmeprivately 14]

Thanks a lot for the previous help!!

As a reminder, I am using the Global Rule Method outlined here:

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

While AirVPN is connected (!), I still get some blocked Firewall Events as follows:

---- (blocked) Firewall Event from "Windows Operating System" with Protocol: IGMP, Source IP: 192.168.0.198 (= my PC) or sometimes Source IP: 192.168.0.185 (= another PC on the home network) to Destination IP: 224.0.0.22. No Ports are indicated in Comodo Firewall Events, the "port" fields in the table are blank. This event happens usually once, when a program is opened/closed. I googled and found that this might be a way for my PC (or another PC on the home network) to report its multicast group membership to the router. This seems to be legitimate traffic that stays on the home network.

---- (blocked) Firewall Event with Protocol: UDP to Destination ID: 239.255.0.1 port 9303 every 10 seconds. I googled and this might be an announcement from the D-Link wireless client on my PC, enabling the SharePort utility to find the router. This seems to be legitimate traffic that stays on the home network.

---- (blocked) Firewall Event with Protocol: UDP to Destination ID: 239.255.255.250 port 1900 every 15 minutes. I googled and this might be an announcement from the D-Link wireless client on my PC to the router for Universal Plug and Play (UPnP). This seems to be legitimate traffic that stays on the home network.

This leads to my first question:

A:

Why do these events get blocked at all? After all, AirVPN is connected, and I am using the Global Rules Method, which should allow all traffic as long as AirVPN is connected. Is the reason maybe that legitimate internet addresses only run from 0.0.0.0 to 223.255.255.255, so the above connection requests do not go to legitimate internet addresses and are therefore not going through the AirVPN server (Castor in my case)?

After some research, I learned that the above addresses are so-called "host group addresses" (range from 224.0.0.0 to 239.255.255.255). To allow this traffic (assuming it is legitimate -- is it really??), I first defined a new network zone called "Router IGMP (SharePort, UPnP, Multicast)" with the IP range 224.0.0.0 to 239.255.255.255, and then I added the following global "allow"-rule (ABOVE the "totalblock"-rule):

Allow IP In/Out From In [Home Network] To In [Router IGMP (SharePort, UPnP, Multicast)] Where Protocol Is Any

This eliminated all the above blocking events in Comodo while AirVPN is connected.

This leads to my second question:

B:

Is this safe? Or am I allowing too much traffic this way? Is this traffic even legitimate, as I assumed? Will this traffic ever leave my home network (while AirVPN is connected or disconnected)? Will this allowed traffic ever reveal my true IP address to the world (while AirVPN is connected or disconnected)?

With the above "fixed" this way, I am left with one last problem:

While mutorrent is running, I keep getting (blocked) Firewall Events from "Windows Operating System" every 2-3 seconds with Protocol: ICMP, Source IP 192.168.0.198 (= my PC), Source Port: Type(11), Destination IP: 95.211.169.3 (Castor, since I am connected to it), Destination Port: Code(1). These connection attempts are probably blocked since in the Global Rules Procedure, only TCP or UDP Protocols are allowed to Castor, not ICMP.

This leads to my third and last question:

C:

Are these ICMP events important and can/should I allow them? These blocked events every 2-3 seconds are quite annoying and clog up my Firewall Events log. Allowing them would make my logs clean. But maybe this would be allowing too much? Should I maybe allow some ICMP events but not others? How to implement this with the Global Rule Method?

Any help on questions A, B and C above is greatly appreciated!!!

[Staff 9972]

Thanks a lot for the previous help!!

As a reminder, I am using the Global Rule Method outlined here:

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

While AirVPN is connected (!), I still get some blocked Firewall Events as follows:

A:

Why do these events get blocked at all? After all, AirVPN is connected, and I am using the Global Rules Method, which should allow all traffic as long as AirVPN is connected. Is the reason maybe that legitimate internet addresses only run from 0.0.0.0 to 223.255.255.255, so the above connection requests do not go to legitimate internet addresses and are therefore not going through the AirVPN server (Castor in my case)?

Hello!

No, of course the packets of a local network from/to hosts of the network are routed inside the network itself.

After some research, I learned that the above addresses are so-called "host group addresses" (range from 224.0.0.0 to 239.255.255.255).

Exactly, see RFC 1112 http://www.ietf.org/rfc/rfc1112.txt

This leads to my second question:

B:

Is this safe? Or am I allowing too much traffic this way? Is this traffic even legitimate, as I assumed? Will this traffic ever leave my home network (while AirVPN is connected or disconnected)? Will this allowed traffic ever reveal my true IP address to the world (while AirVPN is connected or disconnected)?

Yes, it is safe, as long as all the hosts in your network are safe. It does not expose your real IP on the Internet.

Kind regards

[Jinsong 5]

Without knowing the exact details of your home network setup, it is difficult to answer these questions. However, my general advice on those unknown firewall events would be as follows: If everything on your system/network seems to be functioning perfectly normally without them, then just LEAVE THEM BLOCKED. Otherwise you run the risk of inadvertently opening up a security hole in your system.

To reduce the frequency of blocked events clogging up your log file, you should try to find out where (from what application or system process) these events are triggered from so you can just disable them altogether at the source. Disabling unnecessary Windows Services (run > services.msc) is a good place to start, and will help to cut down on a lot of this unwanted traffic and wasted resources.

For example, I have SSDP Discovery and UPnP set to DISABLED on mine, and I seem to get along just fine without them. That's where your 239.255.255.250:1900 connection attempts are spawning from. Basically, what it's doing is sending out "probes" on to see if any new devices were attached to your network (such as a network printer). If you aren't planning on adding/removing any network-shared devices anytime in the near future, then I don't see any good reason to leave this service turned on.

You may also want to go into your torrent application's settings and turn off Local Peer Discovery and/or anything else that may be contributing to unwanted firewall events (ICMP probes and such). Your torrent client only needs to have TCP/UDP traffic allowed through your Air VPN Network Zone to function correctly; everything else is unnecessary.

[itsmeprivately 14]

Thanks, admin, for the quick help!

"itsmeprivately: While mutorrent is running, I keep getting (blocked) Firewall Events from "Windows Operating System" every 2-3 seconds with Protocol: ICMP, Source IP 192.168.0.198 (= my PC), Source Port: Type(11), Destination IP: 95.211.169.3 (Castor, since I am connected to it), Destination Port: Code(1). These connection attempts are probably blocked since in the Global Rules Procedure, only TCP or UDP Protocols are allowed to Castor, not ICMP.

admin: You can safely allow also those packets. Kind regards."

Sorry if it's obvious, but how to allow those ICMP packets? Maybe one way would be, in your "Rule 10":

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

to replace "TCP or UDP" simply with "IP" (Protocol Any)?

But there probably is a reason why you wrote "TCP or UDP" in your rule, and not "IP", right? Would I then screw something up if I use "IP"? And would some of these allowed ICMP connections then not be harmful? (I'm worried about this, since Comodo had some global ICMP blocking-rules per default installed. I deleted them later since they were BELOW the totalblock-rule and thus irrelevant.). Maybe it would also be an option to change "TCP or UDP" to "IP" in your rule above, and then add the original Comodo ICMP blocking-rules just before the totalblock-rule, to make sure at least the most harmful ICMP connections are blocked?

(The default Comodo ICMP rules I'm referring to are here:

http://help.comodo.com/topic-72-1-284-3017-Global-Rules.html

)

Thanks again!

[itsmeprivately 14]

Hi Jinsong, thanks for your help on this, too!!

I played with the settings in mutorrent as you suggested ("no local peer discovery") but that did not stop the frequent ICMP connection blocking events in Comodo. Since these events happen every 2-3 seconds while mutorrent is running, they clog up the log big time. These ICMP events are now the ONLY log event happening, otherwise the Firewall Events log would be clean while AirVPN is connected.

When mutorrent is not running, the logs are now clean and stay clean. That's because the extra allow-rule for the "host group addresses" (range from 224.0.0.0 to 239.255.255.255) now allows traffic from my home network to these addresses:

(new network zone called "Host Group Addresses" with the IP range 224.0.0.0 to 239.255.255.255, and then)

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

As you say, it would be safer to determine which applications cause these events, and shut them down at the source. But, for example, I know that one of them (Destination ID: 239.255.0.1 port 9303) is the D-Link SharePort utility, and I don't know where to turn that off (it's not a service). Since it happens every 10 seconds (no matter if mutorrent is running or not), it's quite annoying to get all these Firewall blocking-events piling up. So it's easier for me to go with this extra rule. I just *REALLY* hope that, allowing traffic from my "Home Network" to the "Host Group Addresses" with this extra rule is indeed safe, and that this traffic never leaves my local network. This would entail that the "Host Group Addresses" are not actually located outside of my local network (client PCs + router), which seems to be true from what I read about it.

[Jinsong 5]

Are all of these ICMP requests outbound only?

Are they all "Code 1" (Host Unreachable)?

If so, you can probably just create a rule like this (filling in the blanks with the appropriate source/destination zones):

Allow ICMP Out From _____ To _____ Where ICMP Message Is HOST UNREACHABLE

Sorry if it's obvious, but how to allow those ICMP packets? Maybe one way would be, in your "Rule 10":

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

to replace "TCP or UDP" simply with "IP" (Protocol Any)?

But there probably is a reason why you wrote "TCP or UDP" in your rule, and not "IP", right? Would I then screw something up if I use "IP"?

I'd leave that the way it is (TCP or UDP) only, and just make a separate rule as suggested above for the ICMP traffic. "IP" encompasses more than just TCP, UDP, and ICMP protocols, so allowing all "IP" would be too permissive, IMO.

[itsmeprivately 14]

I think they are all outbound, and they are all Code(1), since they are all perfectly identical. In Firewall Events it says on each line exactly the same thing: "Application: Windows Operating System, Protocol: ICMP, Source IP: 192.168.0.198 (= my PC, so it should be outbound), Source Port: Type(11), Destination IP: 95.211.169.3 (Castor, since I am connected to it), Destination Port: Code(1).

Thanks for the tip about adding the ICMP allow rule! Could you also quickly check the link I posted in my previous message (to admin), where the original Comodo ICMP rules are listed?

So basically, you are saying, instead of *blocking* any ICMP connections that Comodo lists there (= dangerous), I should rather *allow* only the one ICMP connection that I actually get on my system (and that one is harmless, right, since it is "Code 1" (Host Unreachable))?

So then it would be:

Allow ICMP Out From [Home Network] To [Castor] Where ICMP Message Is HOST UNREACHABLE

Is this correct?

EDIT1: I just did add the above global rule, but the ICMP connections still get blocked in the Firewall Events (with the information above). How do I know if it's "In/Out" or just "Out"? The Firewall Events info just gives me the source IP and destination IP.

EDIT2: Never mind, it's "Out" (one can see this from the extended Events info). But the ICMP Type 11 code 1 is "Fragment Reassembly Time Exceeded". I added the revised allow-rule (with ICMP Time Exceeded), and now the logs are clean.

So everything seems fine. The only question is if this was safe to do. Asking for a quick confirm on this, and otherwise thanks for all the great help!!!!

[Jinsong 5]

Well, I can't say with 100% certainty that it's "safe" to allow those outbound ICMP requests, but as far as I know most ICMP traffic is relatively harmless. I'd be more curious to know WHY your torrent application is sending out all of those "Host Unreachable" requests in the first place.

If there's a legitimate reason for it, and there's no getting around it, then yes; your rule "Allow ICMP Out From [Home Network] To [Castor] Where ICMP Message Is HOST UNREACHABLE" should work fine. I would suggest making that an Application Rule rather than a Global Rule, however, since it's generally safer to make your firewall rules as precise and specific as possible.

[itsmeprivately 14]

Hi Jinsong,

there is a misunderstanding:

Type 3 code 1 is "Host Unreachable" (but that's not what I had).

I got type 11 code 1, which is "Fragment Reassembly Time Exceeded".

When making the new allow-rule, I was able to choose this from the drop-down menu

as "custom type 11 code 1", and then later when the rule was added in the table,

this shows up as "ICMP Time Exceeded".

But why I get this ICMP only when mutorrent is running? --- I have no idea!

Anyway, the new allow rule took care of this (by allowing it), and now my logs are clean.

Thanks again!

[Jinsong 5]

Hmm. I think I'm going to fall back on what I said originally, which is basically "when in doubt, block it."

Maybe those ICMP "Time Exceeded" packets are harmless, but I still don't see why they're necessary for your torrent client to function properly.

I'd consider changing that ICMP rule to BLOCK (but don't log) the requests instead. As long as you don't notice any functionality or performance issues as a result of blocking this traffic, I think that would be the safer way to go.

[itsmeprivately 14]

Thanks, Jinsong! As you say, I could also change the rule to "block" (and don't log).

I just don't know why I get these ICMP "Fragment Reassembly Time Exceeded" connections with mutorrent running in the first place, nor what they mean....

Am I really the only one who sees these? Any others here feel free to chime in!

To admin: What do you think about those ICMP "Fragment Reassembly Time Exceeded" connection attempts? Block or allow? Are they dangerous? Is it good for torrent client performance to allow them? They happen when the Global Rules Method is used while mutorrent is running, and are outgoing from Home Network to Castor.

EDIT: When looking at what Codomo considers dangerous ICMP events by default

http://help.comodo.com/topic-72-1-284-3017-Global-Rules.html

the ICMP Message 11.1 is not among them, luckily!