DHCPv6 traffic blocked on LAN with DHCPv6 relay enabled
-
@5 block drop in log inet6 all label "Default deny rule IPv6"
-
OK, yeah it appears as though the code to put in the auto rules just doesn't check if relay is enabled.
DHCPv6 relay is a bit of an afterthought, it was only worked on recently and I'm not sure anyone had a working environment to properly test it against.
It probably just needs an extra bit on that if statement to check about the status of dhcp relay.
-
Try this.
diff --git a/etc/inc/filter.inc b/etc/inc/filter.inc index 1db82a3..848111a 100644 --- a/etc/inc/filter.inc +++ b/etc/inc/filter.inc @@ -2743,7 +2743,8 @@ EOD; } break; default: - if ((is_array($config['dhcpdv6'][$on]) && isset($config['dhcpdv6'][$on]['enable'])) || isset($oc['track6-interface'])) { + if ((is_array($config['dhcpdv6'][$on]) && isset($config['dhcpdv6'][$on]['enable'])) || isset($oc['track6-interface']) + || (is_array($config['dhcrelay6']) && !empty($config['dhcrelay6']['interface']) && in_array($on, explode(',', $config['dhcrelay6']['interface'])))) { $ipfrules .= << <eod<br># allow access to DHCPv6 server on {$oc['descr']} # We need inet6 icmp for stateless autoconfig and dhcpv6</eod<br>
-
Yes, that fixed the problem. 8)
-
I saw a similar issue with prefix delegation (see issue 3028): Even though a dhcpd6 instance gets started on the tracking interface, no rules get added to actually allow DPCH6 traffic in on that interface. Would that be related?
-
I saw a similar issue with prefix delegation (see issue 3028): Even though a dhcpd6 instance gets started on the tracking interface, no rules get added to actually allow DPCH6 traffic in on that interface. Would that be related?
Don't think so… looks allowed just fine looking at the code in filter.inc.
if ((is_array($config['dhcpdv6'][$on]) && isset($config['dhcpdv6'][$on]['enable'])) || isset($oc['track6-interface'])
-
Dunno, all I know is it's not actually generating any rules for DHCP6 traffic on my LAN interface. The only DHCP6-related rules that I see are the following (all on WAN):
# allow our DHCPv6 client out to the WAN pass in quick on $WAN proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 label "allow dhcpv6 client in WAN" pass in quick on $WAN proto udp from any port = 547 to any port = 546 label "allow dhcpv6 client in WAN" pass out quick on $WAN proto udp from any port = 546 to any port = 547 label "allow dhcpv6 client out WAN"
-
Actually, looking at filter.inc, the last assignment in the following fragment seems a bit odd:
if(!is_ipaddrv4($oc['ipaddr']) && !empty($oc['ipaddr'])) $oic['type'] = $oc['ipaddr']; if(!is_ipaddrv6($oc['ipaddrv6']) && !empty($oc['ipaddrv6'])) $oic['type6'] = $oc['ipaddrv6']; if (!empty($oc['track6-interface'])) $oc['track6-interface'] = $oc['track6-interface'];
Note that the source and destination of the last assignment are identical ($oc); it seems like the destination should be $oic as in the preceding two assignments.
-
Actually, I think this might explain why the rules are not generated: Because the destination is 'oc' and not 'oic', FilterIfList never gets a 'track6-interface' entry, and so the if statement you quoted earlier would never see 'track6-interface' either.
-
Frankly, I am wondering if this black magic behind the scenes brings any significant benefit for non-WAN interfaces.