OPNsense Forum
Archive => 22.1 Legacy Series => Topic started by: staticznld on March 25, 2022, 08:41:46 pm
-
After upgrading to OPNsense 22.1.4_1 i have no IPv6 connectivity.
Through DHCPv6 over PPPoE i am able to get an /48 prefix, which is served to the clients through radvd "Track interface".
Clients in my lan network are getting an IPv6 address but pining an IPv6 host is not possible. (Ping within the /64 network works)
When running a ping from the gui, "ping6: sendmsg: No route to host" is the message.
In OPNsense 22.1.3 I had the same setup without any issues!
-
My German isn’t good at all but on twitter I read this thread, https://twitter.com/opnsense/status/1507439603082579978 where “opnsense-patch 1a5dfc932f8” is mentioned.
I tried applying the patch and reload the PPPoE interface and IPv6 is working again!
The default IPv6 route was missing, with the patch applied it was there again.
-
Same problem here after the upgrade, but after applying the 1a5dfc9 commit it works again...
-
I’ll wait for the second hotfix…
-
I’ll wait for the second hotfix…
No offence, but good luck with that. Someone with a PPPoE needs to look at why this happens. I triple-checked without PPPoE and it works fine. It might be a side effect from PPPoE setup script (ppp-linkup.sh).
Cheers,
Franco
-
Same issue here on a Dutch KPN optical fiber connection. Applying the patch make things work again. Thanks!
-
Before applying the patch there was no default route for IPv6, with the patch applied the default IPv6 route was there again.
Also dutch ISP KPN FTTH . (PPPoE over Vlan 6)
-
Same here in the UK with VirginMedia with Cable Modem in Bridge Mode after this update it killed my IPv6
Nothing to do with PPPoE IMHO as we use just DHCP on the WAN Interface
-
I don't have any issues with IPv6 (DHCPv6 over PPPoE).
-
After a reboot, no IPV6 anymore. With the patch applied... :(
Anyone else here the same results after a reboot?
-
I don't use neither DHCPv6 nor PPPoE. Just SLAAC everywhere. The upgrade to 22.1.4_1 killed my IPv6 as well.
-
I'm seeing the same thing on 22.1.4_1 (among other IPv6 related issues). But in my case at least the loss of IPv6 on the pppoe WAN interface seems to be conditional. Unfortunately the steps to restore (other than a reboot) work intermittently at best.
I use pppoe and have a /56 PD, using the basic settings of "Request only an IPv6 prefix", "Prefix delegation size" of 56, and "Use IPv4 connectivity"
I've also applied patch 1a5dfc932f8.
- When pppoe is established at boot, the WAN interface overview shows both the IPv6 PD and the IPv6 gateway addresses. IPv6 is working and seems to be stable
- If the pppoe interface is reloaded, only the IPv6 gateway address is shown. The PD has disappeared. IPv6 is not working
- If the pppoe interface is disconnected/connected, IPv6 PD and the IPv6 gateway addresses are shown, but 9 times out of 10 after about 4-5 pings the IPv6 connection drops and the PD has also disappeared from the WAN interface overview. IPv6 works for only a few seconds
- Doing a disconnect/connect a few times in quick succession sometimes brings IPv6 back. Sometimes doing a disconnect and then a reload also brings it back. But then doing just a reload will always break it again.
Removed the patch (reverted to a snapshot I took before applying) and the behaviour is the same, except that occasionally IPv6 will randomly work even when the PD address isn't shown in the overview...
-
Applied patch 1a5dfc932f8. That brought IPv6-connectivity back for the clients. The only thing not working right now is the connectivity audit. Although IPv4-connectivity works there, an IPv6-connection can not be made.
Oh ... just found out that all other IPv6-connectivity coming directly from the OPNsense-box seems to be broken too, such as ntp and stuff.
-
We went from PPPoE fix with the patch to "the patch doesn't work either" and "non-PPPoE is broken".
This is all but structured... seemingly random things dropped into this thread all relating to IPv6 in general.
Cheers,
Franco
-
Hi Franco,
Sorry for that. It really is not my intention to confuse anyone. To make a long story short.
1. After updating to 22.1.4_1, and yes, my provider uses PPPoE, I lost IPv6-connectivity;
2. Using your "patch", clients on my network regained IPv6-connectivity;
3. Although my clients are able to use IPv6 again, the OPNsense-box does not have IPv6-connectivity to other IPv6-enabled hosts on the other site of the PPPoE-link.
So as far as I'm concerned it's all related to the initial post. Please let me know if there's something you want me to do, and I will comply as far as I'm able to.
Best regards.
-
Well with the patch applied my clients AND the OPNsense box are able to connect over IPv6.
***GOT REQUEST TO AUDIT CONNECTIVITY***
Currently running OPNsense 22.1.4_1 (amd64/OpenSSL) at Tue Mar 29 09:52:34 CEST 2022
Checking connectivity for host: pkg.opnsense.org -> 89.149.211.205
PING 89.149.211.205 (89.149.211.205): 1500 data bytes
1508 bytes from 89.149.211.205: icmp_seq=0 ttl=59 time=5.230 ms
1508 bytes from 89.149.211.205: icmp_seq=1 ttl=59 time=5.271 ms
1508 bytes from 89.149.211.205: icmp_seq=2 ttl=59 time=5.811 ms
1508 bytes from 89.149.211.205: icmp_seq=3 ttl=59 time=5.129 ms
--- 89.149.211.205 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.129/5.360/5.811/0.265 ms
Checking connectivity for repository (IPv4): https://pkg.opnsense.org/FreeBSD:13:amd64/22.1
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.txz: .......... done
Processing entries: .......... done
OPNsense repository update completed. 783 packages processed.
All repositories are up to date.
Checking connectivity for host: pkg.opnsense.org -> 2001:1af8:4f00:a005:5::
PING6(1548=40+8+1500 bytes) 2a02:a450:839:dddd:: --> 2001:1af8:4f00:a005:5::
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=0 hlim=59 time=3.404 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=1 hlim=59 time=3.280 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=2 hlim=59 time=3.301 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=3 hlim=59 time=3.398 ms
--- 2001:1af8:4f00:a005:5:: ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 3.280/3.346/3.404/0.056 ms
Checking connectivity for repository (IPv6): https://pkg.opnsense.org/FreeBSD:13:amd64/22.1
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.txz: .......... done
Processing entries: .......... done
OPNsense repository update completed. 783 packages processed.
All repositories are up to date.
***DONE***
-
The patch really doesn't do much to be honest and is semantically the same except that it tries to clear the router file when rtsold is invoked. What I need to know:
What is the state of /tmp/pppoe0_routerv6 with and without the patch... and if the file exists what is the contents of it? (the name might differ, look for "/tmp/*_routerv6" files on your system.
Cheers,
Franco
-
At the moment i am unable to check without the patch installed.
But with the patch installed i see the default link local gateway.
root@router:~ # cat /tmp/pppoe0_routerv6
fe80::1251:72ff:fe23:3288
root@router:~ #
Before i installed the update i didn't see the default gateway in the gui.
I will try to lookup the file tonight.
-
Hmm, in any case here is a patch for 22.1.4 that emulates the previous behaviour.
https://github.com/opnsense/core/commit/4b6fa9e556690
However, it suggest that doing "DHCPv6 on a PPPoE that provides IPv6 connectivity" is one of the silliest things the code historically did... does dhcp6c even ever get an address? A prefix maybe at best?
Cheers,
Franco
-
Without the patch installed i did see the "IPv6 delegated prefix" xxxx:xxxx:xxxx::/48 in the overview.
-
prefix info is irrelevant. It moved to a different file but it's a read-only value. (It's mentioned in the patch BTW.)
Cheers,
Franco
-
Patch removed en reloaded the PPPoE device.
root@router:~ # cat /tmp/pppoe0_routerv6
fe80::1251:72ff:fe23:3288
Also the default IPv6 route is gone in the GUI.
Then applied https://github.com/opnsense/core/commit/4b6fa9e556690 and IPv6 is working again!
Also the default route is back in the GUI.
-
Hi,
I decided to investigate my IPv6-problem and it turns out Franco was right :-[ . The problems I experienced after running patch 1a5dfc932f8 had to do with IPv6 fragments (observed while looking at a packet capture) and had nothing to do with the patch.
After checking (and re-setting) the MTU-size on the WAN-interface (MTU:1512) and the vlan on the WAN-interface (MTU:1508) I got an MTU of 1500 on my PPPoE interface after which I was able to ping using IPv6 again.
Checking connectivity for host: pkg.opnsense.org -> 2001:1af8:4f00:a005:5::
PING6(1548=40+8+1500 bytes) [opnsense-box_ipv6] --> 2001:1af8:4f00:a005:5::
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=0 hlim=59 time=3.960 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=1 hlim=59 time=3.660 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=2 hlim=59 time=3.657 ms
1508 bytes from 2001:1af8:4f00:a005:5::, icmp_seq=3 hlim=59 time=3.629 ms
Problem solved!Thanks for being so resolute. That made me look into it again and solve my problem ;) .
Best regards.
-
Also investigating your MTU solution, but that isn't working for me.
Some websites aren’t available at all!
I have a PPPoE tunnel over VLAN 6.
I have created an unused (only for setting MTU) interface IGB0 with an MTU of 1508, on top of that VLAN6, and on top of that PPPoE.
When looking at https://www.speedguide.net/analyzer.php i can see that I am using an MTU of 1500.
opnsense-patch 4b6fa9e
Did solve the problem for me.
-
Is there ever a nameserver file?
# cat /tmp/pppoe0_nameserverv6
You said there is a prefix assigned. Do you also request and address for WAN IPv6 or just the prefix?
-
Nameserver is there
root@router:~ # cat /tmp/pppoe0_nameserverv6
2a02:a47f:e000::53
2a02:a47f:e000::54
I only request an prefix.
-
Thanks, I guess this is fixed then (and only relevant for PPPoE before someone else jumps in again).
Cheers,
Franco
-
Hi Franco,
Just to confirm ... this patch will be included in the next update of OPNsense?
Best regards.
-
Yes, but happy about all additional feedback in the meantime.
Cheers,
Franco
-
Thanks for the patch!
If there is anything else you would like know, let me know and i take a look.
-
Still trying to think of how to make this code more resilient when PPPoE is being used in conjunction with DHCPv6, but I don't think there isn't any uncertainty here:
ppp-linkup.sh gets called for IPv6 setup (due piggybacking on the IPv4 PPPoE setup actually) before the real IPv6 configuration code can run rtsold which on 22.1.4 cleared the router file written by linkup script a fraction of a second before.
So what worries me is that PPPoE IPv4 connectivity also sets up IPv6 connectivity unrelated to actual IPv6 GUI interface configuration. Sure, there is no other way to obtain a prefix, but the nameserver file could clash as well (if the ISP screws up their end that is).
Cheers,
Franco
-
But that's because of a PPPoE "feature" that allows IPv6 information to be requested using IPv4 connectivity. That's a setting that has to be set manually. So it seems to me that there has to be a way to solve this in an elegant way, right?
-
Forgive my ignorance: which setting is that exactly?
Thanks,
Franco
-
Use IPv4 connectivity? Which after checking seems to be a DHCPv6 client configuration thing (or is it still PPPoE?).
The RFC that talks about it is: https://www.rfc-editor.org/rfc/rfc4241.html if I'm not mistaken.
-
No, use IPv4 connectivity is for moving dhcp6c on top of PPPoE device instead of attached network port that PPPoE runs on. What I mean here is that mpd5 daemon PPPoE connection establishment handles IPv4 and IPv6 although it's supposed to be a pure IPv4 connectivity thing.
You can check this by disabling IPv6 mode on WAN and rebooting... there should still be a /tmp/pppoe0_routerv6 file there?
Cheers,
Franco
-
Correct. So that info is not derived using dhcpv6. Looking at figure 2 used in rfc 4241 is it possible the info comes from IPV6CP? Anyway. I'll try and do some more investigating tonight. Can´t interrupt my internet connection too often because of grumpy customers (a.k.a. family) ;)
-
> Looking at figure 2 used in rfc 4241 is it possible the info comes from IPV6CP?
Yes I think so. So with PPPoE we have two mechanisms to provide name servers and router address. In theory the ISP should match both if he sends them through multiple channels at once, but if that's not the case it's no fun for the customer.
Further, I believe that this could explain the reports over the years regarding endless "reload" cycles on WAN with IPv6 involved, because
https://github.com/opnsense/core/blob/master/src/opnsense/scripts/interfaces/ppp-linkup.sh#L28
and
https://github.com/opnsense/core/blob/master/src/etc/inc/interfaces.inc#L2773
will both execute a WAN-type reload once they receive their information as closely in time as possible even though it's not required.
Cheers,
Franco
-
PS: it might be that we prevent these type of loops since 22.1 via https://github.com/opnsense/core/commit/028302ae74c5bb86 where we avoid removing "cache" files for IP registration inside WAN reload scripts so that the script will always detect it was running if connectivity is still up. Previously I think that the file was cleared and it went into a loop of "oh this address is new let's reload" going to "oh this address is new reload" etc. :)
-
And maybe one more thought... https://github.com/opnsense/core/commit/01913bf7125ec this prevents a full reload on address removal mimicking what PPPoE always did which seems to be more reasonable (or address is gone which we don't care about but the DNS information needs to be cleared).
Cheers,
Franco
-
That's a lot to take in, but I'll dive into it when I have some "spare" time. It's too interesting to let go. Thanks a lot. i really appreciate it. Will report back in a while.
Best regards.
-
I, too, have a PPPoE internet connection, and I'm having the same issues with IPV6 sometimes working and sometimes not. I noticed that the ssh/terminal screen shows different info than the GUI dashboard, as can be seen in the screenshots. Could this be related?
-
Hi dinguz,
The fe80-address is a link local address (https://en.wikipedia.org/wiki/Link-local_address). Nothing wrong with that ;D.
Best regards.
-
The difference I'm observing is that WAN_INET has 2a02:a468:4bba:0:4262:31ff:fe00:4d05/64 in one view, and fe80::4262:31ff:fe00:4d05 in the other. Or is this not an issue?
-
The FE80 address is the gateway for IPv6.
I think the info in the SSH screenshot is wrong, because the Preifx ID "0" is selected for LAN and not WAN.
-
And both addresses can be valid although they have a different scope. To elaborate on that ... someone on the internet could ping your "normal" IPv6 address even when having no direct connection where the link local address can only be used in situations where there is a direct connection (Layer-2) between devices.
As can be seen in your screenshots, 4262:31ff:fe00:4d05 is the host part of the address and that it's the same for both the link local fe80:: and the global 2a02:a468:4bba:: or 2a02:a468:4bba:0 network address.
i81b4u@OPNsense:~ % ping -c 5 2a02:a468:4bba::4262:31ff:fe00:4d05
PING6(56=40+8+8 bytes) [OPNsense_IPv6] --> 2a02:a468:4bba:0:4262:31ff:fe00:4d05
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=0 hlim=61 time=5.547 ms
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=1 hlim=61 time=5.493 ms
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=2 hlim=61 time=5.481 ms
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=3 hlim=61 time=5.518 ms
16 bytes from 2a02:a468:4bba:0:4262:31ff:fe00:4d05, icmp_seq=4 hlim=61 time=5.524 ms
--- 2a02:a468:4bba::4262:31ff:fe00:4d05 ping6 statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 5.481/5.513/5.547/0.024 ms
-
Hi Franco,
Fired up my (t)rusty Dualcomm ethernet tap and captured all traffic between my isp and the OPNsense box during boot. I can say that (at least for my isp) the IPv4 address is assigned during the PPP IPCP phase and that the IPv6 prefix is handed out via DHCPv6 and not via PPP IPV6CP.
Happy to share the pcap-file if you're interested.
Best regards.
-
I, too, have a PPPoE internet connection, and I'm having the same issues with IPV6 sometimes working and sometimes not. I noticed that the ssh/terminal screen shows different info than the GUI dashboard, as can be seen in the screenshots. Could this be related?
i have the same thing after i swap the Intel x540T2 for a Intel x520 SR, wan pppoe has the same ipv6 ip as one of the local lan networks, for me its currently using my pi-hole vlan what resulting in weird dns issues.
when turn off the pi-hole network interface, wan pppoe got an another ipv6 address from one of the enabled lan networks...
can't put the x540 back in because its broken...
before the swap it was just a fe80 address like the gui is showing... (which works create!)
-
configuration issue? When in doubt, unconfigure and reconfigure. That's always my plan of attack ;)
-
@i81b4u
Yes, I get that the prefix can only be dashed out by the DHCPv6 mechanism. I am still pondering about adding a pure PPPoE mode for IPv6 for two reasons:
1. Lock down PPPoE IPv6 connectivity acquired through the link when not requested
2. Exclusive DHCPv6 use when configured.
The latter seems like a change of current operation, but it should work if the ISP sends a complete configuration. The problem is it might not judging from the missing routerv6 file in the rtsold case.
Cheers,
Franco
-
Running into the same issue, I want to add my observations and a my current workaround.
In 22.1.4 the IPv6 Gateway IP is missing.
See attached Screenshots to compare 22.1.2 and 22.1.4.
Simple workaround: I added the Gateways link-local adress manually in the gateway configuration.
This looks like a stable wokraround for me. At least it still was working after some reconnects and reboots.
Cheers
Thorsten
-
Removed patch 4b6fa9e, upgrade to 22.1.5 and IPv6 is working instantly.
-
I still don't have IPv6 on my clients since the upgrade to OPNsense 22, even with 22.1.5.
My WAN interface has a prefix delegation size of 56.
The IPv6 configuration type of the LAN interface is 'Track Interface' with WAN as 'IPv6 Interface' and 'IPv6 Prefix ID' 0 (I also tried 1 as I read somewhere that 0 might cause issues but that didn't fix it).
With these settings my LAN interface gets one of the public IPv6 subnets (public IPv6 with prefix size 64).
Still none of my clients get an IPv6 address.
Did I miss something?
-
21.1.5 broke my ipv6 config.
when untick the 'Allow manual adjustment of DHCPv6 and Router Advertisements', my desktop is getting an ipv6 address, but this will break my android phone wifi connection...
also, when ssh into opnsense wan/pppoe is showing a ipv6 address what is in use by one of the lans.
the GUI dashboard is showing a fe80 address...
before 21.1.4 everything was fine!
logbook is showing this:
2022-04-08T17:48:13 Error opnsense /usr/local/etc/rc.newwanipv6: On (IP address: 2XXX:XXXX:XXXX:1:92e2:XXXX:fe0e:3874) (interface: WAN[wan]) (real interface: pppoe1).
2022-04-08T17:48:13 Error opnsense /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe1'
2022-04-08T17:48:12 Error opnsense /interfaces.php: Warning! dhcpd_radvd_configure(auto) found no suitable IPv6 address on igb0
2022-04-08T17:48:12 Error opnsense /interfaces.php: Warning! dhcpd_radvd_configure(manual) found no suitable IPv6 address on ix0_vlan9
2022-04-08T17:48:12 Error opnsense /interfaces.php: Warning! dhcpd_radvd_configure(manual) found no suitable IPv6 address on ix0_vlan1337
2022-04-08T17:48:12 Error opnsense /interfaces.php: Warning! dhcpd_radvd_configure(manual) found no suitable IPv6 address on mlxen0
2022-04-08T17:48:12 Error opnsense /interfaces.php: Warning! dhcpd_dhcp6_configure() found no suitable IPv6 address on opt5
2022-04-08T17:48:12 Error opnsense /interfaces.php: Warning! dhcpd_dhcp6_configure() found no suitable IPv6 address on opt6
2022-04-08T17:48:12 Error opnsense /interfaces.php: ROUTING: skipping IPv6 default route
2022-04-08T17:48:12 Error opnsense /interfaces.php: ROUTING: IPv6 default gateway set to wan
2022-04-08T17:48:12 Error opnsense /interfaces.php: ROUTING: skipping IPv4 default route
2022-04-08T17:48:12 Error opnsense /interfaces.php: ROUTING: IPv4 default gateway set to wan
2022-04-08T17:48:12 Error opnsense /interfaces.php: ROUTING: entering configure using 'opt7'
logbooks are bit bit broke, the dhcp4 logbook is empty, but going from the syslogbook widget from the desktop i can get more...
-
Thanks for chiming in on the wrong issue. I have to reiterate that this isn't helpful.
Cheers,
Franco
-
Thanks for chiming in on the wrong issue. I have to reiterate that this isn't helpful.
Cheers,
Franco
if this is the wrong issue, which one is the right?
today i found out that when i change the Router Advertisements from 'managed' to 'assisted' my desktop is getting a fully working IPv6, were on 'managed' it only got the ipv6 dns server info but no working ipv6 connection...
i would love to help, but i have no clue were to start ::)
-
It sounds like an individual support case if the answer is already in the configuration change? That's all I'm trying to say.
Cheers,
Franco