No DHCPv6 on internal net, radvd issue: "sendmsg: Permission denied"
-
And this IPV6 ICMP….
http://imgur.com/1cgaMr5
But IPV6 is off.
-
546/547 is DHCPv6. It would go away if you enabled DHCPv6 Relay on the interface. Why is it blocked by default with the black magic in behind - no idea. For ICMP - this is all the local traffic. Allow ICMPv6 in floating rules, useless log noise gone. ICMPv6 is required for proper IPv6 working anyway.
-
OK. I plagiarized you with cut and paste… And am thinking of charging to worsen the crime.
We will see how it goes. -
well guys - that was not my main problem
Nevertheles I changed the MTU on both sides of the tunnel to 1460. So I'm behind a DSL-line with a NAT-box. So I think the MTU on line is somewhat 1500 bytes. So there are 1500bytes - 6 bytes PPPoE - 2 bytes PPP-ID 20 bytes IPv4 header size - 0 bytes 6in4 = 1472 bytes. So 1460 bytes should be fine to work without fragmentation.But my problem is that the internal DHCPv6 server and the radvd seem not to work correctly. So some time after reboot it works for 10? minutes and then all stateful IPv6-adresses are gone. I changed the RA to assisted. So my clients get stateful and statless adresses - but after powersafe on my OSX notebook all IPv6 adresses are gone. I have a IPv6 capable printer. It keeps the stateless adress but forgets about the statful. Further I have a Synology-NAS. it never gets a stateful adress but a stateless.
It seems to me that the DHCPv6-server in in combination with the radvd only work after reboot and then no RS and no RA are handled anymore.
-Markus
[EDIT] I never saw this issue: http://forum.pfsense.org/index.php/topic,59996.0.html
-
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…