Messages

Can't answer your question, but I am curious why you would want to switch away from a working setup that will continue to be supported and improved by OPNsense in future versions?

Just so I am clear on your issue.

At the OPNsense level you want to bridge a passed-through X550-T2 port (LAN) Physically connected to a switch with a Proxmox virtual-only linux bridge using model virtio? So line speed to physical lan and Paravirtualized speed to Proxmox VM's through a single OPNsense bridge.

At the proxmox level, I assume this Linux bridge does not have an assigned Port/Slave (so not physically connected to anything)?

This OPNsense Bridge (passed-through X550-T2 port (LAN) + proxmox Net1) functions when the Proxmox Network device defined in the OPNsense VM is Model Intel E1000, but the Bridge fails if the Proxmox Network device defined in the OPNsense VM is Model Virtio?

AND this setup works correctly in PFSENSE Bridge (passed-through X550-T2 port (LAN) + proxmox Net1 Model Virtio)?

Have you tested to be sure that a proxmox Virtio network device in promox functions at expected speeds alone outside this bridge?

I would retry using a q35 based OPNsense VM. Latest Nonsubscription promox has moved to QEMU 9 as well and that may require a reboot to move the VM over.

Disable Secure Boot before the VM or install.iso starts.

https://forum.proxmox.com/threads/disabling-secure-boot-for-vm.125640/post-547967

Use vmbr2 if you want your VM/LXC to be protected by the opnsense firewall. vmbr0 is direct to wan most likely.

ISC DHCP Server has reached EOL

Now that the version of ISC DHCP that OPNsense uses is EOL as of this release in 22.7.6, what are the plans going forward?

Any consideration to making the move to ISC Kea DHCP server?

Would also be great, if OPNsense was finally able to function as a DHCP server for multiple subnets and VLANs over a single defined interface/link in the context of an L3 switch.

So have Adguard on port 53 and Unbound on port 53530. So everything hist adguard first.

I used Adguard Settings/Client Settings to segregate lists of clients IP's and MAC addresses that bypass the global Adguard settings and get passed through directly to unbound as well as other client lists, for example younger kids, that get more stringent settings.

Solution picked from Adguard bug thread:


- SSH in your opnsense box
- Send this command, change USERNAME:PASSWORD to your Login/Pass of Adguard
- Specify port if you changed the default

Code Select Expand

curl -H 'Content-Type: application/json' -X POST -v 'http://USERNAME:PASSWORD@127.0.0.1/control/update'

Can confirm this worked - but, in my case, I had to use the IP address of my AGH box on my LAN, localhost didn't work.

Updated to .b17 successfully, no apparent loss of data.  Thank you!

Same here, but had to add the IP address and port for it to work for me. Thanks, that was much easier than I expected.

Might be an issue on the adguard update server side. I get the same error for the v0.108.17 that came available today. I would give them a few hours to get things sorted and try again.

Under System -> Settings -> Logging -> Preserve logs (Days) what do you have there? Some have stated the default changed to 31 days with the 22.* series. Some have needed to decrease this to 7 days or less.

@rafaelreiser have you tried to run the opnsense VM either in ubuntu kvm/qemu or Proxmox without nic passthrough yet? Using a virtualized cpu and paravirtualized nics (virtio) seems to be about the only combo left to try.

I've also run OPNsense VM on Proxmox for years now without any sort of crashes like this, as have many others on the Proxmox forum I frequent, so no inherent generalized compatibility issues there on the software front.

Proxmox is just some binaries on top of a slightly modified Debian install. In fact, you can install Debian and then install proxmox to that.

Regardless of how you chose to install initially, you can have Docker running directly on the Debian/proxmox host easily as getting it running on Debian. Most people don't as installing docker on a lightweight proxmox Debian/Ubuntu/alpine LXC takes so few additional resources, but you can.

https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_install_proxmox_ve_on_debian

You would lose little to nothing virtualizing the cpu and host and really it might just be temporary to trouble shoot if the host nic or cpu direct interaction with FreeBSD are the issue. It's more about systematically checking off those boxes of what might be the cause.

VirtIO on many host can do 10-20g of throughput and should have no issues with 2.5g.

Also similar to https://forum.opnsense.org/index.php?topic=29845.0?

Are you virtualizing the VM CPU as KVM/Qemu or using host? Have you tried not passing through the network adapter and using VirtIO instead, which should handle 2.5g fine? Either of those could narrow down the issue.

Starting to suspect something in this hardware combo is giving the underlying FreeBSD base fits. If virtualizing the 2.5g nic or the CPU (or both in combination) stops the Freebsd Kernel panics that should point in the general direction of an answer. Seems as though RAM issues would affect the host and VM.

Interesting, watching on GitHub.

Im assuming the FW needs rebooted after this? Also wireguard go service fails to start, assuming that's OK as kmod is running and everything works just fine.

I do not remember on the first question, sorry.

Yes on the second question, that is the expected behavior. If the Red/stopped WireGuard-Go status bothers you on the dashboard services widget (it did bother me) you can click the edit (pencil) button for that widget and specify that wireguard-go status is no longer shown. Out of sight, out of mind was my fix.