Router Advertisements (revisited)
-
Now seems like as good a time as any to reiterate the need for a page devoted completely to Router Advertisement configuration. My personal suggestion is to put it under the Services drop-down and tab the page for individual interface configuration. I realize it will need to tie in (to some degree) to the DHCPv6 Server page, but a checkbox on the latter reading Allow Router Advertisement configuration to override these settings or Use RA Configuration should suffice. At the very least, have an Advanced RA Configuration section on the DHCPv6 Server page that only expands or becomes visible/configurable when the Advanced RA Configuration box is checked.
Here is what I know is in need of repair as it stands. I can't turn RAs off on any interfaces as I mentioned in a previous post. I just realized recently that RAs are getting transmitted over HE and SixXS tunnels as well as the LANs. So far, no complaints on their end (you never know with SixXS, though) and maybe there never will be since I doubt seriously the RAs are making it past the far endpoint. The only interface that is immune is the IPv4 WAN. No configuration is ever generated for it in the rtadvd.conf.
And that brings me to the other rtadvd.conf problem. The DNS server address that is sent in the RA for every interface save the WAN is always that of the last configured interface. If I have two LANs, for instance, the pfSense interface addresses of which are fd00:ac10::65 (LAN1) and fd00:ac10:100::65 (LAN2), and RA is set to Managed on both interfaces in the order mentioned, fd00:ac10:100::65 will be included as the DNS server address in the RA on both interfaces/LANs. If I disable RA on LAN2, nothing changes. If I then disable RA on LAN1, still nothing changes. Now, both LANs have RA disabled; I set RA to Managed on LAN1. The DNS server address in the RA is still the address of the LAN2 interface.
I know neither of these examples is the desired behavior, but what is? This is going to vary by user, network, application, etc., which is why I'm advocating finer configuration options. In my case, I only want RAs on specific interfaces and if I wanted DNS servers advertised with the RA instead of DHCPv6, I would prefer that the address sent in the RA on LAN1 was that of the interface on LAN1 and likewise for LAN2. What I'd really prefer, however, is not to advertise DNS addresses in the RA at all; I'm using DHCPv6 for that and my DNS servers are separate machines which list the pfSense boxes as forwarders (convenient when they in turn forward to DNS servers provided by upstream DHCP). But that's what I want for my network. The next guy will want something else.
Since it seems like there are a few things to fix and a few others still to consider in light of this, now would be the ideal time for discussion about how best to implement RA configuration. Of all the puzzle pieces involved with setting up a functioning IPv6 network, getting the proper RA on the proper networks is the only remaining hurdle for me.
In the meantime, are there any workarounds?
-
I tried blocking outbound RAs on em1 with a floating rule, but
pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"
appears before and thus trumps
block drop out log quick on em1 inet6 proto ipv6-icmp all icmp6-type routeradv.
Any way around this?
-
Is there no way to (for the time being) block RAs on certain interfaces?
-
The rule you mentioned does not have the "quick" keyword on it, so any rules below it should be able to override it.
-
Okay. But the rule generated by my configuration
block drop out log quick on em1 inet6 proto ipv6-icmp all icmp6-type routeradv
is not blocking router advertisements on em1. So what is wrong?
-
Maybe I need clarification on rule order. According to http://doc.pfsense.org/index.php/Firewall_Rule_Basics, the first rule matched wins, which jibes with my dilemma and is the basis for my thinking the autogenerated rule was overriding my rule. But according to http://openbsd.org/faq/pf/filter.html, it's the last rule matched that wins, which (a) agrees with what Efonne is saying, (b) makes sense in light of the quick keyword function, and
makes the most sense to me. Yet, if the latter is the case, why isn't my rule working? -
Have you tried making the rule more general to see if you can get it to block? Are you logging the block?
You could hand edit /tmp/rules.debug and move it above the other, then pfctl -f /tmp/rules.debug and see if it behaves differently.
What you are saying about rule order is essentially right.
The rules on our interface tabs are always first-match-wins, because they all have 'quick' set. Rules on the floating tab can work either way (depending on whether or not you have 'quick' checked on the floating rule). Some of our internal rules do not have 'quick' set so they can be overridden by user rules.
-
I changed the rule to read
block drop out log on em1 inet6 all
with no effect. This time, though, I paid closer attention to the output of pfctl -s rules. The offending autogenerated rule is not the one I mentioned, but instead is
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state.
How do I get around this one?
-
There probably isn't a way around that if it's above the user rules. databeestje will probably have to comment on that one, I don't know if there is an option or bypass for it.
-
I edited /tmp/rules.debug and removed quick from this line:
pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} keep state.
This solved my problem, but I don't know if any other rules further down (other than mine) will override this one now. I don't see any, but I haven't exactly studied the file. How do I make this edit persistent (assuming nothing else is broken as a result of the change). It is, after all, just a rig until router advertisements are fixed.
-
Edit the line in /etc/inc/filter.inc
https://github.com/bsdperimeter/pfsense/blob/master/etc/inc/filter.inc#L2286
-
I made this change and now have the desired functionality. Actually, I changed the line following the one highlighted at https://github.com/bsdperimeter/pfsense/blob/master/etc/inc/filter.inc#L2286 because it is the one causing me problems. Now that it's blocking and logging, I can confirm beyond a shadow of doubt that RAs are being sent down the gif tunnels too when not blocked. Thanks for the assistance! Now, I think I'll tinker with fixing the RAs. :)
