Hi,
This problem may be related to https://forum.opnsense.org/index.php?topic=41508.0 but my problems appear slightly different.
After the update to 24.1.10 I rebooted and everything appeared fine. After 30 minutes (first IPv6 renewal) I seemed to loose IPv6 connectivity. Logs showed dhcp6c sending RENEW and then SOLICIT messages. When trying to diagnose this I could see the packets were being allowed out - checked with
$ sudo tcpdump -ve -i pflog0 udp port 546 or udp port 547
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes
21:37:43.196073 rule 105/0(match) [uid 0]: pass out on igb0: (hlim 1, next-header UDP (17) payload length: 89) fe80::2e0:xxx.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x29e8 -> 0x1be3!] dhcp6 solicit (xid=2feda3 (client-ID hwaddr/time type 1 time xx xx) (elapsed-time 65535) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/56 pltime:4294967295 vltime:4294967295)))
21:39:35.293493 rule 105/0(match) [uid 0]: pass out on igb0: (hlim 1, next-header UDP (17) payload length: 89) fe80::2e0:xxx.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x29e8 -> 0x2881!] dhcp6 solicit (xid=e134 (client-ID hwaddr/time type 1 time xx xx) (elapsed-time 0) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/56 pltime:4294967295 vltime:4294967295)))
21:41:41.236162 rule 103/0(match) [uid 0]: pass out on igb0: (hlim 1, next-header UDP (17) payload length: 89) fe80::2e0:xxx.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x29e8 -> 0x484f!] dhcp6 solicit (xid=419032 (client-ID hwaddr/time type 1 time xx xx) (elapsed-time 12531) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/56 pltime:4294967295 vltime:4294967295)))
But running a similar tcpdump command on igb0 (WAN) did not show the packets actually being sent, despite them showing as 'pass out' in the pf log. Which I find rather confusing. I'm not sure if the bad checksum notices in the pflog output are significant.
After rebooting the IPv6 has come back, but I don't yet know if it will stay up. Reloading the WAN interface from the UI > Interfaces > Overview didn't bring it back.
My IPv6 has been working fine on 24.1.7 and 24.1.9.
Any suggestions would be much appreciated.
Thanks
Ben
Looks like this was expected according to the release notes...
Quote from: FrancoAlso, a bad dhcp6c patch has been reverted which requires a manual reboot to take full effect.
Nope: "After rebooting the IPv6 has come back, but I don't yet know if it will stay up. Reloading the WAN interface from the UI > Interfaces > Overview didn't bring it back."
They broke IPv6 with 24.1.9 and have now also broken intra networking with 24.2.10.
> They broke IPv6 with 24.1.9 and have now also broken intra networking with 24.2.10.
If only we got more qualified reports like this one IPv6 would work better than ever. ;)
So I have to ask the obvious... what's the actual problem then?
Cheers,
Franco
I didn't want to bring it up before, but you gave me the opening. Franco, look into yourself, and there you will find the problem and the solution.
Let me know if I can help or you just want to dis. In the latter case I'll go find someone else to help.
Cheers,
Franco
Hi there! After upgrade to 24.1.10 and reboot, no prefix. IPv6 address on wan interface is fe80::e63a:6eff:fe60:f068/64 and gateway fe80::21c:73ff:fe00:99
USA, Xfinity
thanks, over here we were discussion the filter rule change: https://forum.opnsense.org/index.php?topic=41508.0
If you revert this one https://github.com/opnsense/core/commit/e94baab85 by issuing:
# opnsense-patch e94baab85
If that's the offending one I'm curious how the packet capture looks.
Cheers,
Franco
sudo tcpdump -ve -i pflog0 udp port 546 or udp port 547
Password:
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 262144 bytes
01:31:21.137376 rule 72/0(match): pass in on igc0: (flowlabel 0xe03b8, hlim 1, next-header UDP (17) payload length: 76) fe80::9209:d0ff:fe2c:2bfa.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=7027e2 (client-ID hwaddr type 1 9009d02c2bfa) (option-request DNS-server DNS-search-list) (elapsed-time 65535) (Client-FQDN) (IA_NA IAID:3492555770 T1:3600 T2:5400))
01:31:36.745789 rule 72/0(match): pass in on igc0: (flowlabel 0xd0000, hlim 1, next-header UDP (17) payload length: 58) fe80::1443:eb41:299:bf99.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=cab31f (client-ID hwaddr type 1 7ae0d678f796) (option-request DNS-server DNS-search-list opt_103) (elapsed-time 15768) (IA_NA IAID:0 T1:0 T2:0))
01:32:45.734092 rule 94/0(match) [uid 0]: pass out on igc1: (hlim 1, next-header UDP (17) payload length: 105) fe80::e63a:6eff:fe60:f068.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x4205 -> 0x12a1!] dhcp6 solicit (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (IA_NA IAID:0 T1:0 T2:0) (elapsed-time 25083) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:4294967295 vltime:4294967295)))
01:32:45.812523 rule 17/0(match): block in on igc1: (flowlabel 0xa95d5, hlim 63, next-header UDP (17) payload length: 173) 2001:558:4081:cd::10.dhcpv6-server > fe80::e63a:6eff:fe60:f068.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (server-ID hwaddr/time type 1 time 391757488 14feb5d5b5d0) (IA_NA IAID:0 T1:77079 T2:123327 (IA_ADDR 2001:558:6022:cd:9c37:2b2c:358c:5a3a pltime:154159 vltime:154159)) (IA_PD IAID:0 T1:77079 T2:123327 (IA_PD-prefix 2601:2c1:8e80:7ba0::/60 pltime:154160 vltime:154160)) (DNS-server cdns01.comcast.net cdns02.comcast.net))
01:33:27.347975 rule 72/0(match): pass in on igc0: (flowlabel 0xe03b8, hlim 1, next-header UDP (17) payload length: 76) fe80::9209:d0ff:fe2c:2bfa.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=7027e2 (client-ID hwaddr type 1 9009d02c2bfa) (option-request DNS-server DNS-search-list) (elapsed-time 65535) (Client-FQDN) (IA_NA IAID:3492555770 T1:3600 T2:5400))
01:33:47.010003 rule 72/0(match): pass in on igc0: (flowlabel 0xd0000, hlim 1, next-header UDP (17) payload length: 58) fe80::1443:eb41:299:bf99.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=cab31f (client-ID hwaddr type 1 7ae0d678f796) (option-request DNS-server DNS-search-list opt_103) (elapsed-time 30814) (IA_NA IAID:0 T1:0 T2:0))
01:34:36.785343 rule 94/0(match) [uid 0]: pass out on igc1: (hlim 1, next-header UDP (17) payload length: 105) fe80::e63a:6eff:fe60:f068.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x4205 -> 0xe73f!] dhcp6 solicit (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (IA_NA IAID:0 T1:0 T2:0) (elapsed-time 36188) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:4294967295 vltime:4294967295)))
01:34:36.861682 rule 17/0(match): block in on igc1: (flowlabel 0xa95d5, hlim 63, next-header UDP (17) payload length: 173) 2001:558:4081:cd::10.dhcpv6-server > fe80::e63a:6eff:fe60:f068.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (server-ID hwaddr/time type 1 time 391757488 14feb5d5b5d0) (IA_NA IAID:0 T1:77024 T2:123238 (IA_ADDR 2001:558:6022:cd:9c37:2b2c:358c:5a3a pltime:154048 vltime:154048)) (IA_PD IAID:0 T1:77024 T2:123238 (IA_PD-prefix 2601:2c1:8e80:7ba0::/60 pltime:154049 vltime:154049)) (DNS-server cdns01.comcast.net cdns02.comcast.net))
01:35:34.316332 rule 72/0(match): pass in on igc0: (flowlabel 0xe03b8, hlim 1, next-header UDP (17) payload length: 76) fe80::9209:d0ff:fe2c:2bfa.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=7027e2 (client-ID hwaddr type 1 9009d02c2bfa) (option-request DNS-server DNS-search-list) (elapsed-time 65535) (Client-FQDN) (IA_NA IAID:3492555770 T1:3600 T2:5400))
01:36:37.514103 rule 94/0(match) [uid 0]: pass out on igc1: (hlim 1, next-header UDP (17) payload length: 105) fe80::e63a:6eff:fe60:f068.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x4205 -> 0xb816!] dhcp6 solicit (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (IA_NA IAID:0 T1:0 T2:0) (elapsed-time 48261) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:4294967295 vltime:4294967295)))
01:36:37.588213 rule 17/0(match): block in on igc1: (flowlabel 0xa95d5, hlim 63, next-header UDP (17) payload length: 173) 2001:558:4081:cd::10.dhcpv6-server > fe80::e63a:6eff:fe60:f068.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (server-ID hwaddr/time type 1 time 391757488 14feb5d5b5d0) (IA_NA IAID:0 T1:76963 T2:123141 (IA_ADDR 2001:558:6022:cd:9c37:2b2c:358c:5a3a pltime:153927 vltime:153927)) (IA_PD IAID:0 T1:76963 T2:123141 (IA_PD-prefix 2601:2c1:8e80:7ba0::/60 pltime:153928 vltime:153928)) (DNS-server cdns01.comcast.net cdns02.comcast.net))
01:37:39.979613 rule 72/0(match): pass in on igc0: (flowlabel 0xe03b8, hlim 1, next-header UDP (17) payload length: 76) fe80::9209:d0ff:fe2c:2bfa.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=7027e2 (client-ID hwaddr type 1 9009d02c2bfa) (option-request DNS-server DNS-search-list) (elapsed-time 65535) (Client-FQDN) (IA_NA IAID:3492555770 T1:3600 T2:5400))
01:38:26.031522 rule 94/0(match) [uid 0]: pass out on igc1: (hlim 1, next-header UDP (17) payload length: 105) fe80::e63a:6eff:fe60:f068.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x4205 -> 0x8db2!] dhcp6 solicit (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (IA_NA IAID:0 T1:0 T2:0) (elapsed-time 59113) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:4294967295 vltime:4294967295)))
01:38:26.108827 rule 17/0(match): block in on igc1: (flowlabel 0xa95d5, hlim 63, next-header UDP (17) payload length: 173) 2001:558:4081:cd::10.dhcpv6-server > fe80::e63a:6eff:fe60:f068.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (server-ID hwaddr/time type 1 time 391757488 14feb5d5b5d0) (IA_NA IAID:0 T1:76909 T2:123055 (IA_ADDR 2001:558:6022:cd:9c37:2b2c:358c:5a3a pltime:153819 vltime:153819)) (IA_PD IAID:0 T1:76909 T2:123055 (IA_PD-prefix 2601:2c1:8e80:7ba0::/60 pltime:153820 vltime:153820)) (DNS-server cdns01.comcast.net cdns02.comcast.net))
01:39:36.614890 rule 72/0(match): pass in on igc0: (flowlabel 0xe03b8, hlim 1, next-header UDP (17) payload length: 76) fe80::9209:d0ff:fe2c:2bfa.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=7027e2 (client-ID hwaddr type 1 9009d02c2bfa) (option-request DNS-server DNS-search-list) (elapsed-time 65535) (Client-FQDN) (IA_NA IAID:3492555770 T1:3600 T2:5400))
01:40:17.044694 rule 94/0(match) [uid 0]: pass out on igc1: (hlim 1, next-header UDP (17) payload length: 105) fe80::e63a:6eff:fe60:f068.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x4205 -> 0x749c!] dhcp6 solicit (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (IA_NA IAID:0 T1:0 T2:0) (elapsed-time 65535) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:4294967295 vltime:4294967295)))
01:40:17.116563 rule 17/0(match): block in on igc1: (flowlabel 0xa95d5, hlim 63, next-header UDP (17) payload length: 173) 2001:558:4081:cd::10.dhcpv6-server > fe80::e63a:6eff:fe60:f068.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (server-ID hwaddr/time type 1 time 391757488 14feb5d5b5d0) (IA_NA IAID:0 T1:76854 T2:122966 (IA_ADDR 2001:558:6022:cd:9c37:2b2c:358c:5a3a pltime:153708 vltime:153708)) (IA_PD IAID:0 T1:76854 T2:122966 (IA_PD-prefix 2601:2c1:8e80:7ba0::/60 pltime:153709 vltime:153709)) (DNS-server cdns01.comcast.net cdns02.comcast.net))
01:41:04.726874 rule 72/0(match): pass in on igc0: (flowlabel 0xd0000, hlim 1, next-header UDP (17) payload length: 58) fe80::1443:eb41:299:bf99.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=cab31f (client-ID hwaddr type 1 7ae0d678f796) (option-request DNS-server DNS-search-list opt_103) (elapsed-time 65535) (IA_NA IAID:0 T1:0 T2:0))
01:41:30.673066 rule 72/0(match): pass in on igc0: (flowlabel 0xe03b8, hlim 1, next-header UDP (17) payload length: 76) fe80::9209:d0ff:fe2c:2bfa.dhcpv6-client > ff02::1:2.dhcpv6-server: [udp sum ok] dhcp6 solicit (xid=7027e2 (client-ID hwaddr type 1 9009d02c2bfa) (option-request DNS-server DNS-search-list) (elapsed-time 65535) (Client-FQDN) (IA_NA IAID:3492555770 T1:3600 T2:5400))
01:42:15.044218 rule 94/0(match) [uid 0]: pass out on igc1: (hlim 1, next-header UDP (17) payload length: 105) fe80::e63a:6eff:fe60:f068.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x4205 -> 0x749c!] dhcp6 solicit (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (IA_NA IAID:0 T1:0 T2:0) (elapsed-time 65535) (option-request DNS-server DNS-search-list) (IA_PD IAID:0 T1:0 T2:0 (IA_PD-prefix ::/60 pltime:4294967295 vltime:4294967295)))
01:42:15.119840 rule 17/0(match): block in on igc1: (flowlabel 0xa95d5, hlim 63, next-header UDP (17) payload length: 173) 2001:558:4081:cd::10.dhcpv6-server > fe80::e63a:6eff:fe60:f068.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=9ed244 (client-ID hwaddr/time type 1 time 758694841 e43a6e60f067) (server-ID hwaddr/time type 1 time 391757488 14feb5d5b5d0) (IA_NA IAID:0 T1:76795 T2:122872 (IA_ADDR 2001:558:6022:cd:9c37:2b2c:358c:5a3a pltime:153590 vltime:153590)) (IA_PD IAID:0 T1:76795 T2:122872 (IA_PD-prefix 2601:2c1:8e80:7ba0::/60 pltime:153591 vltime:153591)) (DNS-server cdns01.comcast.net cdns02.comcast.net))
after that opnsense-patch e94baab85 all is ok
Ah, very good. The capture is from the bad attempt, right?
Yes, it from bad attempt
Ok how about this then: https://github.com/opnsense/core/commit/0217a1a95b1
# opnsense-revert opnsense
# opnsense-patch 0217a1a95b1
Cheers,
Franco
Gut! All work. Thank you!
P.S.
After reboot too
Thanks, I'll have this hotfixed in a bit.
(see how awesome this teamwork in open source can be)
Cheers,
Franco
Thank you for this quick fix, I'm trying 24.1.10_1 now.
Last night I did:
opnsense-revert -r 24.1.9 dhcp6c
opnsense-revert -r 24.1.9 opnsense
And _one_ of these did resolve the problem, it was late and I didn't have time to do them separately and confirm which one.
I'm not sure though if mine is the same problem - just because when IPv6 is working well, the DHCP replies all seem to come from a link-local address, so not sure if/how the GUA fix here is relevant. Still, I'll wait and see.
Thanks
Ben
It depends... improving IPv6 is like playing whac-a-mole. Best to make sure all packages are on the latest version (see health audit) and then reassess.
Cheers,
Franco
Unfortunately it's still not working for me. Same as yesterday - I see a log entry saying the DHCPv6 packet is being allowed outbound, but I don't see it being sent in tcpdump on the WAN interface.
What can I do to diagnose this further? I don't understand why the packet is being apparently allowed, but not actually sent (unless tcpdump is lying to me).
Thanks
Ben
Suricata IPS mode running or Zenarmor? Few keep reporting that IPv6 (both WAN and LAN) can be impeded by it, but I honestly don't know why.
Cheers,
Franco
I'm running neither of those - nothing complicated at all here really. Aside from usual firewall/NAT I run unbound and an OpenVPN client (the latter of which I have disabled - can't see how it would affect this, but who knows).
I've done:
opnsense-revert -r 24.1.9 dhcp6c
(and rebooted) to narrow down where the problem might be, will see how that goes.
24.1.9 is the worst one. The baseline is 24.1.8 and 24.1.10 should work according to other qualified reports.
I understand that IPv6 seems to have issues, but I doubt a bit that all the things going on are related to just OPNsense. Half the issues are on the ISP side, intermittent or otherwise.
Cheers,
Franco
Interesting. I never had a problem on 24.1.9, at least not 9_4.
Well for me it looks like the previous command has resolved the problem - at least after 30 minutes, the first renewal has worked ok. I'll let it run a bit longer and see how this goes.
From a read of the diffs I am confused how the behaviour has changed.
It hasn't much. There are two bugs that have now been fixed as of 24.1.10_1
o dhcp6c was not renewing its IA-NA (introduced in 24.1.9)
o the DHCPv6 WAN requirements rule was cleaned up some servers seem to send from a GUA instead of a link-local which doesn't make a lot of sense as it complicates the way IPv6 is acquired probably using the temporary SLAAC address (introduced in 24.1.10)
The problem with all this is my main IPv6 setup doesn't show a considerable amount of the side effects that exist out there in the world so while all this is tested it doesn't matter much without worldwide community coverage. I'm confident about a number of other IPv6 changes in the past weeks which brings our IPv6 connectivity into a state that haven't seen elsewhere so what we see as breakage is a sign of moving this forward considerably. If anyone wants to think otherwise that's ok too. I could really use some help so all free energy is welcome.
And then again during testing I see the wildest intermittent issues, sometimes in response to re-requests happening frequently where the ISP just refuses to answer for a while.
Cheers,
Franco
Same problem here. 24.1.9 ran fine, problems with 24.1.10 after a while on dhcpv6 renewal. With that version, the GUA prefixes were gone after renewal.
Then I saw 24.1.10_1 was out, installed and rebooted, same behaviour.
Then did "opnsense-revert -r 24.1.9 opnsense" and voila - problem is gone.
ISP is Deutsche Glasfaser, no IA-NA, only IA-PD. Strange thing is, I have 3 machines with that ISP, only two of which show this behaviour. Because of CG-NAT, the problem is hard to diagnose from remote when IPv6 connectivity is lost.
I certainly know of the IPv6 improvements that are about to come with 24.7 and will probably stay on 24.1.9 until then.
24.1.10_1 needs a filter reload (and 24.1.10 a reboot if you want to be sure).
Cheers,
Franco
Worth mentioning that I'm also in the no address, prefix-only camp.
I'm happy to help diagnose in any way I can - the problem seems to be fairly consistent here, and it's not a remote router with problematic access.
> Worth mentioning that I'm also in the no address, prefix-only camp.
In that case the dhcp6c changes should be irrelevant either way. Same as here for me. Try to keep running a clean reboot of 24.1.10_1 and see how far it goes.
Thanks,
Franco
With the reverted dhcp6c my IPv6 was up for just over an hour (first request + 2x renewals at 30 minutes). I've now updated to the latest dhcp6c again, checked everything else is correct with a health audit, and rebooted. So this should be clean 24.1.10_1.
IPv6 initial request has worked (but it always did). I will see what happens at renew time.
Thanks
Ben
Well back on a clean 24.1.10_1 it's now working fine, which is good, but also slightly weird. I don't know why it was failing this morning with the same settings, or last night, which was admittedly before the hot-fix, although all my logs indicate my ISP sends DHCP replies from a link-local address, so that shouldn't have mattered.
Anyway - good news that it works but I'm still nervous I don't really understand what went wrong. I know it could be an ISP problem, but that would seem a huge coincidence and doesn't really fit with the odd behaviour I saw with packets being logged as allowed but not appearing in tcpdump.
I'll continue to monitor it anyway.
Turning my OpenVPN client back on has broken it. Getting desperate, I found this:
$ sudo tcpdump -i ovpnc1 net fe80::/10 or net ff02::/16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc1, link-type NULL (BSD loopback), capture size 262144 bytes
14:03:16.232230 IP6 fe80::xx.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
The DHCPv6 packet is being sent over the VPN interface.
Any idea why that would happen? It makes little sense to me.
I disabled OpenVPN again and on the next attempt, dhcp6c succeeded.
I'm not sure, but with another user we found https://github.com/opnsense/core/commit/eb269e0d4a which coincidentally is about destination ff02::/16. It looks like the older ruleset was allowing dhcp6c to piggyback the state of the other rule, but that's no longer possible.
Cheers,
Franco
Thanks, I've applied that and will report back.
Hi
I've been running V24.1.9_3 since 20-Jun & everything appeared to be fine on the surface. Today, since 24.1.10 became available, I cleaned my glasses properly & looked at the dashboard and realised that I had no IPV6 addresses. (I do have a public V4 (and no CGNAT) which explains why I (we) hadn't noticed that anything was awry before.
I rebooted the FW and noted that IPV6 was back ok. I then set to, writing a logging script to check how long it took to fail. My public V6 address had gone before I'd finished writing the script ::) . So I finished the script, rebooted again, and ran the logging script. It took precisely 10 minutes to lose the V6 address again (sounds like a 600 sec lease to me).
I then did a backup of the config file, and tried to do the update to 24.1.10_1. That didn't work. I'm guessing that part of the system was trying to do the upgrade using IPV6, which had silently gone away.
So I rebooted again, and started the update to 24.1.10_1 before I lost my V6 public address. The update appeared to go ok. When it had finished, I did a manual reboot (but not a filter reload - because I wasn't sure what that was referring to) and the system has now been up for just over an hour. My IPV6 logging script shows that my V6 address hasn't gone awol.
So 24.1.10_1 seems to have fixed whatever was wrong in 24.1.9_3 for me, at least.
I do have another live system, also running 24.1.9_3, but that system has a fixed IPV6 public address, but, unsurprisingly, that system shows absolutely no problem.
HTH
PeterF
Initially https://github.com/opnsense/core/commit/eb269e0d4a is looking good for me. I've re-enabled OpenVPN and DHCPv6 still renews ok. I'm going to reboot and make sure a clean boot runs fine.
I'll hotfix this now and then we're hopefully back to 24.1.8 state. The rest of the goodies for IPv6 are stashed away on 24.7 which makes this extra work worth the while eventually.
Cheers,
Franco
While the patch seems to fix the problem with dhcpv6 renewal for me as well, 24.1.10_1 still takes long on reboot to pick up the IPv6 GUA - it does not start right away as before.
If you could look into the different timelines during boot between versions that would help.
Cheers,
Franco
Here is the log from a reboot with the patched 24.1.10_1. You can see that the IPv6 takes ~2 minutes to get at from the start of the WAN configuration, but IDK why... the IPv4 is ready after ~1 minute. I can also see that the wireguard connections are reconnected before there is even an IPv6 - which is a problem if the counterpart is IPv6 only.
Around 2024-07-12T18:38:50, there is a lot going on that fails, like dyndns updates and HAproxy startup (apparently with a segfault).
Quote from: franco on July 12, 2024, 06:30:05 PM
I'll hotfix this now and then we're hopefully back to 24.1.8 state. The rest of the goodies for IPv6 are stashed away on 24.7 which makes this extra work worth the while eventually.
24.1.10_2 has been stable for me overnight, with OpenVPN turned back on. Thanks for the fix.
Ben
I'm not sure this is related, but after the upgrade, OPNSense started rejecting all inbound traffic. I haven't done any research yet, just switched over to my backup machine running an older version, but the log errors were mentioning something about default blocking due to state. Will post the exact error when I get back to that machine.
EDIT: The error is Default deny / State violation rule, and the version is 24.1.10_2-amd64. ISP is Comcast Business USA. Is this related, do you think?
EDIT EDIT: I reverted to 24.1 with a fresh install, and everything is working again with the same config. I'll pass on 24.1.10_x and wait for next update in hope it will settle down.
EDIT³ - Because I am apparently a glutton for punishment, I upgraded the new working installation to 24.1.10_2 to see what would happen. Result: the same thing. All inbound connections blocked with Default deny / State violation rule.
The more I think about it, the more I conclude this is an unrelated issue, so I'm starting a separate thread for the question.
Also have issues with IPv6 on the latest OPNsense installations with PPPoE.
The firewall can't communicate to the outside world over IPv6. The clients can. I dont know what happened, but it seems to be broken for me, even with a backup restore on a clean install. This worked fine in the past.
My IPv6 is also broken since a few weeks back.
I get this when tcpdumping:
# tcpdump -ve -i pflog0 udp port 546 or udp port 547
08:47:53.564963 rule 91/0(match): pass in on igb0: (class 0xe0, hlim 128, next-header UDP (17) payload length: 179) fe80::2022:ff:fe01:1.dhcpv6-server > fe80::2e0:67ff:fe2c:f570.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=7206b (IA_NA IAID:0 T1:3600 T2:7200 (IA_ADDR 2001:9b0:130:0:ffff:cd9e:c6ea:d722 pltime:54000 vltime:86400)) (IA_PD IAID:0 T1:3600 T2:7200 (IA_PD-prefix 2001:9b1:23ff:6800::/56 pltime:54000 vltime:86400)) (client-ID hwaddr/time type 1 time 700187364 00e0672cf570) (server-ID hwaddr/time type 1 time 660837239 00505687fc2c) (DNS-server 2001:9b0::53:1 2001:9b0::53:2) (status-code UnspecFail))
The last part, (status-code UnspecFail), doesn't look good.
I have tried all tips in this thread, patching back and forth, reverting to 24.1.8 and 24.1.9, nothing helps. Should I revert even further?
One of the patches doesn't seem to work anyway:
# opnsense-patch e94baab85
Found local copy of e94baab85, skipping fetch.
1 out of 1 hunks failed while patching etc/inc/filter.lib.inc
From my ISP i get DHCP6-PD with a /56.
Not very useful. If that's what the server says it's probably right (even if for the wrong reasons). Check with your ISP.
Cheers,
Franco
Ok, can I debug in more detail?
If I change Prefix Delegation Size to "None" instead of 56, then I get back my v6-address on the WAN interface. But the tracking doesn't work. If I change back to 56, then the "status-code UnspecFail" show up again.
This has been working for several years, I'm not sure what to ask my ISP?
You can dump a lot of debug information via dhcp6c debugging options, but if the ISP's server refuses your request it's likely because your request isn't valid anymore either by the ISP changing it or you locally.
You should be able to ask your ISP why the IPv6 advertise packed with with an UnspecFail status code.
Cheers,
Franco
@riborg: which ISP do you use?
I live in Sweden and the ISP is Bahnhof.. I talked to them today and they have no issues. I am also going to talk to my layer 2 provider, they have had issues with delivering v6 before..
Got Bahnhof as well and the same problem with ipv6. Did someone got this to work?
The support stating it should work and other customers on the same switch has ipv6. With their equipment not opnsense