Firewall blocking too much?
-
I'm seeing some traffic being caught in the default "block all" rule, which I assume is comming from torrent traffic. Shouldn't such traffic be caught by the firewall's state tracker?
Also I'm seeing some odd ICMP pings comming in from outside, targeting an internal (192.168.1.x) address, which I assume is only possible if the source of the packets is specially creating the packets? To go along with that, I've had to explicitly allow ICMP traffic so he.net ipv6 tunnels work, but I've set it so the rule only allows ICMPs targeted at the WAN address, but its still allowing ICMP targeting internal addresses, I've also tried adding a specific block rule for ICMP targeting internall addresses from the outside, and the firewall log is still saying the ICMP Allow rule is catching it, even though the block rule is above it.
-
screenshots of blocks and of firewall rules please.
-
screenshots of blocks and of firewall rules please.
Firewall log: (the blocked TCP and UDP traffic looks like it aught to be ok, but I can't be sure, and the allowed ICMP traffic is very strange, particularly the ones with a local dest)
Wan Rules:
-
do you have any NAT rules setup?
do you have private IP addresses blocked in the WAN interface? -
@sai:
do you have any NAT rules setup?
do you have private IP addresses blocked in the WAN interface?Yes and yes.
The private address thats being sent ICMP packets never has existed on my lan, and private addresses are blocked using those checkboxes labeled "block private networks" and "block bogon networks" on the WAN interfaces page.
-
if you click on the green icon in the logs, it will tell you which rule is letting it through. I would guess it is the one labeled "icmp allow"
-
@sai:
if you click on the green icon in the logs, it will tell you which rule is letting it through. I would guess it is the one labeled "icmp allow"
Right. That is the one that pfsense thinks is letting the rule through, but not only should it not be letting it through, an earlier rule should be blocking it first.
-
the previous rule will only block packets going to LANnet. I guess your lan net is not 192.168.1.0/24 so that is why the packets are not blocked.
-
@sai:
the previous rule will only block packets going to LANnet. I guess your lan net is not 192.168.1.0/24 so that is why the packets are not blocked.
It is indeed 192.168.1.0/24. And the rule allowing ICMP specifically only allows ICMP traffic NOT targeting LANnet, so the first rule should be blocking it, and the second shouldn't be allowing it.
-
can you show us your NAT rules and interfaces page?
-
Tomasu, try this:
Switch the order of your two icmp rules. Place your "logged, allow icmp rule" above your "logged, block icmp rule" and see if that does this trick. Good luck! :)
ps (do you have any Virtual ip's, carp ip's, or 1:1 NAT items setup? Let us know because I am wondering how the allowed icmp rule know to go directly to your 192.168.1.102 ip address instead of just listing your normal, WAN ip address. More specifically, does 192.168.1.102 have a WAN ip of something other than 68.149.45.164? )
-
Tomasu, try this:
Switch the order of your two icmp rules. Place your "logged, allow icmp rule" above your "logged, block icmp rule" and see if that does this trick. Good luck! :)
I'll get back to you on this…
ps (do you have any Virtual ip's, carp ip's, or 1:1 NAT items setup? Let us know because I am wondering how the allowed icmp rule know to go directly to your 192.168.1.102 ip address instead of just listing your normal, WAN ip address. More specifically, does 192.168.1.102 have a WAN ip of something other than 68.149.45.164? )
192.168.1.102 does not exist. Never has as far as I know. My dynamic dhcp pool starts allocating from 199 and goes down to 100, and I'm currently only seeing 192.168.1.17x ips so far (mainly for Virtual Machines with random'ish mac addresses) I also have no Virtual IPs, no carp IPs, or 1:1 NAT items.
The icmp just should not be getting through at all. The allow rule explicitly states only ICMP not targeting a LAN address should get through, and the explict deny rule should further block it. the extra block rule was added after I noticed the allow rule allowing local dest icmps through even when told not to.
Not to mention the packets getting blocked when they could be valid bittorrent traffic (not sure on this one, its hard to test when pfsense lacks all the useful packet sniffing tools that I'm used to).
-
Interesting… If you don't mind, could you post you WAN ip info and LAN ip info of your pfsense box? Block out the necessary items in the WAN ip as needed. Just to be sure, your WAN ip is gotten via DHCP from your ISP, correct?
Another item: Are you using pfsense 1.2 or an older version?
-
Interesting… If you don't mind, could you post you WAN ip info and LAN ip info of your pfsense box? Block out the necessary items in the WAN ip as needed. Just to be sure, your WAN ip is gotten via DHCP from your ISP, correct?
Another item: Are you using pfsense 1.2 or an older version?
I'm using 1.2. And yes I get DHCP from my isp.
-
Thanks for supplying the interfaces screenshot. Several different items and thoughts:
I would like to see the subnet mask of your WAN ip if you don't mind. I am still intrigued as to which machine on your lan is the 192.168.1.102 computer that showed up in the logs. Could be a random machine that had that ip address at that time. The reason I asked if you had any virtual/public ip's is because normally, when items in the firewall get blocked on the WAN side, they should only be showing the WAN ip address, as they are in the other types of items being blocked. Internal ip addresses show in the logs when those internal addresses are matched up with 1:1 NAT public ip's (at least from all the setups I have performed and seen).
Another item, unless needed for the specific application you mentioned in your first post regarding that "he.net ipv6 tunnels work", you could delete the two ICMP rules and just use the following:
Allow - ICMP - * - WAN ADDRESS - * - *
That way, you'd be allowing ping replies to your 64.149.45.164 ip address, and by default, all ICMP requests to your internal LAN would be blocked by default. Of course, for logging purposes, that is when you need to create the additional rules. So basically, I am saying, get rid of the rule that says ALLOW ICMP to !LAN net, and replace it with what I have mentioned above.
Could you post your latest firewall log so we could see the ip's whose ICMP packets are still making it through? I am interested if it is still coming from the same ip, or from somewhere else.
Thanks
-
Thanks for supplying the interfaces screenshot. Several different items and thoughts:
I would like to see the subnet mask of your WAN ip if you don't mind.
255.255.252.0
I am still intrigued as to which machine on your lan is the 192.168.1.102 computer that showed up in the logs. Could be a random machine that had that ip address at that time.
Doesn't has hasn't existed. My network has a total of 5 PC style devices, a Wii, a Linksys PAP2, a wireless router (behind the firewal), and 4 Virtual Machines. Most are using known static DHCP addresses (all under 100 or over 200).
Another item, unless needed for the specific application you mentioned in your first post regarding that "he.net ipv6 tunnels work", you could delete the two ICMP rules and just use the following:
Allow - ICMP - * - WAN ADDRESS - * - *
That way, you'd be allowing ping replies to your 64.149.45.164 ip address, and by default, all ICMP requests to your internal LAN would be blocked by default. Of course, for logging purposes, that is when you need to create the additional rules. So basically, I am saying, get rid of the rule that says ALLOW ICMP to !LAN net, and replace it with what I have mentioned above.
I've changed to that rule, though my current log doesn't show any ICMPs, its only 150 entries, it fills up fairly fast.
Could you post your latest firewall log so we could see the ip's whose ICMP packets are still making it through? I am interested if it is still coming from the same ip, or from somewhere else.
Thanks
Heres what I've managed to grep out of /var/log/filter.log
# cat /var/log/filter.log | grep ICMP May 20 09:46:45 boris pf: 016836 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 50, id 47337, offset 0, flags [DF], proto: ICMP (1), length: 56) 91.153.102.36 > 68.149.45.164: [|icmp] May 20 09:48:58 boris pf: 466091 rule 1202/0(match): pass in on dc0: (tos 0x0, ttl 119, id 26923, offset 0, flags [none], proto: ICMP (1), length: 111) 209.148.138.5 > 68.149.45.164: [|icmp] May 20 09:49:01 boris pf: 122975 rule 1202/0(match): pass in on dc0: (tos 0x0, ttl 119, id 38233, offset 0, flags [none], proto: ICMP (1), length: 111) 209.148.138.5 > 68.149.45.164: [|icmp] May 20 09:50:55 boris pf: 1\. 066297 rule 1202/0(match): pass in on dc0: (tos 0x0, ttl 117, id 18329, offset 0, flags [none], proto: ICMP (1), length: 61) 58.121.16.66 > 68.149.45.164: ICMP echo request, id 512, seq 47325, length 41 May 20 09:14:58 boris pf: 230275 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 116, id 51379, offset 0, flags [none], proto: ICMP (1), length: 61) 211.213.206.64 > 68.149.45.164: ICMP echo request, id 512, seq 58905, length 41 May 20 09:18:33 boris pf: 104160 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 125, id 23272, offset 0, flags [none], proto: ICMP (1), length: 92) 68.149.8.89 > 68.149.45.164: ICMP echo request, id 512, seq 30253, length 72 May 20 09:20:15 boris pf: 3\. 626664 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 110, id 9998, offset 0, flags [none], proto: ICMP (1), length: 61) 83.7.216.207 > 68.149.45.164: ICMP echo request, id 1024, seq 61797, length 41 May 20 09:23:52 boris pf: 5\. 597584 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 236, id 49267, offset 0, flags [DF], proto: ICMP (1), length: 56) 62.176.117.138 > 68.149.45.164: ICMP host 192.168.1.4 unreachable, length 36 May 20 09:27:14 boris pf: 1\. 568594 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 50, id 27221, offset 0, flags [DF], proto: ICMP (1), length: 56) 91.153.102.36 > 68.149.45.164: [|icmp] May 20 09:28:51 boris pf: 6\. 111734 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 125, id 19116, offset 0, flags [none], proto: ICMP (1), length: 92) 68.149.15.21 > 68.149.45.164: ICMP echo request, id 512, seq 26477, length 72 May 20 09:30:37 boris pf: 2\. 523891 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 52, id 30261, offset 0, flags [none], proto: ICMP (1), length: 64) 208.78.169.236 > 68.149.45.164: ICMP echo request, id 10321, seq 0, length 44 May 20 09:32:19 boris pf: 9\. 605654 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 50, id 1193, offset 0, flags [DF], proto: ICMP (1), length: 56) 91.153.102.36 > 68.149.45.164: [|icmp] May 20 09:33:53 boris pf: 698602 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 56, id 39735, offset 0, flags [none], proto: ICMP (1), length: 64) 204.11.51.62 > 68.149.45.164: ICMP echo request, id 45903, seq 0, length 44 May 20 09:37:14 boris pf: 3\. 677497 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 50, id 63911, offset 0, flags [DF], proto: ICMP (1), length: 56) 91.153.102.36 > 68.149.45.164: [|icmp] May 20 09:39:00 boris pf: 3\. 856077 rule 1203/0(match): pass in on dc0: (tos 0x0, ttl 123, id 14688, offset 0, flags [none], proto: ICMP (1), length: 92) 68.147.179.35 > 68.149.45.164: ICMP echo request, id 512, seq 30961, length 72 ```So it seems its not happened in the past 10-20 minutes or so. And the file is getting shorter as I "cat file | wc -l" it every couple of seconds, so I cant check further back. -
For the silly question now:
Is this issue you're having showing up anywhere else besides in the logs? Can you replicate it in any other fashion?
-
So it seems its not happened in the past 10-20 minutes or so. And the file is getting shorter as I "cat file | wc -l" it every couple of seconds, so I cant check further back.
One thing to do is turn off the setting that says: "Log packets blocked by the default rule"
That way, the firewall logs will only show what you tell it to log. To get to that setting, go to:
System Logs: Settings
It should be the second option at the top.
-
For the silly question now:
Is this issue you're having showing up anywhere else besides in the logs? Can you replicate it in any other fashion?
How can it show up anywhere else? Somoene from the outside was sending icmp packets to an internal address that doesn't exist, something I assume you can't do normally unless you're intending to do something malicious. I don't even know how to do that myself. Heck, I don't even know how to write a program to send an ICMP packet (can only do TCP and UDP using bsd socket api myself).
As for the other problem, its probably just random botnets trying to find bots, but at one point it looked like BitTorrent traffic being blocked. I'm getting a few blocks a minute from a few places. I've already changed the rule to only allow WAN api ICMPs…
So it seems its not happened in the past 10-20 minutes or so. And the file is getting shorter as I "cat file | wc -l" it every couple of seconds, so I cant check further back.
One thing to do is turn off the setting that says: "Log packets blocked by the default rule"
That way, the firewall logs will only show what you tell it to log. To get to that setting, go to:
System Logs: Settings
It should be the second option at the top.
Yeah, though if theres ever a problem with that, I'll never see it ;) I'll turn it off for now though.
EDIT:
Heres a couple new logs with ICMP traffic:
May 20 10:21:44 boris pf: 71\. 398252 rule 1202/0(match): pass in on dc0: (tos 0x0, ttl 115, id 52197, offset 0, flags [none], proto: ICMP (1), length: 61) 59.61.163.192 > 68.149.45.164: ICMP echo request, id 1024, seq 10483, length 41 May 20 10:24:56 boris pf: 13\. 777140 rule 1202/0(match): pass in on dc0: (tos 0xc0, ttl 244, id 62072, offset 0, flags [none], proto: ICMP (1), length: 88) 118.100.198.209 > 68.149.45.164: ICMP host 192.168.0.8 unreachable, length 68 ```Now its a non LAN address thats being let in, but not forwarded because the address isnt used (or routed on my network) -
the only strange thing in your setup is the 192.168.1.1 as dns in general settings. even that should not let in the icmp…
this is really weird.
you said that there were some NAT rule. can we see those?
