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

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