Messages

Any solution to this problem?

***GOT REQUEST TO UPDATE***
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (1 candidates): . done
Processing candidates (1 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.

flowd-0.9.1_3 is locked and may not be modified
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
Nothing to do.
Nothing to do.
Starting web GUI...done.
Generating RRD graphs...done.
Fetching base-21.7.7-amd64.txz: ............................... failed, no signature found
***DONE***

I tried this, but "gpart resize -i 1 vtbd0" just returns "gpart: no such geom: vtbd0".  Seems like the partition names differ between installs.  Finally did get it to work though.  Thanks.

I have been having the same issue since mid last year when my isp (Greenlight networks) did updates. They insist nothing they did would affect this and have since just stopped responding to ipv6 issues.  IPv6 works for a few min after a reboot, then it doesn't until the next reboot (and again for only a couple min).  On/off I dig into this, and from what I can tell the route expires.  The issue persists even across different OSs (win 10, server 2016, server 2019).  My isp, although good and I like the FTTH connectivity, their support is seriously lacking.

I'm slightly puzzled, what could prevent the IPv6 connection here. I'm considering setting up a fresh install as this one is already updated since quite some years now.

I did that myself already.  I created a new install and manually ported the configurations over.  No change in the behavior.  What I don't understand is why my ISP seems to insist everything is fine when every OS I plug directly into their ONT fails to work (and has the same problem; connectivity fails when the NDP entries go stale).  I'm about ready to just give up and call IPv6 connectivity a total loss at this point.  :(

I dont have an issue with the GW ipv6 link local address showing up in system>gateways>single.  Also the reference to restarting radvd has no effect on the inability to ping the upstream LL gateway.

The interesting thing I noticed this morning is that the upstream gateway IPv6 address (non LL) is actually showing up in "ndp -a" (where I don't recall that being the case previously).

(Note: I manually removed from the output anything w/the Netif was on the LAN as that's not relevant for this discussion).

root@OPNsense:~ # ndp -a
Neighbor                             Linklayer Address  Netif Expire    S Flags
2605:9480:10b:4000::                 98:f4:ab:ca:a9:e7   vmx0 7h8m40s   S
2605:9480:10b:4000::1                c0:d6:82:64:00:54   vmx0 8h50m15s  S R
fe80::3223:3ff:fefa:4d8a%vmx0        30:23:03:fa:4d:8a   vmx0 5h22m59s  S R
fe80::224:45ff:fe8e:cbd3%vmx0        (incomplete)        vmx0 expired   I  2
fe80::7ad2:94ff:fe9a:5cb%vmx0        78:d2:94:9a:05:cb   vmx0 5h22m59s  S R
fe80::46a5:6eff:fe42:10c0%vmx0       44:a5:6e:42:10:c0   vmx0 5h23m0s   S R
fe80::c2d6:82ff:fe64:54%vmx0         c0:d6:82:64:00:54   vmx0 23h47m25s S R
fe80::250:56ff:fea0:c131%vmx0        00:50:56:a0:c1:31   vmx0 permanent R

I can say that pinging the upstream route DOES work (e.g. 2605:9480:10b:4000::1).

Netstat -rn reports this:

root@OPNsense:~ # netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            100.64.108.1       UGS        vmx0
100.64.108.0/22    link#1             U          vmx0
100.64.109.236     link#1             UHS         lo0
127.0.0.1          link#4             UH          lo0
192.168.11.0/24    link#2             U          vmx1
192.168.11.1       link#2             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
default                           fe80::224:45ff:fe8e:cbd3%vmx0 UGS        vmx0
::1                               link#4                        UH          lo0
2605:9480:10b:4000::/50           link#1                        U          vmx0
2605:9480:258:ff10::/64           link#2                        U          vmx1
2605:9480:258:ff10:250:56ff:fea0:fe73 link#2                    UHS         lo0
fe80::%vmx0/64                    link#1                        U          vmx0
fe80::250:56ff:fea0:c131%vmx0     link#1                        UHS         lo0
fe80::%vmx1/64                    link#2                        U          vmx1
fe80::250:56ff:fea0:fe73%vmx1     link#2                        UHS         lo0
fe80::%lo0/64                     link#4                        U           lo0
fe80::1%lo0                       link#4                        UHS         lo0
root@OPNsense:~ #

Pinging the "default" ( fe80::224:45ff:fe8e:cbd3%vmx) does not work.

root@OPNsense:~ # ping6 -c 2  fe80::224:45ff:fe8e:cbd3%vmx0
PING6(56=40+8+8 bytes) fe80::250:56ff:fea0:c131%vmx0 --> fe80::224:45ff:fe8e:cbd3%vmx0
ping6: sendmsg: No route to host
ping6: wrote fe80::224:45ff:fe8e:cbd3%vmx0 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote fe80::224:45ff:fe8e:cbd3%vmx0 16 chars, ret=-1

Should I actually expect the upstream ipv6 (non-LL) address to be listed in the "netstat -rn" "default" entry?

Remember also that I can reproduce this issue on two different Windows operating systems as well (e.g NDP entry goes stale, can't ping upstream anymore).

Am I totally out in the weeds on this?

Once the problem starts (e.g. NDP entry goes stale) on OpnSense, if I try to ping the upstream routers link-local address, ping6 returns an error.

PING6(56=40+8+8 bytes) fe80::250:56ff:fea0:c131%vmx0 --> fe80::c2d6:82ff:fe64:54%vmx0
ping6: sendmsg: No route to host
ping6: wrote fe80::c2d6:82ff:fe64:54%vmx0 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote fe80::c2d6:82ff:fe64:54%vmx0 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote fe80::c2d6:82ff:fe64:54%vmx0 16 chars, ret=-1
^C
--- fe80::c2d6:82ff:fe64:54%vmx0 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

I never actually thought to try pinging the all-routers multicast address, but doing so yields the same result.

root@OPNsense:~ # ping6 -c 4 ff02::2%vmx0
PING6(56=40+8+8 bytes) fe80::250:56ff:fea0:c131%vmx0 --> ff02::2%vmx0
ping6: sendmsg: No route to host
ping6: wrote ff02::2%vmx0 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote ff02::2%vmx0 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote ff02::2%vmx0 16 chars, ret=-1
^C
--- ff02::2%vmx0 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

I wonder if the solution lies in manually creating a persistent route (though at the moment I have no idea how I would do that for ipv6).  However, I would argue that I should never ever have to do that, but it might be at least an interesting learning experience. 

Let me also add that this issue (start of this thread where connectivity fails when the upstream router NDP entry goes stale) is NOT unique to OpnSense (freebsd).  I can repeat that from a Windows Server 2016 and Windows 10 system connected directly to my ISP ONT. 

My ISP (Greenlight Networks in Western NY) still insists that everything is just fine (despite having told them that the maintenance activity they did a couple months ago is when this issue started, and IPv6 hasn't worked since) and that the issue is repeatable across different OSs when connected to their ONT.  The fact that I can reproduce on different OSs clearly indicates the issue isn't isolated to OpnSense (freebsd).

At this point, I just don't know what to do to further troubleshoot this.

With your configuration issue, is IPv6 working (e.g. ping6 to anything on the Internet from OpnSense) for a couple minutes and then fails?  That's the problem I have and I'm wondering whether my problem is similar to yours.  What I have noticed in my issue is it fails when the NDP table entries get flagged as stale (and this is repeatable if for example I plug a Windows system into the ISPs ONT instead of OpnSense). 

I'm looking for help trying to troubleshoot IPv6 issues.  All of this is done FROM an SSH/console login to OpnSense (e.g. the shell; forget about what happens on the LAN side).

When OpnSense is rebooted, IPv6 works for a couple minutes, then it just stops working.  By working I mean ping6 or traceroute6 from OpnSense on the WAN interface.

For example, reboot OpnSense, then login to the console (or ssh).  From the shell, I can successfully ping6 google.com.  Wait a couple minutes, retry the command and it fails.  This has been happening for a couple months (ever since my ISP did some maintenance a few months ago).  I haven't been able to get them to reveal what those changes were or really say anything.  So what I'm looking for is a way to troubleshoot what might be happening where it works only for a couple minutes after a reboot.  This is repeatable.  Are there any commands I can use to try and diagnose what's happening?

I did read that someone suggested using 'netstat -rn6' to check the routing table.

root@OPNsense:~ # netstat -rn6
Routing tables

Internet6:
Destination                       Gateway                       Flags     Netif Expire
default                           fe80::224:45ff:fe8e:cbd3%vmx0 UGS        vmx0
::1                               link#4                        UH          lo0
2605:9480:10b:4000::/50           link#1                        U          vmx0
2605:9480:258:ff10::/64           link#2                        U          vmx1
2605:9480:258:ff10:250:56ff:fea0:fe73 link#2                    UHS         lo0
fe80::%vmx0/64                    link#1                        U          vmx0
fe80::250:56ff:fea0:c131%vmx0     link#1                        UHS         lo0
fe80::%vmx1/64                    link#2                        U          vmx1
fe80::250:56ff:fea0:fe73%vmx1     link#2                        UHS         lo0
fe80::%lo0/64                     link#4                        U           lo0
fe80::1%lo0                       link#4                        UHS         lo0

Sample of the issue (the following is a single copy/paste where the commands were run just a couple minutes apart after a reboot):

root@OPNsense:~ # ping6 google.com
PING6(56=40+8+8 bytes) 2605:9480:258:ff10:250:56ff:fea0:fe73 --> 2607:f8b0:4006:802::200e
16 bytes from 2607:f8b0:4006:802::200e, icmp_seq=0 hlim=117 time=9.095 ms
16 bytes from 2607:f8b0:4006:802::200e, icmp_seq=1 hlim=117 time=9.187 ms
16 bytes from 2607:f8b0:4006:802::200e, icmp_seq=2 hlim=117 time=9.324 ms
^C
--- google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 9.095/9.202/9.324/0.094 ms
root@OPNsense:~ # ping6 google.com
PING6(56=40+8+8 bytes) 2605:9480:258:ff10:250:56ff:fea0:fe73 --> 2607:f8b0:4006:81a::200e
^C
--- google.com ping6 statistics ---
25 packets transmitted, 0 packets received, 100.0% packet loss

I've been using OpnSense for a few years now and it's worked well.  However, it's become quite unreliable as of lately.  The current symptom is that every 1-5 days it starts to fail rather suddenly.  The exact symptom is network throughput from the LAN starts to fail (~50% packet loss when pinging google.com or 8.8.8.8).  At the same time that happens the web login interface from the LAN also fails (just stops responding completely).  From the console, when I login ping rates out the WAN seem consistent (~50% packet loss).  Restarting the services (11 in the menu) doesn't resolve the problem.  The only resolution is to reboot (again, you'd have to do this from the console since the web login interface has stopped responding entirely).  This is all ipv4.

What I mean by failing is that after OpnSense is rebooted "ping6 google.com" works.  After 4 minutes, it no longer works.  This is directly from OpnSense (not some workstation on my LAN).  My ISP configuration is ISP -> ONT -> OpnSense.  Same result regardless of the setting "Request only an IPv6 prefix".  I read someone elses post (can't recall where at the moment and I don't have the URL handy) that they were having IPv6 reliability issues and they moved back to 20.1 and their issues were resolved.  I'll be trying the same thing, but will not be able to for a few days.

I have a similar problem (ipv6 stops working).  If I reboot OpnSense, ipv6 works for 4 minutes, then stops working. Reboot it again and it'll work (for another 4 minutes).  The command recommend on this bug report ("pluginctl -s radvd restart" reported here: https://github.com/opnsense/core/issues/4338) doesn't work for me.  I'm using v20.7.3 and my ISP is fiber (ISP -> ONT -> OpnSense).  When I say "not working" I mean I can "ping6 google.com" and that works for up to 4 minutes after a reboot.  After 4 minutes, 100% failure. I don't have the thread/URL handy, but I did recall seeing someone else (not sure if it was on this forum or elsewhere) indicate they had similar issues and moved back to 20.1.  I'm likely going to try that, but will not be able to for a few more days.

The problem I am having continues.  My ISP does not provide a router, just the ONT.

It appears that the point of failure is 4 minutes after OpnSense is rebooted. 

I'm not sure I understand what you mean.  If I reboot OpnSense, ipv6 works, for some amount of time less than 20 minutes (only because I haven't sat around testing every few min).  After that some amount of time, it fails.  By working and failing, I'm talking about pinging google (from opnsense, ping6 google.com; from windows ping -6 google.com).