Logged, but not formatted
-
I was investigating IPv6 link local traffic and wrote a rule to pass and log all link local traffic.
I was surprised to find out that at least one of the packets logged did not show up at all under the formatted output.
Can anyone explain what controls this behavior?
-
Where are you passing a link local packet to? Link local packets do not pass through routers and are usable on the local link only.
-
The rule logs and passes any packet with a IPv6 Link Local address. With a LL source address, the packet can't have a public IPv6 destination, so I can't imagine any harm with passing all link local traffic..
As you can see from the log, the firewall is not formatting the packets that go to ff02::16, which is the reason that number of records differ.
Anything addressed to ff02::/16 is a multicast packet and is received by every node on the LAN segment, including the firewall. Per IANA, this is a multicast to "All MLDv2-capable routers" per RFC 3810. MLVD is the Multicast Listener Discovery Protocol. The purpose of MLD is to enable each multicast router to learn, for each of its directly attached links, which multicast addresses and which sources have interested listeners on that link. Presumably, pfsense is a MLDv2-capable router, which might be the reason to not show this traffic (although there are about 55 internal pass rules that might match this traffic and keep this user rule from ever seeing the traffic). The raw log file though shows that the packet is being matched by the LL rule (even though the formatted entry doesn't show it).
-
The only LL packets that pfSense can see are those that pass through a pfSense interface. I know about the multicast packets for things such as router advertisements etc.. However, MLD is used to discover which devices on a local LAN want to receive specific multicasts from elsewhere, not those originating on the local LAN. For example, if your computer wants to listen to some multicast out on the net, the routers (and possibly switches) listens for the request and then arranges to get that multicast from the source and pass it on to the requesting device(es). There is no need to do this on the local network. Also, multicasts are not received by every node on the network. They are filtered by multicast MAC address in the NIC, so that if a node is not interested in a particular multicast, it doesn't hear it. This differs from IPv4 broadcasts that all devices receive. The only thing that's comparable in IPv6 is the all nodes multicast, which is received by all nodes and used for things like router advertisements. Also, that "2" in ff02 refers to the scope, in this case link local. That means a router will ignore it, as it doesn't have anything to do.
BTW, RFC 3810 has been superseded by RFC 4604.
-
The only LL packets that pfSense can see are those that pass through a pfSense interface. I know about the multicast packets for things such as router advertisements etc.. However, MLD is used to discover which devices on a local LAN want to receive specific multicasts from elsewhere, not those originating on the local LAN. For example, if your computer wants to listen to some multicast out on the net, the routers (and possibly switches) listens for the request and then arranges to get that multicast from the source and pass it on to the requesting device(es).
Agreed; all the packets logged are from potential LAN clients of a multicast stream that the pfsense router has access to. If you execute "netstat -s -s" you can see that under icmp6: has reference to "MLDv2 listener report" which am guessing means the number of listeners observed since boot.
There is no need to do this on the local network. Also, multicasts are not received by every node on the network. They are filtered by multicast MAC address in the NIC, so that if a node is not interested in a particular multicast, it doesn't hear it.
Yes, I understand and agree that multicasts are not received by every node. My understanding that the higher level IP protocols configure the Ethernet interface according to their needs to take advantage of the NICs ability to ignore Ethernet multicast traffic in hardware. The packets coming from various LL addresses on my LAN are sending to an IPv6 multicast address (ff02::16) that must be enabled by the pfsense router based upon a reserved Ethernet multicast address for MLDv2. I know how the old mapping of IPv4 multicast addresses were handled, but have not come across the equivalent method that supports IPv6 multicast addresses. IPv6 has many multicast addresses defined for LL traffic (https://www.iana.org/assignments/ipv6-multicast-addresses/link-local.csv)
This differs from IPv4 broadcasts that all devices receive. The only thing that's comparable in IPv6 is the all nodes multicast, which is received by all nodes and used for things like router advertisements. Also, that "2" in ff02 refers to the scope, in this case link local. That means a router will ignore it, as it doesn't have anything to do.
Both IPv4 and IPv6 use Ethernet multicast. IPv4 also uses Ethernet broadcast, which is not supported in IPv6, but, as you pointed out, however, if every IPv6 node enables the same Ethernet multicast address on a specific interface, then there is an effective link broadcast address. Routers will NOT repeat that traffic onto other links.
BTW, RFC 3810 has been superseded by RFC 4604.
RFC4604 is an update to RFCs 3376 and 3810 and clarifies how IGMPv3 is related to MLDPv2
And, I still am waiting to hear why there is selective filtering of logged traffic. I wonder what else is unformatted besides MLDv2 listener reports…