23.05 Update: IPv6 RIP
-
Following up on 23.01 issues with IPv6
Updated to 23.05 hoping to finally have it working. But currently I have NO IPv6 AT ALL. (because no clients inside can get a lease).
Looking at the logs I identify the firewall itself blocking dhcp6 traffic:
Each version there are more issues. I CAN add a rule to allow this traffic, but I SHOULD NOT have to, since this should be covered by the default rules.
-
@maverickws FWIW I'm not seeing this.
Pinging google.com [2607:f8b0:4009:804::200e] with 32 bytes of data: Reply from 2607:f8b0:4009:804::200e: time=26ms
-
@SteveITS what kind of setup is yours? IPv6 I mean?
I'm using Track Interface -
@maverickws DHCP on WAN, Track Interface on LAN.
-
@SteveITS same.
So I don't get it. I had IPv6 (and working) since the update, I don't get a public IPv6. Only those hits on the firewall.
Interface config did not change.
DHCP log:
-
@maverickws It's all fine over here too. Well, better than fine as the PPPoE / IPv6 issue has been resolved in this release.
I also track interface on the LAN, from DHCPv6 on the WAN.
๏ธ
-
@RobbieTT :'( I have no idea what's going wrong here.
My 23.05 update was a bit dreadful as this happened and had to wipe the disk and reinstall CE then 23.01 then restore config then update to 23.05.
All went well with the second update reinstalled all the packages the configs are all correct. Just... no IPv6.
-
-
Follow up on this issue,
I have noticed the RADVD service is stopped and fails to start.
I get the following error from the system logs:
/status_services.php: The command '/usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog' returned exit code '1', the output was '/var/etc/radvd.conf:12 error: syntax error'
The raided.conf file is an autogenerated file. How can an auto-generated file prevent the service to start? I made a backup and removed the contents of the file, it's generated with the same errors?
Line 12
# Automatically Generated, do not edit # Generated for DHCPv6 Server lan interface igb0 { AdvSendAdvert on; MinRtrAdvInterval 200; MaxRtrAdvInterval 600; AdvDefaultLifetime 1800; AdvLinkMTU 1500; AdvDefaultPreference medium; AdvManagedFlag on; AdvOtherConfigFlag on; prefix ::a0a:fefe/128 { DeprecatePrefix on; AdvOnLink on; AdvAutonomous on; AdvValidLifetime 86400; AdvPreferredLifetime 14400; }; route ::/0 { AdvRoutePreference medium; RemoveRoute on; }; RDNSS ::10.10.254.254 { AdvRDNSSLifetime 1800; }; DNSSL pt.home.net { AdvDNSSLLifetime 1800; }; };
EDIT:
Turns out that first entry which was failing was created by pfBlockerNG-devel. Removed the package and the new generated radvd.conf file seems to cause no errors:
# Automatically Generated, do not edit # Generated config for dhcp6 delegation from wan on lan interface igb0 { AdvSendAdvert on; MinRtrAdvInterval 200; MaxRtrAdvInterval 600; AdvLinkMTU 1500; AdvOtherConfigFlag on; prefix ::/64 { AdvOnLink on; AdvAutonomous on; }; DNSSL pt.home.net { AdvDNSSLLifetime 1800; }; };
However, no IPv6 either way.
-
That does look a bit odd; mine for comparison:
/root: cat /var/etc/radvd.conf # Automatically Generated, do not edit # Generated for DHCPv6 Server lan interface igc0 { AdvSendAdvert on; MinRtrAdvInterval 200; MaxRtrAdvInterval 600; AdvDefaultLifetime 1800; AdvLinkMTU 1500; AdvDefaultPreference medium; AdvManagedFlag off; AdvOtherConfigFlag on; prefix 2a02:###:####:3::/64 { DeprecatePrefix on; AdvOnLink on; AdvAutonomous on; AdvValidLifetime 86400; AdvPreferredLifetime 14400; }; route ::/0 { AdvRoutePreference medium; RemoveRoute on; }; RDNSS 2a02:###:####:#:####:####:####:70aa { AdvRDNSSLifetime 1800; }; DNSSL a######.me { AdvDNSSLLifetime 1800; }; };
๏ธ
-
@RobbieTT I don't disagree with the "odd", but again, it's an auto-generated file by pfSense. Any changes to this file are overwritten. So the oddity comes from design?
-
@maverickws said in 23.05 Update: IPv6 RIP:
@RobbieTT Any changes to this file are overwritten. So the oddity comes from design?
No, it really means that the settings are actually set via the GUI through to the pfSense configuration. You must have something inappropriately set somewhere as you are not even getting an IPv6 prefix.
๏ธ
-
- Running config without issues on 23.01;
- Backup full config;
- Update to 23.05;
- Router bricked;
- Wipe drive and reinstall CE;
- Update to 23.01;
- Restore config;
- Update to 23.05;
I really REALLY would like to know where in this scenario "I must have set something inappropriately". Since I didn't change any settings from the config that was running without issues before.
And also to put my mind at ease about the restored config, I booted back to 23.01 before the config restore and I don't get a prefix either. With a clean install, the same settings on the interface as before, which are fairly simple:
DHCP6 on WAN
(only request ipv6 prefix + send an piv6 prefix hint + do not wait for RA) the same settings that have been working forever and the same settings recommended on the ISP forums.
Track Interface on LAN
Enable DHCPv6 RA Assisted. Didn't change anything else.So, what exactly is the inappropriate setting that doesn't even allow me to get a prefix?
-
@maverickws What happens if you tick "Use non-local gateway" in your WAN_DHCP6 gateway and reboot pfsense?
-
@maverickws said in 23.05 Update: IPv6 RIP:
So, what exactly is the inappropriate setting that doesn't even allow me to get a prefix?
From here, I don't know. Clearly you did not have a smooth update path.
You did get a prefix previously though, you used to get:
prefix ::a0a:fefe/128 {
Now it only shows this:
prefix ::/64 {
I know my way around networks, routers, Linux, IPv6 etc but I am new to pfSense myself and still working my way through what is familiar and what is slightly different. Hopefully a pfSense guru will join the thread.
๏ธ
-
@Bob-Dig I don't see the point of that (but if you explain what I'm missing here I will gladly try it) what will doing that accomplish?
Because back in23.01 the workaround for the problem was precisely adding a static gateway and using it, overriding the DHCP6 provided gateway. I know what my gateway is for that IPv6 connection it is local, and with the current configuration my DHCP6 connection DOES get a gateway (fe80::etc) which is the same address from the last three years since I got this ISP and the same address I had to add as a static gateway before.
So, the non-local option will attain what? Please?
EDIT:
@RobbieTT No, not at all.
When you say "you did previously get a prefix though" please consider that that prefix caused this:/status_services.php: The command '/usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog' returned exit code '1', the output was '/var/etc/radvd.conf:12 error: syntax error'
So I do not know where that prefix came from, but I suspect it was related to pfBlocker-NG since as I removed it it went back to the ::/64 prefix.
-
EDIT
IPv6 just started working out of the blue. All of the sudden the LAN interface has an IPv6 address and clients as well and so on. I have no freakin idea of what happened but spent my last minutes replying in the forums not changing any configs really. shrug
-
@maverickws https://screenrant.com/calvin-and-hobbes-funniest-spaceman-spiff-strips/#3-point-landing
Is the /var/etc/radvd.conf different?
-
@SteveITS said in 23.05 Update: IPv6 RIP:
https://screenrant.com/calvin-and-hobbes-funniest-spaceman-spiff-strips/#3-point-landing
-
Follow-up on this,
I got the
prefix ::a0a:a01/128
line again and once again radvd fails to start.Seems to me this happens as a consequence of having Multi-WAN where both have IPv6.
Multi-WAN with IPv6 dynamic isn't possible nor I am attempting anything to put it to work, however it appears to me pfSense is handling poorly with having two IPv6 enabled connections.
The definite solution to overcome this issue was to either disable the second WAN v6 GW entirely or move from Automatic to WAN6 and reboot.
-
@maverickws Interesting. So not necessary to set "IPv6 Configuration Type" to None on WAN2? I suggest a redmine.pfsense.org entry about this. Per https://docs.netgate.com/pfsense/en/latest/recipes/multiwan-ipv6.html static IPv6 is required but I would think the WANs shouldn't step on each other, or maybe pfSense warn that two dynamic connections are set up and problems may ensue...or just disallow the second. Also if it worked in 23.01 then something changed to break it.