Hey all.
I think I need to configure my rules to stop a false positive but I am not really sure what is going on. I keep having firewall log entries related to DNS and when I lookup the address it resolves to my ISP.
Is this only my ISP? When I called they said IPv6 isn’t supported but it works.
Is it normal to have to allow access for ISP DNS?
Generally I turn off IPv6 but I am not clear on what errors you are getting.
This is a name server for my ISP if I am not reading things incorrectly.
Is port 5353 for multicastDNS?
Yeah, if those are UDP packets with 5353 as the destination port, then they are most likely mDNS.
The IPv6 addresses that contain “ff:fe” in the middle of the last 8 bytes are publishing the MAC id of the device. Grab the three bytes before and after the ff:fe, showing that one is 02-17-88-26-7F-28.
The above means for generating an IP from the MAC is called EUI-64, see the end of this article: IPv6 Address Examples | What is an IPv6 Address? ⋆ IpCisco for a better explanation than I gave above.
There are a handful of other mechanism in use, DHCPv6 (needs a server, sort of equivalent to DHCP with v4) and SLAAC (“stateless”, each device makes up its own IP with no server needed). SLAAC looks to be the most common (as far as I can tell from my limited experience).
Oops, I always do this. The EUI-64 specifies that the first byte sometimes has bit 7 toggled (rfc4291), so actually your device MAC is 00-same as above. So, 00-17-88 prefix indicates a Philips Lighting BV manufacturer (sound right?).
ooooooooooh spooooooky
How did you decode the whole mac ID?
Take the IPv6, delete the /64 prefix (fe80::), remove the EUI-64 flag bytes ff:fe from the middle, leaving 021788267f28. Toggle bit 7 in byte 1 et voilà, 00-17-88-26-7f-28.
Edit: go to one of the MAC decoder websites and type in the first three bytes, it will show the owner of that prefix, in this case Philips.
the 02 being replaced with 00 kind of throws me
As others stated fe80::217:88ff:fe26:7f28 is the link-local address of a Philips device on your network. A link-local is an auto generated addressed based on the device’s MAC address. As it’s name suggests, this address is not routable and it’s visible only on the lan/vlan that the machines talks to.
It seams that the host (that Philips device) believes that it has IPv6 connectivity. Initially it tries a normal DNS query (port 53) to a host with the address 2001:1970:5198:8b00:2e0:edff:febc:dc3d. This host could be an interface on your router or anyone else on your network advertising a v6 prefix or responding to neighbor discovery packets (equivalent to v4 arp). Then it tries to resolve using multicast DNS IPv6 fb02::fb on port 5353 (FB02::FB is the equivalent of 224.0.0.251 in the v4 world).
This kind of behavior is normal although I find the mDNS queries quite aggressive - it could be interesting to check what this device does on v4 as well. As suggested in multiple posts/videos/etc, you should have a dedicated VLAN for your IoT devices (with or without v6).
I don’t see quite as many entries on the main page widget displays logs for anything ipv4. I do have my devices on a vLAN and it has been working well until now. I am experiencing issues running backup software across subnets.
I have a lot blocked IPV6 traffic originating on my LAN (450 entries in 6 minutes for example). Most are ICMPv6 or UDP protocol. Many have a destination of [ff02::1]. IPV6 is disabled. Are there procedures anybody can suggest to track down the source or the internal device? Many are from an internal source with ff:fe in mid-address, but not all. I extracted the mfg code but none of them are listed on the MAC lookup tools I tried.
You can use tcpdump to sniff the senders address (usually an ipv6 link local). This is constructed using the MAC address that the device is using at that particular time period. You can then use arp to discover its v4 address.
This is a multicast to all nodes, similar to broadcast in IPv4 (think ARP, not exactly, but sort of like that). If the source is an ff:fe it is likely a device assigning itself an address (SLACC) and letting all of the other nodes on the subnet know by sending to ff02::1. This is business as usual so IPv6 communication will work. If it bothers you then you can create a rule in your firewall to catch it and not log it. You may want to verify if your interface has IPv6 enabled (interfaces > LAN for example). If you are not using IPv6 then set the configuration to none.
I realized I did not answer your question with my previous response so here it goes. I would take the local address (not the mulicast) and get the MAC from it. Then I would lookup the MAC in an OUI lookup tool to get an idea of the manufacturer (not always helpful). Then I would login to Unifi and go to the clients page, add MAC as a column, and look for that MAC, assuming it wasn’t Unifi or pfSense in which case you would find it under devices in Unifi or in pfSense under diagnistics > NDP table.
EDIT: Beware of randomly generated MAC addresses.
@jpizzle and @Prntdckt What is the name of the rule that is doing the blocking in status > system logs > firewall? If you are seeing a lot in there from Default Deny Rule IPv4 or Block All IPv6 then the answer is most certainly to turn off logging for the default rules by unchecking this box.
I was curious so I fired up a test VM and by default the LAN interface IPv6 configuration type was set to track interface and RA was set to assisted in Services > DHCPv6 Server & RA> LAN > Router Advertisements. So, if you want IPv6 to work on a VLAN but not get through the firewall then unchecking the Allow IPv6 box in system > advanced > networking will do the job, but the firewall log will fill up with all of that blocked stuff unless you also uncheck the previously mentioned option to log firewall default blocks. If you really want to turn off all IPv6 then you need to set those internal interfaces to have an IPv6 configuration of none and consider disabling the route in system > routes just in case but that is a bit extreme.
I am personally happy as long as IPv6 works in a similar fashion to how I have my IPv4 rules setup and doesn’t open up any holes in my network security. I hope you found this helpful!
I have done that and about 40% of the log entries are MAC addresses track back to my two Ubiquiti AP’s. But some decode to MAC addresses that do not have a DHCP lease. I appreciate your response and suggestions.
Thanks, I have tried that and have some success tracking down devices
Are you looking in pfSense at the DHCP leases or in Unifi at the clients (in the old view click the three dots in the upper right and add a column for mac addresses)? You may see different things in these places.
With IPv4 I find the arpwatch package in pfSense great for tracking IP and MAC addresses of clients connected to my network but IPv6 doesn’t do ARP so I would need a different way (but the MAC is likely the same as long as it’s not randomly generated). If you want to get wild you could break out NMAP.
