No IPv6 after upgrade to 23.01
-
@gertjan interface tracking has been working here for YEARS.
All local interfaces are correctly assigned an IPv6 from upstream correctly.
Now, NO Gateway. WHY?
All I did was update the software. There were no changes in the config. I'm here day after day providing every single thing I'm asked. It's all wonder, but in the end, IPv6 isn't working.
In my opinion there is clearly an issue with this software version. I'm starting to be alarmed for not seeing any involvement from anyone of Netgate on this thread. It's like something alike Schrödinger's cat? There is a problem and there isn't, let's not open the box and find out?
-
@maverickws Mine doesn't say dynamic, so something is wrong there I guess.
-
@bob-dig your's doesn't say dynamic?
When it gets the GW from the upstream DHCP it changes from dynamic to something. Dynamic because it's configured by DHCP: Dynamic Host Configuration Protocol. Go figure.
If I unplug the network cable from WAN and reboot, IPv4 WAN will also show "dynamic" until its configured (by DHCP).
-
@maverickws said in No IPv6 after upgrade to 23.01:
IPv4 WAN will also show "dynamic" until its configured (by DHCP).
That looks like
IPv6 WAN will also show "dynamic" until its configured (by DHCP).
So, yeah, it doesn't get configured.This is :
@maverickws said in No IPv6 after upgrade to 23.01:
receive advertise from fe80::22e0:9cff:fe14:e401%igb5 on igb5
your gateway I guess, if igb5 is your WAN interface.
I see the same lines in my dhcp6c log :
2023-02-21 16:15:36.288257+01:00 dhcp6c 76460 receive reply from fe80::46d4:54ff:fe2a:3600%ix3 on ix3and then
Strange indeed.
I'll locate my IPv6-expert list, see if I can ping request some one.
The thing is : it - the thing that communicates with the other side = dhcp6c, works "for me".
With the identical bare bone "DHCP6 Client Configuration" settings.
I'm using 23.01 Release.
( and I'm pretty sure we don't have the same ISP ... )Anyway, we should find what we haven't seen yet ;)
edit : do you need to check "Do not wait for a RA" ?
No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@gertjan I have that option selected bc when I first configured it followed a tut for my ISP (Altice/MEO Portugal) and it said to enable that option. I can try and remove it an see how it goes.
Before updating to 23.01 it would show exactly as your Gateways print. I'm clueless.
igb5 is WAN
igb4 is WAN2igb0 is LAN
Thank you for your effort in accompanying this and trying to get someone else to help
-
@maverickws said in No IPv6 after upgrade to 23.01:
my ISP (Altice/MEO Portugal) and it said to enable that option.
This post : https://forum.meo.pt/internet-fixa-e-movel-11/pfsense-ipv6-155245 ?
-
@gertjan I don't think it was that, was another on a tech forum from around which name I don't recall. but in the end the options are basically those yes.
Just noticing I'm not sending a prefix delegation hint, but been working fine since. And I'd say I don't need it actually, looking at the logs, wouldn't you say?
-
@gertjan said in No IPv6 after upgrade to 23.01:
edit : do you need to check "Do not wait for a RA" ?
Yeah, I would disable that and maybe delete the gateway and start over, just to be sure.
-
@maverickws To help rule out a config problem you could try resetting to a default config, see if it's still an issue. If it works, save a copy of that working config, and compare to your saved/backup config. If it's still a problem, just restore your old config.
I totally get "but it used to work"...23.01 skipped an entire FreeBSD version so could well have different behavior. For instance unbound set to forward, with DNSSEC enabled, seems to be causing problems for people now. IPv6 isn't broken for everyone which implies it's something specific to the people having problems.
-
@steveits said in No IPv6 after upgrade to 23.01:
For instance unbound set to forward, with DNSSEC enabled, seems to be causing problems for people now.
But that is only with quad9 I guess, working here fine with google and cloudflare.
-
@bob-dig You know you don't "delete" dynamic gateways, right? Because, well, how interface is configured and DHCP.
And by the way, stop with the "it's working here". Your config isn't everyone's config. There isn't ONE config only. There are many variables, different ISP's, different modes.
Just saying "its working here" is just annoying.
I rebooted after removing the option "do not wait for RA" and it didn't really make a difference. I get the IPv6 addresses the same, and nothing else.
@SteveITS I could if I had the time right now or other similar hardware where I could do AB testing. I will try to do that test, but I got no timetable for it.
It seems to me that this release has been poorly tested, specially in what concerns IPv6.
-
My issue here is: the ISP honors DHCPv6c giving me an IPV6 address on the WAN interface and a delegation to apply on a track interface. Both show up correctly on the matching interfaces. BUT: the RA announcement from the ISP does not follow the RFC convention of setting the "O" or "M" flags on the RA packet when DHCPv6 is available. Thus rtsold() does NOT invoke the -M or -O scripts resulting in gateway of the relevant interface not being defined/assigend (stuck in "dynamic"), dpinger not running and no default route assigned or the interface not eligible in a gateway group. The strange thing is that it worked up to version 22.05 with this same ISP, ceasing to function with the recent 23.01 update. I suspect the inner workings of rtsold() changed with FreeBSD 14 (current), but cannot find any references to any relevant changes.
Another ISP which honors the M+O flags works fine on the same router...
BTW, IPv4 with the troublesome ISP works OK, so no connectivity issue. -
HI all,
I've been following this thread since my upgrade to 23.01 which also "broke" my ipv6 configuration. Very similar to your observations:-
a) My ISP allocates ipv6 address on the WAN interface by dhcp. I get a \56 allocation
b) I'm allocated a \56 which I then distribute to multiple Internal LAN interfaces via "Track" the WAN as \64s. The "prefix" allocates different \64's to the internal LANs.
c) from the router I can ping6 to ipv6.google.com, and various other sites. (but not all)
d) the "test my ipv6" websites just say that I'm not doing IPv6. - These were working previously.
e) Google Ipv6test says my ipv6 is working... it's an outlier - nothing else agrees.
f) I don't know enough about ipv6 to understand the flags on the DHCP on the WAN interface - but I can see that the appropriate \64 ipv6 address, router address and DNS addresses are being advertised on the various internal LANs.
This all did work until 22.05 - same hardware, same ISP - only change is pfsense.
-
See also here : https://forum.netgate.com/topic/174980/fios-getting-56-pd-via-dhcp6-but-no-v6-is-assigned-to-wan/38?_=1677068897922
I've ran the proposed script myself
sh -c '/sbin/rtsol -DF igb0 2>&1'and that shows ' interesting' things :
.... received RA from fe80::46d4:54ff:fe2a:3600 on ix3,Btw : I can't use "tracking" on my LAN interfaces. That fails for me.
My ISP box does hand over one (just 1) prefix, so a /64 and does not want to give me other /64 for other lans, although my box tells me :La plage de préfixes IPv6 attributable est : 2a01:cb19:xxxx:a600::/56I read that as : I have /56 = 256 /64 for you aviable (minus one, as one has been sued for the network BOX-LAN <=> WAN-PFENSE.
And correct :
the yellow part means : prefix number '0x00' has been used for the
So I got just one, not '0x01', the next one available, but 0xdc (dono why), so I assigned that one as static IPV6 to my LAN interface :
and I called it a day.
You could do the same thing I guess.
The DHCP6 server settings (and pool) have identical IPv6/64 settings - and have to be set manually.
But : this is static, and not 'tracking' my IPv6 prefix(s) at all.
So, if the ISP decides to reallocate my 2a01:cb19:xxxx:a600::/56, or the ISP box decides to give me not 0xdc but 0x11, my entire IPv6 breaks ....
I have to track this ... myself
Sorry for not making your question easier, as I can't pretend that I know (and master) what's going on. IPv6 live with he.net (IPv6 tunnel broker) was easier.
-
@gertjan I only have one observation regarding this,
On my tracking configuration the WAN interface actually never gets a public v6 address. Only a local link fe80.
So I actually never went dip on it why, simply I'd figure it would work it's magic (many IPv6 configs end up using local link as local gw), the LAN and other local interfaces would get their IPv6, all the hosts also got working IPv6 configs, so I was ok with it.
Now I can't do that (setting static) because I've realised I'm always attributed an IP inside a larger /40 network. But the addressing is still kinda dynamic, so putting it static would likely break things. It's kinda like my ISP gives me an IPv4 address and the lease lasts for years. But if I try to put that same IP as static, it denies it and next time I put it on dynamic I get a new one. Dunno why, but it's how it goes.
Nevertheless I found @mhillmann very interesting and it would be quite interesting if we could get some involvement from Netgate on this issue?
-
M maverickws referenced this topic on
-
@maverickws I am agreed with you. I have the same issue, for WAN is only local IPv6, because FIOS does not provide IP for the WAN, I have IPv6 for all my LANs, the only think is al my LANs got 64 prefix and not 56 that is suppose to be according to FIOS, anyway I have IPv6 and works.
Because there is not IPv6 on WAN the Configuring CoDel Limiters for Bufferbloat doesn't works for traffic using IPv6 according to the setting on software Configuration Recipes. For make work you have to applied the firewall rule for all LANs and WAN not only the floating rule for WAN.
Luke Hamburg @luckman212 has a script luckman212/assign-gua-from-iapd - GitHub, and also he has a companion patch to make it automatic. We have this problem before 23.01 because of FIOS implementation of IPv6.
-
Another day without IPv6 on 23.01.
-
@maverickws Can't even reinstall and fix the problem goes directly to 23.01 and no ipv6
-
Hi all,
Just replying here in case my recent findings help anyone else. I don't think I have (had) the same problem as @maverickws , but it may help.
To re-cap - My ISP (BT Business - UK) allocates me a static \56 on the WAN interface via DHCP. I then use WAN address tracking to allocate a \64 to each subnet/VLAN via RADV.
Prior to 23.01 - things were all working swimmingly - 10/10 on the various ipv6 Test web-sites. After the 23.01 upgrade, this all stopped.
I did notice that I was still receiving IPv6 Addresses + DNS via RADVD. I noticed that IPV6 DNS queries were still working.
Google IPV6 test said that my IPv6 was still working, but any web-site I tried to access would just hang, SSH sessions would just hang etc. (I couldn't even reliably access this forum)
i.e. I was able to make ipv6 "connections" but not usable ones.
I then fell down the rabbit hole of IPV6 MTUs / Router Advertisements / Packet Too Big ICMP, and all of the Path MTU discovery process.
I also found the Packet Tuesday channel on YouTube - very informative. Packet Tuesday
I found the IPvFOO Chrome plugin which helped by showing me how hit-and-miss the IPv6 was - small packets (like DNS) worked, larger streams (like web-pages or SSH sessions) would stall immediately.
I discovered that the PFSense default MTU of 1500 is advertised in the RADVD advertisement packet. I read a load of stuff about MTU's, and decided to have a play with that...
I dropped the MTU down to 1280 (the minimum IPv6 MUST support) - and everything started working again. I was getting 10/10 on all of the ipv6 test sites, and my SSH sessions didn't hang.
I had a play with wireshark, and saw that the "packet too big" ICMP responses I was getting were suggesting MTU of 1492. These "Packet too big" responses were from the local LAN interface of my router to the end-device I was using... I don't know whether the end-devices (laptops etc) actually paid any heed to these packet-too-big responses and started using smaller packets - as my WireShark-Fu is not that good.
I read some more, and saw that google and others use a smaller MTU than my pfSense 1500 default.
To cut a long story short - I dropped my MTU to 1480 - and confirmed that this is being advertised by RADVD
AdvLinkMTU 1480- and IPV6 is working for me again !!!I'm not sure what the change was in 23.01 that brought this to the fore.
Hope this helps someone.
Lee.
-
@maverickws
I know, it worked for years. But, seeing as many an ISP may be using PfSense themselves and update the same day as you (and bring other changes to the table at the same time to minimize deployments) and because the vast majority of users run from CPEs and won't miss IPv6 for an hour anyway, try that anyway.
