Noob question: Block IPv4 link-local (1000000102) and Block IPv4 link-local (1000000101)

louiannucci

Hi,

I am a very novice user and just installed pfsense 2.4.4, i was inspecting my logs to see if my basic setup was working and I keep seeing Block IPv4 link-local (1000000102) and Block IPv4 link-local (1000000101) in the system log. The 1000000102 events are from IOT devices (Phillips Hue, Amazon Alexa, etc.) while the 1000000101 events appear to be from IP addresses outside of my network. Can any one explain what these events are, and if I should allow them?

Thanks,
Lou

johnpoz

Blocking ipv4 link local, so you mean 169.254 - yeah those are APIPA address when dhcp client didn't get an IP.. Some iot devices will use them as well even when they have a IP... Not a fan myself.. My dvr bridge from directv does that.

Be a bit easier if you post screenshots of the logs so we sure of what we are seeing.

Yes a firewall is going to block some noise that many users are not really aware was there when they used their soho that doesn't show them any logs of any kind, etc. Or just scares them with stopped attack without any details, etc.

See here is that noise from my bridge.. I looked to see if anyway to turn it off at the bridge.. But I just do not log such noise.. Since that is multicast could block at my switch but just haven't got around to it as of yet... Only bugs me when doing a sniff and notice it ;)

A network be internet or lan going to have some noise. You can either turn off the noise at the client in the case of your lan network. Not log it, or live with the log spam, etc.

I don't log default blocks and just log for example syn traffic hitting my wan.. I don't care to see the noise but am curious what ports are common and how much the bots are looking 3389, 22, 23 etc. etc.

Post up some screenshots and we can discus what the stuff is and how to get rid of it.

louiannucci

Thank you

louiannucci

Here are some of my logs (I don't know how to capture them like your post). I appreciate your help.

Thank you for your response, it was very helpful. Here is a snapshot of the logs:

Oct 26 06:29:11 LAN Block IPv4 link-local (1000000102)   10.10.120.55:45526   169.254.10.6:49154 TCP:S 
Oct 26 06:29:11 LAN Block IPv4 link-local (1000000101)   169.254.10.6:53639   239.255.255.250:1900 UDP 
Oct 26 06:29:11 LAN Default deny rule IPv6 (1000000105)   [fe80::cce:339f:58cd:d82]:5353  [ff02::fb]:5353 UDP 
Oct 26 06:29:11 LAN Block IPv4 link-local (1000000101)   169.254.10.1   239.255.255.252 IGMP  
Oct 26 06:29:12 LAN Block IPv4 link-local (1000000102)   10.10.120.55:45526   169.254.10.6:49154 TCP:S 
Oct 26 06:29:12 LAN Block IPv4 link-local (1000000102)   10.10.120.29:45158   169.254.10.6:49154 TCP:S 
Oct 26 06:29:14 LAN Default deny rule IPv6 (1000000105)   [fe80::107c:5b9f:682c:a796]:5353   [ff02::fb]:5353 UDP 
Oct 26 06:29:14 LAN Block IPv4 link-local (1000000102)   10.10.120.55:45526   169.254.10.6:49154 TCP:S  
Oct 26 06:29:14 LAN Block IPv4 link-local (1000000102)   10.10.120.29:45158   169.254.10.6:49154 TCP:S  
Oct 26 06:29:17 LAN Default deny rule IPv4 (1000000103)   0.0.0.0   224.0.0.1 IGMP  
Oct 26 06:29:18 LAN Block IPv4 link-local (1000000102)   10.10.120.55:45526   169.254.10.6:49154 TCP:S  
Oct 26 06:29:18 LAN Block IPv4 link-local (1000000102)   10.10.120.29:45158   169.254.10.6:49154 TCP:S

johnpoz

Ok the top one is kind of weird.. Curious why 10.x would be trying to talk to linklocal.. that port 49154 is Xsan - take it 10.10.120.55 is a Mac OS box? You run a San??

:1900 is typical multicast SSDP noise.
5353 is mdns.. Which typical noise that is ipv6 link local sending out a mdns multicast..

What are the 10.10.120.55 and .29 boxes? the IGMP from 0.0.0.0 is odd...

But then again there was another thread where 0.0.0.0 came up - while this typical in dhcp discover.. 0.0.0.0 is also valid before link local/APIPA 169.254.x.x became popular so some devices might use that when IP has not been assigned, etc.

Nothing there I would be too worried about.. I would be curious about the 49154 xsan traffic and what is the 169.254.10.6 box.. You can do a packet capture on pfsense under diag and find the mac address of where that is being sent to help track down what actual device your 2 boxes are trying to talk to via xsan.

But I would guess its is broadcast mac if pfsense is seeing it in firewall log.. Pfsense should not have a 169.254 address..

louiannucci

Thanks for all of the info.

10.10.120.29 and 10.10.120.55 are Amazon FireTV devices, I do not run a SAN.

I will try and track down the 169.254.10.6 box.

Thanks again

johnpoz

I do not have firetv sticks - so can not check to see if they all do that sort of thing.. Have to do some research..

I have roku and roku sticks - they don't do that.. Or atleast that I have notice.. I can turn on default logging to see if they or my amazon show and dots send out any traffic like that..

I do log all outbound traffic they do that is unicast and hits the firewall. But I don't log all the nonsense multicast or link-local they might be putting on the wire ;)

louiannucci

Here is some more detail from the packet capture.

00:08:a2:::** is from ADI Engineering which I think is my NetGate Firewall. I am wondering if I have something configured wrong.

Thanks again for your help!

09:10:40.859331 00:71:47:4c:fe:04 > 00:08:a2:0d:f3:98, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 50509, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.120.29.46055 > 169.254.10.6.49154: Flags [S], cksum 0x2a48 (correct), seq 1804592184, win 65535, options [mss 1460,sackOK,TS val 40247669 ecr 0,nop,wscale 6], length 0

09:10:41.820256 50:f5:da:e0:77:2b > 00:08:a2:0d:f3:98, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 28737, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.120.55.34571 > 169.254.10.6.49154: Flags [S], cksum 0x0714 (correct), seq 1199314392, win 65535, options [mss 1460,sackOK,TS val 4810236 ecr 0,nop,wscale 6], length 0

johnpoz

No that would be right to be honest - explains why your firewall logs are seeing its actually sent to pfsense. The device says hey want to talk to 169.254 which is not my local network so send it to the gateway.. But those are link-local and don't route. They are only viable on the same layer 2...

You never know with some of these iot devices on some of the crap they might spew out or stuff that makes no sense..

I just did a sniff on my roku vlan to see what mine where sending out while getting ready for work.. No link-local nonsense - here is the only multicast seeing from them. .97-.99 are 2 sticks which wireless and 1 wired roku box..

Which is your typical ssdp discovery junk...

I could block it at the switch I guess.. But since all the roku on their own layer 2 the only devices going to see it is other roku and the firewall.. And firewall just ignores it and I make sure the firewall just doesn't log such noise.

louiannucci

Great, thanks for the info. Appreciate the help!

johnpoz

if you figure out what the point of that 49154 traffic is - please let us know. I am curious myself.

s_serra

I have a doubt. I created a machine and don't get IP by dhcp. I have other machines connected in the same way and received IP. I don't know if this is preventing the machine from receiving the IP or if my ISP's IP is probably exhausted and I have to wait until I have some available.

stephenw10

That is not preventing DHCP.

Link-local IPs are only assigned after DHCP has failed. They are non-routable and should be blocked.

Steve