Messages

By the way...


I have just done this for fun :

You can use static port for TCP and EIM-NAT for UDP by making two rules.

And going to check how it performs in the future instead of just one Static-port NAT Rule which I was using before.

Yeah, that's what my wife and I needed for GTA Online. With just Static Port, we couldn't both play together at the same time. Static Port for TCP and Endpoint-Independent for UDP was the solution. Hopefully it works out for you as well!

When you perform the step on the Certificates page to generate the CSR, it creates a line on that page. Once you have the cert from the CA, you click the Edit button on that same line. There'll be an empty box in the edit page for you to paste in the cert.

At what point are you getting that message? Can you describe the exact steps you're following to generate the CSR and upload the certificate?

Edit: It sounds like you're choosing an option that tells OPNSense to sign a certificate itself (like "Sign a Certificate Signing Request"), which would explain why it thinks it needs a CA key. Instead, you need to edit the line that was created when you generated the CSR. There's a field there for Certificate data where you can paste the cert.

Are you just trying to replace the web UI certificate with one signed by a publicly available CA? How exactly are you trying to do it? I've been meaning to do this myself (but with my own CA), so I just did it and it seems to have worked fine. Here's what I did:

• Added root CA certificate (not key) in System -> Trust -> Authorities. (I didn't have any intermediates, but I think if you do you need to add them as well.)
• Created an entry in System -> Trust -> Certificates with method "Create a Certificate Signing Request".
• Downloaded the CSR.
• Uploaded the CSR to the CA to create the certificate.
• Edit the entry in System -> Trust -> Certificates to add the certificate signed by the CA (just paste the cert block into the field on the form).
• Set the new certificate in System -> Settings -> Administration and save.

Like you I'm largely self-taught and still fairly new to this, but I can at least offer a couple of suggestions:

• Connect a laptop (or other device that you can manually configure) to the Wifi network, configure a static IP appropriate to the network, and then see if it can ping the router's IP on that network. That can tell you if there's any communication getting to the router at all.
• Maybe also try setting up a VLAN 90 access port on the switch and see if your tests change at all there.
• If you're using a centralized management interface for the network hardware, maybe check the switch and APs directly as well and make sure the configs are what you think they are.

I had set this issue aside while I was dealing with bigger things, but with OPNSense 26.7.2 this is now resolved via Endpoint-independent NAT.

• Gaming device IPs added to a firewall alias ("GamingHosts").
• Source NAT set to hybrid mode.
• Add a Source NAT rule:
  
  • Interface: WAN/IPv4/UDP
  • Source address: GamingHosts
  • Endpoint independent: Checked
• I had previously set up a Static Port rule. Not sure if it's still necessary but I kept it for TCP and just removed UDP to avoid conflict:
  
  • Interface: WAN/IPv4/TCP
  • Source address: GamingHosts
  • Static-port: Checked

That's it, no UPnP necessary.

Ok, it's been 2 weeks without incident, so I'm going to (cautiously) call this resolved by the switch from coreboot BIOS to AMI. I did update Protectli; they indicated there's no plan for a patch to coreboot for the VP3200 series at this time. The support person mentioned they wanted to talk to the dev team about it, but I haven't heard anything in the week since, so I'm assuming nothing further is forthcoming. I'll update this if that changes.

Thanks to everyone who pitched in with troubleshooting help and suggestions!

@fornax did you get any statement from them about this?  Are they even working with you to diagnose and root cause, or just pushing you to AMI?

The only time I've reached out to them so far was specifically about the NVM update, but I did summarize the issue, so they did respond to that as well. And I'm glad you mentioned that, because looking back at the email I realize I misread it initially and probably should have tried this sooner. The relevant part is:

At this point we have seen similar behavior in the VP3200 series' coreboot implementation compared to the VP2440's. The VP2440 had a NIC throughput degradation issue that was related to ASPM. (https://kb.protectli.com/wp-content/uploads/sites/9/2026/02/TSB-2025-001_VP2440-ASPM-Network-Interface-Performance-Issue-v2_0.pdf) Our other products don't seem to display this behavior.

I missed that they've actually seen "similar behavior" in my model as in the VP2440, which had a coreboot issue that required an update. So that's entirely on me, I should have pursued that at the time. I was initially going to wait until I considered this resolved and then reach back out to let them know, but I'm accelerating that now.

Wanted to drop in a status update. I'm not ready to declare victory quite yet, but this is the longest I've gone without an incident in quite a while. Possibly it was an issue with coreboot? Fingers crossed. I'll give it another week and then consider this resolved.

@fornax, it has been seen in past that auto-negotiate for 2.5gbps was an issue between certain devices that can do 2.5Gbps. If the WAN shows problem again, try:

sudo ifconfig igc1 down
sudo ifconfig igc1 media 1000baseTX
sudo ifconfig igc1 up

Yeah, I actually had both interfaces hardcoded to 1000 Full before the rebuild, thanks for the reminder.

I also flashed the BIOS from coreboot to AMI, which was a suggestion Protectli threw out there when I contacted them previously.

So the WAN "died", and then you installed fresh copy of 26.7? That's not really a good troubleshooting tactic, because now the issue (if it still exists) is reset.

I wanted to rule out corruption in the install. Also, as this was my first experience with OPNSense, I did a fair amount of poking around and playing with settings, so I wanted a fresh start to rule out any possibility of lingering config weirdness. And those are ruled out now, as I had another incident last night.

Is WAN router or LAN switch 2.5G capable?

WAN router yes, LAN switch no.

Even on 15.1 (26.7), verify EEE settings and look for events.

Code Select Expand

root@scutum:~ # sysctl -a | grep igc | grep eee
hw.igc.eee_setting: 1
dev.igc.1.eee_control: 1
dev.igc.0.eee_control: 1
dmesg and syslog have never shown any random events. Everything is associated with bootup, manual interface bounces, or other actions on my part (eg config changes).

And you are running latest NVM for the 226's ?

As of post #29, yes.

First time for everything, I guess... yesterday I had an issue that was only resolved after bouncing the WAN interface instead of LAN like every other time. In a fit of frustration I reinstalled the OS today, so it's on a fresh 26.7. That should rule out OS corruption or weird config issues from me tinkering with things. I also installed the -igc2 kernel. Will continue to monitor.

I did have another incident with the -igc kernel the other day (attempted to post about it with logs but it looks like it didn't go through?). There were no syslog events associated with anything other than the reboot after installing the kernel or the manual interface bounce.

Try disabling vlan tagging from offloading, this brings it back to kernel.

Code Select Expand

ifconfig igc0 -vlanhwtag -vlanhwtso -vlanhwcsum

Interesting find and definitely worth a try, doing that now.

A kernel patch related to your issue has been developed, assuming you're on 26.1.11_6, you can install it with:

# opnsense-update -zkr 26.1.11-igc

Sure, I'll install that now. What's the change(s) in this one?

May I suggest not involving this game into these issues ?

Yeah, I know the game is buggy as hell. If it was the only issue I was having I wouldn't be here. But it's a useful canary; as I usually check into the game fairly early, it's often my first indication that something's going wrong. And the fact that bouncing the LAN interface on the firewall makes it immediately start working again (and the fact that I never had these issues before switching to the new firewall) leads me to believe this particular issue isn't the game's fault.

No indicators if your issue is WAN or LAN side.

I haven't dug too much into the WAN side because only bouncing the LAN interface has any effect. I've tried bouncing WAN first on a few occasions and it never changes anything.

DHCP stops working, so just for the LAN side?

Yes, the firewall's DHCP client works just fine, it's the LAN-side clients on one or more VLANs that stop working.

VLANs? How do you mean? Two i226's and VLAN's on LAN side, so you run .1q or your VLAN's are L3 ?

Yes, 802.1q VLANs on the LAN side only.

Can you SSH into the FW using a non i226 iface? I suggest you do that and start monitoring stuff. Run a ping to the FW LAN IP address, then wait for the no-traffic issue to arise, what does the ping show?

Start a 2nd ssh session, then
dmesg -w | grep -E 'igc'

see if any kernel messages arrive when your issue happens.

The firewall has just the two i226-Vs. I could set it up to run in the background like the previous one, though. FreeBSD's dmesg doesn't appear to have a follow option, but neither dmesg nor the syslog have never shown any indication that they see anything wrong anyway.