In a firewall rule, what is included in "LAN net" for IPv6?



  • I was writing a firewall rule to allow, devices on my "LAN net" to send IPv6 Multicast to the router.

    When I used "LAN net", as my source, with the Link Local Multicast (ff02::/16) as the destination, the rule was not firing and my Multicast gets rejected by default. I can see in the log that the addresses being used are the link local addresses of fe80::xxxx which are to be expected.

    I changed the "source" to "any" and now the rules fires to allow it and my router is able to respond to the multicast.

    So apparently the link local addresses (fe80::xxxx) are not considered to be part of the "Lan net"?

    This is a rule you probably need to add, since a lot of the communication with the router daemon from the clients occur via multicast from link local addresses, and by default the firewall blocks that traffic.

    The only reason I was using "Lan net" as the source, was in case there was a device with an invalid address, I figured it should be rejected.


  • Rebel Alliance Developer Netgate

    It only includes the actual subnet assigned to the LAN interface.

    Using the default rules that pass to any destination with an fe80::/10 source wouldn't be right since they are not routed and can't leave their segment. You'd really only want to allow from fe80::/10 to fe80::/10 and from fe80::/10 to multicast range(s).

    The default ruleset already allows a lot of ICMP traffic to/from fe80::/10 and rules for fe80::/10 to reach DHCPv6. Since the fe80::/10 traffic can't leave the segment most often the traffic sourced from there wouldn't need to hit the firewall as it's all link-local.

    What specific traffic are you seeing blocked by default that you expect to work? Was it to a service on the firewall by default or a package?



  • @jimp What I ended up doing was a rule on the interface, that passed "any" to the link local multicast as destination. I used ff02::/16 which covers all of the Link-local multicast that I see on my net. Not sure about the other scopes yet. It would depend on what the router daemon does with them, but I would probably want to control them.

    The issue I was running into, is that clients which do not use dhcp, use the multicast to do dns, look ups, etc. and that requires "fe80" addresses as source, and also I see "::" as a source address. Almost anything android based, behaves this way, since they don't support dhcp, but I also see it some on printers.

    The router daemon is required to service those multicasts otherwise the protocol doesn't work. So I was seeing a lot of my devices falling back onto ipv4.



  • I did the same. Also for mDMS I created an extra rule.



  • @mrsunfire said in In a firewall rule, what is included in "LAN net" for IPv6?:

    I did the same. Also for mDMS I created an extra rule.

    It would probably be better, if there was a way to write a rule, that allowed multicast thru to the router daemon, which decides what to do with it, but not forward it out of the subnet. That is what I am not sure about. How to do that?

    Really the router daemon should have its head out in the subnet before the firewall, servicing all of the multicast requests. But you probably would not want that on the WAN interface.



  • Thats the same I care about. Don‘t know if my solution is good or not. Right now it seens that there is nothing routet to WAN.



  • @jimp I know it has been a bit of time, but I have found one specific type of traffic, that maybe should be allowed in the default ruleset.

    I am seeing traffic with a source address of :: (unspecified address) with a multicast to ff02::2.

    Observing on Wireshark, what I am seeing is the network device is sending a multicast asking "who is the router" using the :: address as the source. If I create a easy pass rule in pfsense, I see the router respond with a router announcement. Otherwise it is default blocked and no response from router. The router does periodically give router announcements on its own.

    I only see one device with this behavior, (Samsung TV) so not sure if this is something not normal, but it seems like it may be legal behavior.



  • @jimp I forgot to mention this is an ICMPv6 packet.

    0_1534181983305_router.PNG



  • I can confirm this. My Samsung TV is doing the same think. If you block it, it doesn't use IPv6.



  • I had kind of ignored it for a while, assuming it was a Samsung peculiarity. But I checked the RFC 4861 - Neighbor Discovery in IPv6.

    Par 4.1 Router Solicitation Message Format

    IP Fields:

      Source Address
                     An IP address assigned to the sending interface, or
                     the unspecified address if no address is assigned
                     to the sending interface.
    
      Destination Address
                     Typically the all-routers multicast address.


  • After further checking I can confirm that Windows 10 does the same thing.

    On power up, first thing it does is send icmpv6 multicast, from source address [::] to [ff02::2] (All routers on the local network segment). After that it uses its link local address as source for multicast.

    So it is not just the Samsung.


  • Rebel Alliance Developer Netgate

    Yeah reading through that RFC it does appear to need one more rule to allow from that.

    I've got a commit coming that should fix it up in 2.4.4.

    https://redmine.pfsense.org/issues/8791

    You could make a manual and more specific rule to pass it than allowing any source, though:

    0_1534423796308_Selection_047.jpg



  • @isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

    I am seeing traffic with a source address of :: (unspecified address) with a multicast to ff02::2.

    That sort of packet shouldn't even be passed by pfSense, as it's intended to be for the local link only. Check the hop limit and you'll likely find it's 255. This value is used to ensure a packet has not passed through a router, as it would have been decremented from 0 and routers are supposed to discard any packet that has a hop limit of 0. And, a source address of :: or unspecified can never be a destination address, as it's only used by a device that doesn't yet know it's own address. So, you're looking at a packet that's intended to be used on the local network only and pfSense should not attempt to forward it.



  • @jimp said in In a firewall rule, what is included in "LAN net" for IPv6?:

    I've got a commit coming that should fix it up in 2.4.4.

    Why should a router or neighbour discovery ever be passed by psSense or any other router? Those are link local only functions. I'd seriously question that passes those off the local net.


  • Rebel Alliance Developer Netgate

    @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    Why should a router or neighbour discovery ever be passed by psSense or any other router? Those are link local only functions. I'd seriously question that passes those off the local net.

    They need to be able to hit the firewall itself so the firewall can answer neighbor/router discovery queries from these clients. It's multicast so it's all local, won't leave its segment, but still valid for the firewall to pass.



  • I know why they're needed. However, I've been running IPv6 for over 8 years and this has never been an issue. I'll have to fire up Wireshark and try monitoring what happens with another computer.

    BTW, I have a Samsung Blu-ray player that no longer connects to the Internet at all. They did something absolutely brilliant. When connecting to the Internet, one of the first things the player does is try to connect to a certain web site. Can't reach the site, no connection and it stops there. However, since that was set up, that site, along with many others, switched to https, which this player cannot handle. As I said, brilliant!


  • Rebel Alliance Developer Netgate

    @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    I know why they're needed. However, I've been running IPv6 for over 8 years and this has never been an issue. I'll have to fire up Wireshark and try monitoring what happens with another computer.

    I've been running it for years as well without seeing this, but that doesn't make it invalid. It's valid per the RFC and certain (rare?) devices behave this way. There isn't a compelling reason to not allow the traffic. It won't be routed, it's only hitting the local segment.



  • @jimp said in In a firewall rule, what is included in "LAN net" for IPv6?:

    @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    I know why they're needed. However, I've been running IPv6 for over 8 years and this has never been an issue. I'll have to fire up Wireshark and try monitoring what happens with another computer.

    I've been running it for years as well without seeing this, but that doesn't make it invalid. It's valid per the RFC and certain (rare?) devices behave this way. There isn't a compelling reason to not allow the traffic. It won't be routed, it's only hitting the local segment.

    If you have been running dual stack then some ipv6 errors have been masked by falling back to IPv4.

    In my mind I should only have to define a “pass” rule to allow traffic from one subnet to another.

    The issue is that these rules are needed for services in the router to perform link local functions that are required by ipv6.

    In this case the default rules are not there to allow the router internally to implement NDP on the local net so I am manually having to create pass rules to get them into the router.



  • @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    I'll have to fire up Wireshark and try monitoring what happens with another computer.

    I just did, with another computer running Linux. The first 3 packets were:
    Neighbour solicitation for it's own link local address from ::, for duplicate address check (DAD)
    Router solicitation, with link local address as source
    Router advertisement from router to link local address.

    My question is why are those devices not doing a DAD to ensure they can use their address, as is required by the specs. Once a device passes DAD for it's link local address, it's free to use it, as shown in my test.
    If a device is not doing DAD, it's defective.



  • @isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

    If you have been running dual stack then some ipv6 errors have been masked by falling back to IPv4.

    What sort of errors? I just ran Wireshark filtering on the computer MAC address and ICMP6. No IPv4 involved at all. Incidentally, I've been running a browser add-in called "ShowIP" that shows the web site address, for years. If there was a problem, I'd have noticed it.


  • Rebel Alliance Developer Netgate

    @jknott Your tests aren't going to tell us anything meaningful about how someone else's device behaves or should behave. Only how yours behave, which is not relevant to this discussion.



  • @jimp said in In a firewall rule, what is included in "LAN net" for IPv6?:

    Your tests aren't going to tell us anything meaningful about how someone else's device behaves or should behave. Only how yours behave, which is not relevant to this discussion.

    If a device doesn't do DAD, it's defective. Those other people should be running Wireshark to see exactly what's happening. Packet Capture can also be used, but it's not as useful as Wireshark.

    I'm just getting set up to test a W10 computer, to see what happens with it.



  • @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    I'm just getting set up to test a W10 computer, to see what happens with it.

    I just tried with W10 and got the exact same sequence as with Linux. Both do DAD and then continue with the link local address. What does that other device do, as shown by Wireshark or Packet Capture? If it's trying to do a RS without having run DAD first, it's defective and has no business being on a network. If it has run DAD, then it should be doing the RS with the link local address as source.

    If this is a problem with that other device, then pfSense shouldn't be changed to fix the problem. The problem should be sent back to the company that made the device.


  • Rebel Alliance Developer Netgate

    You already missed the point here. The DAD ND solicitation in your capture mentioned in your post earlier was sourced from ::, too, so pfSense would have dropped it and not responded without this fix.

    This is valid traffic, per the RFC mentioned before and also RFC 4429 and RFC 7527. In each case, the DAD NS is sourced from the unspecified address (::) first, and it would be dropped.



  • @jimp said in In a firewall rule, what is included in "LAN net" for IPv6?:

    You already missed the point here. The DAD ND solicitation in your capture mentioned in your post earlier was sourced from ::, too, so pfSense would have dropped it and not responded without this fix.

    ????

    PfSense should have nothing to do with a DAD from another device. It's simply a check by a device to see if an IP address is in use elsewhere. PfSense or rather the IPv6 stack below it should only respond in the event of a conflict with itself. Likewise NS and RS are below the pfSense level and handled within the FreeBSD IPv6 stack, not pfSense. In fact, you should be able to run FreeBSD or any other operating system and have this work, without any application, such as pfSense, running.

    Now, take a look at the RFCs. In RFC 4861, under Neighbor Solicitation, it says:

    "Source Address
    Either an address assigned to the interface from
    which this message is sent or (if Duplicate Address
    Detection is in progress [ADDRCONF]) the
    unspecified address."

    So, no problem using :: in NS.

    Now, when we get to RFC 2461, where router solicitations are discussed we have:

    "Source Address
    An IP address assigned to the sending interface, or
    the unspecified address if no address is assigned
    to the sending interface."

    Sounds OK, but then we get to a curious situation. RAs are sent out to all nodes at interval or to a specific host, after a RS.

    In the RA section:

    "Destination Address
    Typically the Source Address of an invoking Router
    Solicitation or the all-nodes multicast address."

    But what address if the RS source is ::? That's not a valid destination address.

    So, I'd question whether there should ever be a RA in response to an RS from an unspecified address.

    Here's what Cisco says:
    When an RA is sent in response to a router solicitation, the destination address in the RA message is the unicast address of the source of the router solicitation message.

    But then we get back to what source address, if the unspecified address cannot be used?

    In my experience here, with both Linux and W10, the sequence is DAD from the unspecified address, followed by normal RS & RA using the valid link local address. Is that what's happening with that Samsung TV?


  • Rebel Alliance Developer Netgate

    @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    PfSense should have nothing to do with a DAD from another device. It's simply a check by a device to see if an IP address is in use elsewhere. PfSense or rather the IPv6 stack below it should only respond in the event of a conflict with itself. Likewise NS and RS are below the pfSense level and handled within the FreeBSD IPv6 stack, not pfSense. In fact, you should be able to run FreeBSD or any other operating system and have this work, without any application, such as pfSense, running.

    Except those packets won't make it to the stack to be processed if they are blocked by pf, hence the problem.



  • @jimp said in In a firewall rule, what is included in "LAN net" for IPv6?:

    Except those packets won't make it to the stack to be processed if they are blocked by pf, hence the problem.

    Are you suggesting pfSense is blocking ICMP to itself? That's guaranteed to break SLAAC etc..
    Can you ping the pfSense device on either IPv4 or IPv6? Does SLAAC work on your network without rules passing ICMPv6?


  • Rebel Alliance Developer Netgate

    @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    @jimp said in In a firewall rule, what is included in "LAN net" for IPv6?:

    Except those packets won't make it to the stack to be processed if they are blocked by pf, hence the problem.

    Are you suggesting pfSense is blocking ICMP to itself? That's guaranteed to break SLAAC etc..
    Can you ping the pfSense device on either IPv4 or IPv6? Does SLAAC work on your network without rules passing ICMPv6?

    That's the entire problem we've been actually discussing in this thread, which you seem to have missed entirely.

    There is a default set of rules in pfSense to pass specific ICMPv6 packets at all times, for things like ND, RA, and so on. These are in place to ensure these features function properly even without a user adding rules to pass them. These rules did not pass from a source of :: to the multicast destination. I added a rule to pass them so it will work.

    The full set of automatic default ICMPv6 rules (now)
    https://github.com/pfsense/pfsense/blob/75cf92ffe93c7ea71cd5b432c369860b6e66a0d3/src/etc/inc/filter.inc#L3309

    The change I made in response to this thread:
    https://github.com/pfsense/pfsense/commit/75cf92ffe93c7ea71cd5b432c369860b6e66a0d3#diff-84e675728564ed6deea6ee8002196c14



  • @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    @jimp said in In a firewall rule, what is included in "LAN net" for IPv6?:

    Except those packets won't make it to the stack to be processed if they are blocked by pf, hence the problem.

    Are you suggesting pfSense is blocking ICMP to itself? That's guaranteed to break SLAAC etc..
    Can you ping the pfSense device on either IPv4 or IPv6? Does SLAAC work on your network without rules passing ICMPv6?

    That is what I was observing and is the problem we are discussing.

    In my opinion, if it is an internal service within pfsense, the user should not have to write a "pass" rule just to get it to the internal service within pfsense.

    I, as a user, would not have anyway to know that it would go to pfsense only. I definitely would not want these packets to be forwarded on to other subnets because of my "pass" rule. Only the developers have this knowledge and should have it in the default rules.



  • @jimp said in In a firewall rule, what is included in "LAN net" for IPv6?:

    That's the entire problem we've been actually discussing in this thread, which you seem to have missed entirely.
    There is a default set of rules in pfSense to pass specific ICMPv6 packets at all times, for things like ND, RA, and so on. These are in place to ensure these features function properly even without a user adding rules to pass them. These rules did not pass from a source of :: to the multicast destination. I added a rule to pass them so it will work.

    As I mentioned above, I'd like to know what that TV is sending out. Does it correspond to what I'm seeing from Linux & Windows, that is DAD>RS>RA? Is that RS from :: valid? Is a router expected to send a RA when it doesn't have a valid RS source address? If so, where to? That info appears to be missing from the RFCs. I don't have the means to craft custom ICMP6 to test.



  • @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    Those other people should be running Wireshark to see exactly what's happening. Packet Capture can also be used, but it's not as useful as Wireshark.

    I just tried a capture with both. Packet Capture showed a total of 6 packets, compared to 9 with Wireshark. It also missed all 3 unspecified address DAD packets, including the one that preceded the RS. I'll have to try again after the new rules are available.

    Since it appears pfSense is also missing the DAD packets, that could cause problems on a network with multiple routers, as each pfSense router will try to have a link local address of fe80::1:1 and not see the others when it runs DAD.



  • @jknott Periodically, the Samsung will send out:

    ICMPv6 Src :: -> Dst ff02::2 Router Solicitation

    If I have aforementioned pass rule, then pfsense immediately responds with a router advertisement icmpv6 packet

    ICMPv6 Src fe80::1:1 -> Dst ff02::1 Router Advertisement

    if not pass rule, pfsense doesn't respond in a timely manner, but maybe later on its own schedule.



  • I have seen Windows 10 do the same behavior at initial start up. But you have to be looking for it.

    Samsung is more a Chatty Cathy, sort of like it has amnesia and forgets who and where it is.



  • @jknott On a related, but separate issue, I have noticed the same thing with other multicast, where pfsense should respond.

    I have the Avahi package installed, and I see that the ipv6 multicast, ff02::fb (multicast DNS) is being blocked.

    If I write a pass rule, I can see the pfsense respond with a DNS response, but otherwise it doesn't respond. So what happens then, is that the net device falls back to ipv4 multicast DNS and gets a response from pfsense via ipv4.

    IPv6 uses link local (fe80::) and multicast for a LOT of the housekeeping activities on a link, and the pfsense in some cases is not participating until I write a "pass" rule to allow link local to multicast rule.

    I would prefer not to do that since I worry that something could get passed on to other subnets inadvertently.



  • @isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

    ICMPv6 Src :: -> Dst ff02::2 Router Solicitation

    What does the source address show? You'll need Wireshark to see that. You can download the Packet Capture capture file to view it in Wireshark.



  • I just tried adding that rule and capturing the traffic as the test computer boots up. Wireshark shows the same as before, but Packet Capture now shows 14 packets captured, but none of them are DAD. Something strange is going on here. Packet Capture is running on the pfSense firewall and Wireshark on a computer connected via a managed switch, configured to mirror the traffic.



  • @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    @isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

    ICMPv6 Src :: -> Dst ff02::2 Router Solicitation

    What does the source address show? You'll need Wireshark to see that. You can download the Packet Capture capture file to view it in Wireshark.

    I am seeing on Wireshark, that the source address is ::
    it is coming from the Samsung Mac address.



  • @isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

    I am seeing on Wireshark, that the source address is ::
    it is coming from the Samsung Mac address.

    So, that brings us back to whether it's appropriate to use an unspecified address with a RS. Does it generate a RA when that rule is added? If so, what's the destination address?



  • @jknott said in In a firewall rule, what is included in "LAN net" for IPv6?:

    I just tried adding that rule and capturing the traffic as the test computer boots up. Wireshark shows the same as before, but Packet Capture now shows 14 packets captured, but none of them are DAD. Something strange is going on here. Packet Capture is running on the pfSense firewall and Wireshark on a computer connected via a managed switch, configured to mirror the traffic.

    What I use for testing, is a "pass" rule, IPv6 "any" to "ff02::0/16"

    Then if you use Wireshark, you will see pfsense participating more on the link.

    When you disable the rule, not so much pfsense. Also, a lot of the traffic gets repeated, trying to find the router.

    0_1534447853534_2018-08-16 (1).png



  • @isaacfl said in In a firewall rule, what is included in "LAN net" for IPv6?:

    ff02::0/16

    I am getting more, just not the DAD. BTW, there's no difference between ff02::/16 and ff02::0/16. The :: simply means a string of 0 bits in the area specified.

    When pfSense is updated to include the rule, they should test to make sure it is working properly. There shouldn't be any difference between PC and Wireshark.