Messages

What i did find was other folks asking for firmware for their intel nics on the intel boards, which then got replied by the intel folks by stating that for in order to get access to the firmware for a  intel nic, you have to sign a NDA approval (!) to even get possibly access to the firmware. This is not a matter of just downloading the fw.

Yeah you would have to go back to SuperMicro.  At least your not dealing with a Chinese device manufacturer who will never provide a firmware update ever.  I'm kind of tired of the Chinese dumping for everything, literal garbage that just goes into my local landfill.

makes me wonder if the firmware version in EEPROM is causing issue? Yours looks like v3.16, other sites seem to show v3.30

This probably makes the most sense, considering OP is adamant the cable is good and it was just a upgrade & reboot scenario.  I have seen this sort of issue on an HP backplane swap-out w/ HP-UX, but it was the other way around (backplane delivered newer firmware, OS was running older driver).  Oddly it rendered as NIC-related latency issues.  The infrastructure team had to bring in HP techs to diagnose.

BrandyWine, there aren't any "allow IPv6" toggles in WAN & LAN interface settings on the GUI.

It's in Interface > Settings.

"Allow IPv6
If unchecked, IPv6 interface configuration will be ignored and all forwarding traffic will be blocked. Use with care."

According to the manual, it should be enabled by default:
https://docs.opnsense.org/manual/interfaces_settings.html#allow-ipv6

https://bugs.freebsd.org/bugzilla/show_bug.cgi?format=multiple&id=287267

It appears to be related to the DoQ feature (that aioquic module is pulled in conditionally).  At least just importing the libraries works fine here:
>>> import aioquic.quic.configuration
>>> from cryptography.x509 import certificate_transparency, verification
>>> verification.VerifiedClient
<class 'cryptography.hazmat.bindings._rust.x509.VerifiedClient'>

That dependency is pulled in via py311-cryptography-44.0.3_2,1 for me.

# pkg which /usr/local/lib/python3.11/site-packages/cryptography/x509/verification.py
/usr/local/lib/python3.11/site-packages/cryptography/x509/verification.py was installed by package py311-cryptography-44.0.3_2,1

I am having an issue where if my AT&T BGW320-500 modem reboots sometimes my router WAN will be given a private IP.

I assume this is happening before the WAN IP is assigned, have you tried dropping the lease on the DHCP server in the modem to 10 minutes (same as IP passthrough lease time)?  I haven't encountered this yet, but only 1 month on AT&T Fiber so far.  I'm happy to be back on AT&T, I went to cable after being frustrated with the high-price & low bandwidth of AT&T DSL (still no fiber).  I got the speed from cable but the provider was awful (they had a lot of outages).

I haven't changed the DHCP server lease, but maybe I will preemptively.

Alas, I must say that I am less than impressed by the new layout. I can hardly read it, partly because of the low contrast, partly because of the small font size of 83%. Instead of readable text, many layout elements take up much space, thus nearly half of the page is full before content starts even on my 38" monitor. Thus, scaling up to 120% is no option.

...

Sad to say that, but this is the first website I had to resort to something like this just to be able to use it decently.

Agree on all points, I was in the middle of using Stylus as well for the first time to fix the stylesheet issues.  Unfortunately there are some issues that require the template to be fixed, such as why unread/updated topics is out there with it's own bar and not part of another navigation bar.  But the excessive padding & margins and massive logos/headers are the biggest problem, on my laptop I had to scroll down a full page just to see the first post.

I am using 24.1.7_4, my WAN is connected to my cable modem (it is a bridged configuration) which OPNsense uses DHCP to acquire the public-facing network address.  I also have a Virtual IP setup as an IP Alias to setup an extra private network IP on the WAN interface and a route to my modem's administration interface.  This is all working fine (any computer on the network behind OPNsense can access the admin interface on the modem) until the modem goes down and the OPNsense DHCP client fails, it appear dhclient-script is wiping the route and the alias while I am expecting it not to do that.

I guess the question is am I using the wrong feature, or is this a bug?

The Certificate

Usually the CN on the certificate is the DNS name of the web host, and I plug in a SAN of DNS:<host name>.  I usually bundle the server cert + intermediate cert and configure that as the certificate on the web server, and the server private key, and then install the root certificate in the OS trusted store.

Usually I miss marking it as a Server certificate.  But I have issued several certs in OPNsense and imported into other services/containers/etc that host web apps and everything just works fine.

Perhaps reloading the config is heavier than expected, but it would also depend on the the size of the config.xml. Additional pairs of eyes are appreciated.

Not really seeing the same problem here (CPU-usage wise, but it is the one with the most CPU time racked up), but I profiled it with xdebug and other than sleep the top two calls are:
- return_gateways_status, with most of the time spent in legacy_interfaces_details/php::exec
- parse_config, with almost all of the time spent in OPNsense\Core\Config->toArray (lots of recursive calls for this one, sounds like it is serializing XML into a PHP array?)

Perhaps a caching option, checking mtime to decide whether to reload?