Messages

Oh nevermind. I see that dnsmasq is what I am using and should utilize as a bridge before trying a more complicated Kea based config. The old hooks to ISC on the interface and services tabs is where I went astray.

Really basic questions here.

I am wiping a Celeron based system (Protectli Vault FW6C) that was running 24.7 and jumping to 25.7. Things were working fine but it is past time to upgrade.

This is a clean install. Drive is wiped and then I run the 25.7 installer. I am not carrying any configuration settings over.

I was looking forward to the Kea ipv6 stuff but in the meantime I just want to get basic ipv4 working and I'll use ISC if I have to.

The WAN is getting an IPv4 address. My problem is the LAN interface. This is a fresh install with stock settings. The only thing I have changed right now is the root password and the only thing connected to the LAN interface is an old laptop running Debian 12; directly via ethernet.

I can get to the OPNsense web interface just fine via 192.68.1.1.

Service -> ISC DHCPv4 does not show a LAN interface. I see no way to control or set DHCP options for the LAN interface yet somehow my laptop's enp0s31f6 interface has an IP address of 192.168.1.164 and I can get out to the wider internet

When I assign 192.168.2.1 to OPT1 can then see OPT1 under Service -> ISC DHCPv4

However, as soon as set an IP range, enable the ISC DHCP server, and apply changes I lose all connectivity on the LAN. The ping command on my laptop says the network is unreachable. Reboots have no affect. I have to resort to the factory reset via console.

I don't know why simply turning on a DHCPv4 service on OPT1 would kill LAN connectivity. Also, why can't I see what DHCP service the LAN is using? There is nothing under leases yet something assigned 192.168.1.164 to my laptop.

Anybody else on FIOS?

Does your WAN interface have a real IPv6 address (i.e. a globally unique address)? I remember some people speculating that FIOS had started using the RFC6603 PD Exclude option.

https://datatracker.ietf.org/doc/html/rfc6603

Other people discussed this problem a few years ago here: https://forum.netgate.com/topic/174980/fios-getting-56-pd-via-dhcp6-but-no-v6-is-assigned-to-wan/18

During that talk someone came up with a script to try a work around to this problem but I believe franco commented on it in another thread noting that the script could cause problems: https://github.com/luckman212/assign-gua-from-iapd

The topic came up again here: https://forum.netgate.com/topic/177981/no-ipv6-after-upgrade-to-23-01/86

Also, does anybody know what DHCP/DHCPv6 client OPNsense is using? Is it dhcpd? https://roy.marples.name/projects/dhcpcd

https://opnsense.org/blog/

Still talks about the latest release as 23.7.

Not a good mark; gives the impression of a fading/dying project.

So the out of the box default config, with no options enabled, seems to work. By this I mean...

Go to Interfaces and make sure that "Allow manual adjustment of DHCPv6 and Router Advertisements" is unchecked.

If you go to "Services -> DHCPv6" you should see no interfaces listed there.

These are the default, out-of-the-box settings. With this, my Windows 10 and Linux clients are getting ipv6 addresses.

Moreover, the ipv6 addresses of the interfaces that these clients are connected to show up under "Services -> DHCPv6 -> Leases". It should be noted that both of these devices are connected directly to the OPNsense box via Ethernet.

However, the minute I turned on ""Allow manual adjustment of DHCPv6 and Router Advertisements" for one of the interfaces, bounced over to "Services -> Router Advertisements" and tried to set "Router Advertisements" to "Unmanaged" the dhcpd6 service instantly crashed.

I waited 30 seconds and then manually restarted it.

I am currently trying "Assisted" and "Stateless" to see if there is any difference in behavior.



> Do you have a delegated prefix under Interfaces: Interview?

Looks like it.

/56 which is what it should be.

Under "Interfaces -> Overview" the WAN interface reports an "IPv6 prefix" of xxxx:xxxx:xxxx:xxxx::/56



> Now suddenly after we haven't much altered the page since 2015?

The descriptions are fine. They just don't seem to have any effect or behave the way they sound.

"Managed" doesn't result in any stateful assignments.

Neither "Unmanaged" or "Stateless" seem to make SLAAC work.



> It may just be your ISP or PPPoE being more unreliable than usual. But the answer to this is much more complex depending on what options you use (default gateway switching also had a negative impact on the initial 23.7 but users seldomly mention using it).

There was definitely some network instability a few days ago on account of some very bad weather but that seems to have settled.

I'll try some Android devices in the coming days since those only support SLAAC.

Did a wipe and reinstall on my small x86_64 PC (a Protectli Vault FW6C), updating it to OPNsense 23.7.3-amd64, and the good news is that this problem seems to be gone:

https://forum.opnsense.org/index.php?topic=34661.0

The bad news is dhcpd6 has become very unreliable and assignment of ipv6 address to devices is all over the place.

I've scaled back my ipv6 settings to be as simple as possible. WAN is requesting a /56 from my ISP and the "IPv6 Configuration Type" setting on all the interfaces, such as LAN or OPT1, is set to "Track Interface". I can see ipv6 addresses being assigned to the interfaces. Client devices on the network is where the problems creep in.

Observations.

Upon startup or reboot the dhcpd6 service is ALWAYS red/stopped/dead. I don't know if this is a new issue but I don't remember this behavior in 23.1

Touching/changing Router Advertisements settings causes dhcpd6 to crash.

The "Router Advertisements" setting also seem to make no sense. For example, SLAAC should be the easiest option to get working but using Assisted or Stateless has no effect. Both a Windows 10 desktop and a laptop running Debian Linux 12 failed to acquire an ipv6 address. I first cycled the interfaces and then rebooted the router and the computers to ensure everything was reinitialized but the outcome was the same. Assisted or Stateless yields nothing.

I then tried setting Router Advertisements to Disabled. Both Windows 10 and Linux somehow obtained an ipv6 address and websites like ipv6test.google.com agreed that ipv6 was working.

While that seemed to work for a few hours or even a day, dhcpd6 will just randomly die upon which the clients themselves seem to lose ipv6 connectivity, at least according to ipv6test.google.com.

I am going to try some Android devices and see if I can borrow an Xbox just to observe how different operating systems behave but this isn't looking good. ipv6 support seems SUPREMELY sketchy in 23.7.

This is worse than I thought.

I've been messing around with most of the available settings. Managed. Unmanaged. DHCPv6 assisted. SLAAC only.

Doesn't matter.

Within less than 12 hours my IPv6 addresses disappear, replicated on both Windows and Linux clients. Not even 24 hours and the problem rears its head. Restarting the radvd service restores IPv6 connectivity.

I don't remember my IPv6 addresses disappearing this fast some months ago. I think I would have noticed.

I'll reinstall to an older version of OPNsense when I get some time, just to verify, but this looks like a regression to me.

And it doesn't matter if the root problem is the radvd service or FreeBSD. Bottom line is that IPv6 in this release of OPNsense is broken. IPv6 address are being briefly assigned but are somehow getting yanked away/expiring/vanishing into the ether/whatever you want to call it.

> It was a pretty nasty problem but I think it's still fixed.

I don't think so. Pretty sure I just hit on this error today.

Been running on whatever the latest version of 23.1 was in February; fresh install on a Protectli Vault FW6A. Things were working fine for months. I was not using DHCPv6 yet, though I intended to use it later this year since I don't like stateless auto assignment.

Replaced the FW6A with an FW6C about a week ago; fresh install followed by an update to the latest release: 23.1.11-amd64

Things seemed fine for a few days but then I noticed my devices/clients were missing their IPv6 addresses.

Tried all sorts of stuff on the client side, and the clients ranged from Windows PCs to Linux PCs to Android devices to managed switches running whatever embedded OS they use. All had the same problem. So it's not the clients.

Rebooting the router and then rebooting my devices caused ipv6 to reappear (i.e. be assigned) on my client devices.

I then waited a few days for the problem to hit again, which it did. However, instead of a full reboot the only thing I did today was log into the OPNsese router and restart the radvd service. I didn't restart any of my clients or even bring the network interfaces down and up. The Windows and Linux computers regained their ipv6 address.

I went onto the forums and saw that radvd had this problem in the past. Well, it looks like it's back.

This looks like a regression to me, guys. And a significant one at that.