Messages

This issue appears to be resolved in this patch:

opnsense-patch https://github.com/opnsense/core/commit/c3a24de1b

franco,

Very strange. It doesn't even show that I sent the PM. I sent an email this time, subject=Track interface / Identity association - IPv6 prefix ID already in use.

Edit: I have misremembered, that since I am doing a total gateway bypass from the AT&T gateway, I no longer need the script. You only need that script if you still have the gateway upstream. I kept it for potential future needs, but it's no longer in use on the OPN system. Therefore, my dhcp6 settings are "Basic", no advanced settings or config file overrides in use.

I restored my 25.7.11_2 snapshot, and the issue does not exist there with the same configuration.

Thanks all, I missed this additional patch, solves the issue.

I am curious about this also. From what I can tell, the difference is in the way Floating rules are assigned.

Floating rules are no longer directly specified as Floating. Now, instead you simply assign your rule to more than one interface, and this automatically makes it a Floating rule vs a typical interface rule.

You can see the order process of all rules on a specific interface by pressing the new Inspect button at the top of your rule table. This shows you ALL rules associated with this particular interface, and the sequence they are processed in (you may need to enable the "sequence" option in the filter). This shows Floating rules still processing first, as they always have in the past.

Greetings,

After some testing, I've found that I am unable to Edit or Clone rules that have multiple protocols selected - ie. TCP+UDP. Rules with single protocol - ie. TCP, UDP, ICMP, or * I am able to edit. But all my rules that use TCP+UDP as protocol, I am unable to Edit or Clone. Delete seems to work, though.

When I click the Edit or Clone button on one of these rules from the interface rule list, nothing happens. This behavior does not seem to be producing any log messages, so I'm not sure how to dig down further to find the actual issue.

I have applied these patches:

opnsense-patch ba8194de
opnsense-patch 94081fd82f
opnsense-patch d1519593

But only AFTER I already transferred my rules over, so they didn't do much for me. I decided manually fixing them would be faster than restoring a snapshot and updating again to start over.

franco,

I enabled this option when it became available, but I mistakenly thought the option was moved/removed/set to default in 26.1, because I forgot where it was hiding. I thought it was somewhere else. My mistake, thank you for the correction.

franco,

I have sent via PM the interface dump and my AT&T PD script (it's the same as posted in the GitHub issue linked). I bypass the AT&T device altogether, so I have access to all PDs (16), but only use a handful.

This does very much seem like a validation error. I can go into the interface settings and change something unrelated to IPv6, and I still get the error saying the PD is already in use. I know that it's in use - it's supposed to be.

Greetings,

I switching to Kea IPv4 when it came out, and then IPv6 when that version came out, been using them ever since. I noticed that with IPv6, Kea would assign new addresses in numerical order - ie. ::1, ::2, etc.

There was a patch pushed to GitHub to allow random allocations, and this patch made it into a more recent release (don't remember which one, exactly), which would assign you "random" addresses, but they would remain "sticky", similar to how ISC DHCPv6 server worked.

This option seems to be missing in 26.1. Is it default now?

Greetings,

After updating to 26.1, I was switching my IPv6 interfaces over to the new Identity association option. I am met with an error - You specified an IPv6 prefix ID that is already in use.

No worries, I thought. I'll just change it to an unused one, save, change it back, save again. Changing to an unused prefix ID allows me to save, but I'm unable to change back to my previous (now unused prefix ID - still "in use"). Even after a reboot, still can't revert it - still "in use" (it's not).

I pulled a backup and modified+restored the config file to fix it. It's perfectly happy with the old setting now.

It may be useful to know I'm on AT&T, using a bypass method. AT&T's IPv6 is kind of a joke, you have to script the PDs. I'm not sure if that's relevant here, but I can make that script available upon request.

Check Interfaces > Assignments. Possibly your WG interfaces got renumbered.

Swapped back to the old snapshot - the interfaces are unfortunately numbered the same as they were prior to the update.

I swapped my individual interface installation back to using the Wireguard Group rules, and everything works again.

Greetings,

I have 2 installations of OPNsense - one of these installations has the Wireguard firewall rules in the "Wireguard" interface. The other installation has the Wireguard interfaces in separate OPT interfaces. Both work in 25.1.4.

Upon updating to 25.1.5, the installation using the "Wireguard" interface still passes the VPN traffic, but the installation using the separate Wireguard interfaces is not passing traffic.

Wireguard logs don't show any issues. Firewall logs indicate that the VPN traffic is not being blocked. For now, I've reverted to the pre-installation state with a ZFS snapshot.

Are there any other logs I can collect that might help?

[~$50]

Bypass is the way. Anything else is a waste of effort. If you are interested, I and probably hundreds of others here can assist. I literally did this 2 weeks ago.

I heard about this but I'm not certain it's the approach I want to take (no doubt if this had been available years ago when I was originally building my network I would have done it). Firstly, I don't think I'm on XGS-PON, I'm not sure how much of a hassle it would be to get that changed but it doesn't sound super fun since I really don't need more than 1Gbps. Secondly, my router is a thin client with an Intel PCIe NIC so I don't have an SFP+ port and can't add one, so if I did decide to go this route what would you recommend for converting the WAS-110 with SFP+ to RJ45?

Being on GPON is actually better, because the equipment you need is significantly cheaper. If you are on GPON, you need:

1) a GPON transceiver (SFP) - ~$50 from FS.com, but cheaper models that are known to work can be had.

2) a switch or media converter (puke) that can handle the traffic. Literally any dumb switch with an SFP and RJ45 jack will work. Even an existing smart switch could easily be made to work. Media coverters are junk, in general. I bought one of those first and had pretty bad latency issues in games. Replaced it with a dumb switch and it's perfect now. - ~$20-$80, depending on what ya buy.

The whole deal will cost you $40-$100 USD, depending on which transceiver and switch. It will cost you probably an hour or less in time to get the transceiver set up. The documentation on how to do this is scattered in 3-4 different sites, but I compiled all the instructions into a document for future use.

There can be some gotchas, like if AT&T is still enforcing EAP auth where you are. I'm not sure how common that is any more. I didn't need any certs or anything for my setup, when I did in the past (when I had the BGW210).

Would you mind posting your configs without the keys?

I have experienced this same behavior, with the same fix (refreshing WAN interface). It didn't happen all the time, but enough that I was afraid to remote reboot the firewall.


Ultimately, the solution is to bypass the AT&T gateway, as this is far from the only issue it has (not even talking about the well-known NAT table limitations). It also has some really nasty IPv6-PD bugs as well. Nasty as in it just doesn't work at all since the last update. Completely broken. I don't rely on IPv6, but I do have a dual stack network and I expect it to work... But good look explaining this to the support idiots at AT&T. It's not even worth the effort.

Bypass is the way. Anything else is a waste of effort. If you are interested, I and probably hundreds of others here can assist. I literally did this 2 weeks ago.

Do not do this.