I found the problem. I had IPv6 enabled in pfBLocker-devel 3.0.16 DNSBL: IPv6 DNSBL Enable Enable DNSBL for IPv6 DNS Resolution filtering. Default IPv6 Webserver address [ ::10.10.10.1 ] and ports [80/443] radvd was choking on the ::10.10.10.1 RDNSS line of the config file.

Just in case someone finds this hack useful, the following is the patch I used on 2.5.0. It will only do what is intended (hardcode advertised MTU to 1480) if "Use same settings as DHCPv6 server" is unchecked under the Router Advertisements configuration settings. src/etc/inc/services.inc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/etc/inc/services.inc b/src/etc/inc/services.inc index a3203aaaf7..1c63272ca1 100644 --- a/src/etc/inc/services.inc +++ b/src/etc/inc/services.inc @@ -130,7 +130,8 @@ function services_radvd_configure($blacklist = array()) { $radvdconf .= "\tAdvDefaultLifetime {$dhcpv6ifconf['raadvdefaultlifetime']};\n"; } - $mtu = get_interface_mtu($realif); + /*$mtu = get_interface_mtu($realif);*/ + $mtu = 1480; if (is_numeric($mtu)) { $radvdconf .= "\tAdvLinkMTU {$mtu};\n"; } else {

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

@starcodesystems said in IPV6 ULA LAN to WAN ISP Public IPV4 internet possible?: you have to know how to do these things Huh? Why would you need to know how do stuff that makes no sense to do? Do you have a use case example where anyone would want/need to do such a thing? Where it wouldn't make more sense to just give the device rfc1918 that you nat to your public IPv4..

I don't think its really anything to do with the AP firmware.. So I don't think they will be able to fix it.. From what a few were saying has to do with the different auth that wpa3 uses.. Not sure - have not dug that deep into yet. I was really hoping to just have guest be limited to wpa3.. But I will live with this compromise.. Just thought give you a heads up if you were doing the same thing.. And you had friends come over - and you get hey this qr code thing isn't working ;)

@gertjan Yep. He was one of my favourite things in that magazine. Incidentally, I have every paper issue of the magazine on my shelves here, going back to Vol 1, #1, Sept 1975. I bought the first three issues in person from the original publisher, Wayne Greene, at an amateur radio convention in Ottawa in 1975. He put the magazine in his wife's name for tax reasons. He then lost it when they divorced.

@fabrizior I didn’t know it was a thing :) Thanks for the information.

@jknott I didn't say reboot. I said save WAN again. Your workflow might be triggering a dhcp6c refresh, but, in general, when you make changes to inside interfaces set to "track interface" you have to save WAN again to pick them up. The dhcp6c client is the mechanism that sets all of the interface addresses. That happens when dhcp6c receives the PD. That happens on WAN. pfSense itself does not do any of that work.

Since this is the forum for IPv6 and not the forum for the Development 2.5.1-RC snapshots, you may want to re-post this over there, where the developers would be more likely to see it. https://forum.netgate.com/category/83/21-02-2-2-5-1-snapshots

I have a similar use case, namely building tenants with their own routers. Can this method (firewall rules) be used to control prefix delegation, or at least restrict access to allowed tenants? We're doing this (denying) now with IPv4, where we tell them to plug in, see the IPv4 lease request to create a static lease, after which we can create a firewall rule allowing it. Can't get the old Comcast router to give more than a /64 so I was thinking of using Hurricane to get IPv6 for the tenants.

@derelict Of course, it was one of the DHCPv6 messages. That makes a lot of sense. (I thought this was RA-related since as discussed before, the DHCPv6 mode is the only way aside from SLAAC to make pfSense pick the gateway from the RA message.) So we're back to not receiving the DHCPv6 messages at all. I added similar rules for DHCPv6 messages, and we just don't see them at all. But that's not an issue for this thread.

@bob-dig That's nonsense. First off, we shouldn't avoid IPv6, as that's what the world is moving to and the sooner the better. Also, I gave some suggestions that may help @MrGlasspoole with his problem.

@foo said in Configuring multiple routable IPv6 subnets with multiple routers: How should I have the router A, LAN A and LAN B interfaces configured to connect to router B and C? Should I use DHCPv6 or RA? Think about how you'd do it in IPv4. You set up routes to say those addresses go there. Same thing with IPv6. This is basic stuff for anyone setting up networks, whether IPv4 or IPv6.

@jimp said in RA (and therefore SLAAC) not working after updating to 2.5.0: It still looks like a settings issue. If your ISP is sending you a /56 then set the delegation size on the WAN settings to match, /56. It should slice that up into /64 chunks automatically. Holy cow, really simple to fix, if you just know what to do ;) Thank you so much, this solved the issue!

Why stop there.. While they are at - let me put a /32 on the interface.. That is the min sized prefix you get from arin ;) so you might as well let me put it on my interface - I might want to route it <rolleyes> And clearly the only way to route anything is put it on an interface..

Just like you have rule #2 preventing access to the private IPv4 range, create a rule that prevents access to your IPv6 prefix range. I'm assuming that your IPv6 prefix is static (I certainly hope it is if you have 40 VLANs). For example, if your prefix is 2001:aaaa:bbbb:cd00::/56, create a rule that prevents access to that entire address range. Now your various VLANs won't be able to communicate with each other via IPv4 or IPv6. Of course, if you use pfSense for DNS, NTP, etc., I hope you've allowed those through other rules, because that block would also prevent communication with pfSense. If you want to allow communication between two VLANs, create a single rule for both IPv4/v6, and use the "[interface] Network" selection for the destination... that will include both the IPv4 and IPv6 subnets for the VLAN that you select.

Well, with apologies for the noise level, I found a "fix" - I enabled "Do not wait for a RA" on the WAN interface, rebooted the modem and now recovery is complete without having to toggle the interface. I am stumped why this makes any difference as the modem clearly is sending out RAs after its reboot. I can see from the System logs that dhcp6 client is started without RA mode - consistent with how its now configured! :-) and sends a solicit and gets an advertise back - which then kicks the PD process off. Stu

Works here as well

Hi guys, I've followed this conversation quite a while and run into the same issue. For everyone who would like to have dynamic NPT address to solve this issue please find my repo here: https://github.com/gewuerzgurke84/pfSense-dynamicNptAddress It's tested it with 1 NPT mapping and 1 "Tracking" Interface with pfSense 2.5.0 and it solves my issue so far. Nevertheless I'd prefer to have this feature as part of the distribution itsself as it is a requirement to get IPv6 running in a reasonable way (at least in Germany)... Best Regards, Alex