No DHCPv6 on internal net, radvd issue: "sendmsg: Permission denied"
-
As for Synology, it probably does not support DHCPv6 at all. QNAP for sure does not, tested here. I'd again like to point out that you should NOT use anything smaller than /64 for these purposes.
-
Sorry I forgot: I changed the subnet size to /64. It does not work either.
-Markus
-
I tried to get some usable information about what goes wrong. I started a tcpdump on the client and on the internal if of pfsense. I saw router solicitation packets from the client on both dumps-but no answer. Dhcpd was up and running. So I killed dhcpd and started it from the command line in debug mode. Seeing the RS packets in tcpdump - nothing happened in dhcpd. So I switched off the firewall via Advanced->Network/Firewall.
Now I see the RS packets, an reaction from dhcpd but no RA in dhcpd. So I think DHCPv6 Link local traffic seems o be blocked.
So I think it's a bug in the definition of the internal rules because I have an any-any-pass rule on the firewall defined.
Do you agree?-Markus
-
@ermal:
Can you put the rule with advanced option to allow ip-options?
Seems you are having fragments from the tunnel.Well, except that you'd need the above done via "default accept" rule on WAN, which just defeats the whole purpose of the firewall… Setting this on any of the internal interfaces is useless, just tested myself. Still getting flood of blocked fragmented packets with this forum, and other pfsense.org sites. :-X >:(
No go without fixing the default rules.
-
You can override the default rules through the floating rules.
First lets see if this works than lets fix the problem.So can you confirm that the issue is fixed by allowing fragments?
-
Unfortunately no - since I cannot see how to create such rule in the first place without nuking firewall functionality. Floating rule for what? Creating the rule with allowopts on LAN has no effect as the traffic gets blocked on the tunnel WAN interface. I obviously do NOT want to create "allow any" IPv6 rules on WAN.
-
Finally I solved my problem.
Disabeling the captive portal blocks dhcpv6.Background:
I use a captive portal with freeradius2 auth and accounting (for the kids) with some VIP users (my wife). Because freeradius2 has a very long startup-time on my hardware the captive portal is disabled until freeradius2 is started. In this time it worked for me. Once freeradius2 is started the captive portal stops (almost) all dhcpv6 traffic.I think this is a bug on 2.1. Where to report?
-Markus
-
CP + IPv6 is not in the 2.1 roadmap.
For 2.2 probably yes.So we know about it but not for 2.1
-
I hope so.
I wouldn't want my choices to be "IPV4 + features" or "IPV6 - features".
-
So I'd wish that CP was IPv6 aware. Even the CP doesn't support IPv6 enabeling it shouldn't break the DHCPv6 server.
At least it is worth a note on the config page.
-Markus -
Unfortunately no - since I cannot see how to create such rule in the first place without nuking firewall functionality. Floating rule for what? Creating the rule with allowopts on LAN has no effect as the traffic gets blocked on the tunnel WAN interface. I obviously do NOT want to create "allow any" IPv6 rules on WAN.
I'd really appreciate some ideas on how to prevent pf from dropping totally legit traffic…