IPv4 Rule added, Firewall still blocking
-
Trying to find the solution for this firewall alert. Ive added the firewall using the Easy Rule but no bueno. Is there a system setting overriding this? Notice no traffic going through the rule and transactions are still pilling up in the firewall log for this specific traffic. It's unifi traffic but I'm not sure what it's attempting. this range is defined as Automatic Private IP address meaning there's a network visibility related issue obviously but beyond that I'm in the dark.
-
That is a APIPA address, and its a ssdp multicast - pfsense isn't going to do anything with that.. I would search what device is spewing out that noise and stop it at the source.
169.254 address are normally devices that are set for dhcp, but don't get an IP from the dhcp server.
-
roger, thank you sir
-
Also where exactly in your rule set is the rule you added. Post up your full rule set of your interface.
If the goal is to not log those entries then a rule that doesn't log be it allow or deny in the proper location would prevent those from showing in the log.
Rule are evaluated top down, first rule to trigger wins, no other rules are evaluated. Also you added a specific IP.. APIPA address can change all the time, so you sure the entries you are seeing in the log is just not a different 169.254.x.x address?
-
checking again this morning I see the same logging.
-
The rule that is blocking that is the link-local rule, not your default block rule..
Those are blocked by hidden rules way up in the list, before your rules are evaluated
you can view them with pfctl -sr
block drop in quick inet from 169.254.0.0/16 to any label "Block IPv4 link-local" block drop in quick inet from any to 169.254.0.0/16 label "Block IPv4 link-local"You can turn those off in advanced, firewall & nat
Just do a filter reload after checking that box.. Then look in your rules again with the pfctl -sr to make sure they are gone.
Sorry didn't notice exactly what rule was blocking that in your first post.
But again - prob best to try and turn off the generation of that noise at the device.. Do you know what device is sending that traffic? You can sniff on that interface to find the mac address of the device sending it, help you identify what it is.
That 172.16.1.15 is sending to 169.254? Yeah this is junk ;) Stupid devices!!
-
will do thank you very much, awesome advice! . I think its either Ring or Unifi, I will do a sniff and check back in.
-
What unifi device? A camera?
I have some shit devices that send out noise, directv devices loves to spew 169.254 multicast discovery nonsense.. I just block it at its switch port ;) with an acl. So it never actually enters the network at all, let alone reach pfsense.
The plex software on nas also does dlna discovery nonsense, even when you disable it - also blocked at the switch port..
If you can not turn it off at the device, if your switching allows for ACLs, you could prob stop it from actually entering the network.. Or if via wireless, block it from entering your network at the AP switch port.
-
yes it has to be a crap device because that's all i have on that network. I did enable the APIPA but still broadcasting. I'm fine with supressing this alert if possible rather than wasting time on it. Everything seems to be working fine on that network regardless. I just cant find what is sending this out. I could disconnect 1 device at a time or perhaps wireshark ?
09:07:49.199537 IP 169.254.161.196.50759 > 239.255.255.250.1900: UDP, length 155
09:07:53.413804 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 380
09:07:53.510319 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 364
09:07:53.631861 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 321
09:07:53.773669 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 312
09:07:53.872557 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 380
09:07:53.992901 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 364
09:07:54.132317 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 321
09:07:54.221984 IP 169.254.161.196.50759 > 239.255.255.250.1900: UDP, length 155
09:07:54.234791 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 312
09:07:54.355145 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 380
09:07:54.492174 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 364
09:07:54.595838 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 321
09:07:54.716179 IP 169.254.161.196.1900 > 239.255.255.250.1900: UDP, length 312
09:07:59.202412 IP 169.254.161.196.50759 > 239.255.255.250.1900: UDP, length 155
09:08:11.201464 IP 169.254.161.196.50759 > 239.255.255.250.1900: UDP, length 155
09:08:16.203651 IP 169.254.161.196.50759 > 239.255.255.250.1900: UDP, length 155
09:08:21.212996 IP 169.254.161.196.50759 > 239.255.255.250.1900: UDP, length 155
09:08:33.202489 IP 169.254.161.196.50759 > 239.255.255.250.1900: UDP, length 155
09:08:38.207356 IP 169.254.161.196.50759 > 239.255.255.250.1900: UDP, length 155
-
open the sniff you did on pfsense in wireshark, or up the verbosity so you can see the mac of the device.. Then can track which device it via its mac address, atleast look up what device maker it is..
-
@johnpoz looks like a TV to me. could be the comcast set top box.
OPT1 172.16.1.17 64:12:36:9c:95:f9 Technicolor CH USA Inc. Tue Oct 13 08:55:13 2020
169.254.161.196.50759 > 239.255.255.250.1900: [udp sum ok] UDP, length 155
09:19:16.218208 64:12:36:9c:95:f9 > 01:00:5e:7f:ff:fa, ethertype IPv4 (0x0800), length 197: (tos 0x0, ttl 4, id 16039, offset 0, flags [DF], proto UDP (17), length 183)
kinda odd, this mac has two ips and they are both active. They are connected to a r7500v2 netgear AP.
OPT1 172.16.1.21 64:12:36:9c:95:f9 Technicolor CH USA Inc. Tue Oct 13 09:06:24 2020
OPT1 172.16.1.17 64:12:36:9c:95:f9 Technicolor CH USA Inc. Tue Oct 13 08:55:13 2020 -
Yeah that is odd.. I take it connected wifi - is it some how connected to both 2.4 and 5 at the same time?
Have you tried restarting it, and see if some of the noise resides.. Do you have it IP setup static?
Hmmm - could it have gotten a lease, and then never actually stop using the IP, and then did a discover to get an other IP? do you or did you run more than 1 dhcp server on the same network..
That is odd.. Can you reset the network settings on the device?
-
@johnpoz Yeah, I disconnected it and cleared both leases and powered it back on. Only have 1 IP now and UDP 1900 traffic has stopped. Somehow it was mucked up but I am going to check the wifi settings. It's set to DHCP on wifi. it's one of those trash x1 tv boxes that came with my internet package. I barely use it.
-
@johnpoz said in IPv4 Rule added, Firewall still blocking:
What unifi device? A camera?
I have some shit devices that send out noise, directv devices loves to spew 169.254 multicast discovery nonsense.. I just block it at its switch port ;) with an acl. So it never actually enters the network at all, let alone reach pfsense.
The plex software on nas also does dlna discovery nonsense, even when you disable it - also blocked at the switch port..
If you can not turn it off at the device, if your switching allows for ACLs, you could prob stop it from actually entering the network.. Or if via wireless, block it from entering your network at the AP switch port.
@johnpoz - don't mean to hijack this thread, but just wanted to say thank you for the advice. I have a TV STB that has been spamming my firewall logs with 169.254.x.x. nonsense for over three years now (probably trying to look for other STB's). I never thought about setting up an ACL rule on the switch to block that traffic at the port level. Firewall logs look a lot cleaner now :).
-
Glad it was helpful - that is the really the whole point of discussions vs just blanket Q:A sort of threads... You never know what what kind of great info you can glean from just discussing a specific issue..
Much rather the question kicks off a discussion on what doing, how doing it, what would you like to do exactly.. How else to skin the cat vs just
Q: How do I do X
A: Click hereX might not be the right way to do it in the first place, and 2nd discussing X might expose all kinds of other things that you can like Y and Z.. that the asking of X kicked off.
-
@johnpoz yessir, thanks for your help!
