I am not overly happy with my current firewall setup and looking into alternatives.

I previously was somewhat OK with OPNsense running on a small APU4, but I would like to upgrade from that and OPNsense feels like it is holding me back with it’s convoluted web-ui and (for me at least) FreeBSD strangeness.

I tried setting up IPfire, but I can’t get it to work reliably on hardware that runs OPNsense fine.

I thought about doing something custom but I don’t really trust myself sufficiently to get the firewall stuff right on first try. Also for things like DHCP and port forwarding a nice easy web GUI is convenient.

So one idea came up to run a normal Linux distro on the firewall hardware and set up OPNsense in a VM on it. That way I guess I could keep a barebones OPNsense around for convenience, but be more flexible on how to use the hardware otherwise.

Am I assuming correctly that if I bind the VM to hardware network interfaces for WAN and LAN respectively it should behave and be similarly secure to a bare metal firewall?

2 points
*

Am I assuming correctly that if I bind the VM to hardware network interfaces for WAN and LAN respectively it should behave and be similarly secure to a bare metal firewall?

Correct.

I did that in my old playground VMware stack. I’ll leave you with my cautionary tale (though depending on the complexity of your network, it may not fully apply).

My pfSense (OPNsense didn’t exist yet) firewall was a VM on my ESX server. I also had it managing all of my VLANs and firewall rules and everything was connected to distributed vSwitches in vmware… Everything worked great until I lost power longer than my UPS could hold on and had to shut down.

Shutdown was fine, but the cold start left me in a chicken/egg situation. vSphere couldn’t connect to the hypervisors because the firewall wasn’t routing to them. I could log into the ESX host directly to start the pfSense VM, but since vSphere wasn’t running, the distributed switches weren’t up.

The moral is: If you virtualize your core firewall, make sure none of the virtualization layers depend on it. 😆

permalink
report
reply
4 points

Thanks for the quick reply.

What about the LAN side: Can I bridge that adapter to the internal network of the VM host somehow to avoid an extra hop to the main switch and back via another network port?

permalink
report
parent
reply
3 points
*

May depend on your hypervisor, but generally yes. Should be able to give the VM a virtual NIC in addition to the two physical ones you bind, and it shouldn’t care about the difference when you create a LAN bridge interface.

Depending on your setup/layout, either enable spanning tree or watch out for potential bridge loops, though.

permalink
report
parent
reply
1 point

If you have a managed switch you can also just do vlan tags for your wan and not have to pass any nics to the VM.

permalink
report
reply
2 points

Yeah, I though about that, but that sounds like a footgun waiting to happen.

permalink
report
parent
reply
1 point

I’ve been doing it for years, no issues. It’s fairly common in the enterprise as well.

permalink
report
parent
reply
1 point

I use a Proxmox Cluster and assigned dedicated NICs to my OPNsense VMs (also clustered). I connected the NIC ports I assigned to the OPNsense VMs directly with a cable and reserved it for CARP usage. I can easily download with 1GB/s and the VMs switch without any packet loss during failover, 10/10 would do it again.

permalink
report
reply
1 point
*

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters More Letters
DNS Domain Name Service/System
HA Home Assistant automation software
~ High Availability
PCIe Peripheral Component Interconnect Express
VPN Virtual Private Network

4 acronyms in this thread; the most compressed thread commented on today has 9 acronyms.

[Thread #638 for this sub, first seen 28th Mar 2024, 20:45] [FAQ] [Full list] [Contact] [Source code]

permalink
report
reply
2 points

So you’re planning to reuse the same hardware that the firewall is running on now, by installing a hypervisor and then only running opnsense in that?

permalink
report
reply
2 points

It is more powerful hardware with much higher single thread performance which should help with OPNsense networking; Ultimately to allow more than 1gbit WAN input which my current firewall hardware is incapable off, although that is still in the future.

But I feel like I could utilize this hardware better if it was running something other than OPNsense, thus the idea to make it run it in a VM.

permalink
report
parent
reply
2 points

Ah ok. I’ve done opnsense and pfsense both virtualized in proxmox and on bare metal. I’ve done the setup both at two work places now and at home. I vastly prefer bare metal. Managing it in a VM is a pain. The nic pass through is fine, but it complicates configuration and troubleshooting. If you’re not getting the speeds you want then there’s now two systems to troubleshoot instead of one. Additionally, now you need to worry about keeping your hypervisor up and running in addition to the firewall. This makes updates and other maintance more difficult. Hypervisors do provide snapshots, but opnsense is easy enough to back up that it’s not really a compelling argument.

My two cents is get the right equipment for the firewall and run bare metal. Having more CPU is great if you want to do intrusion detection, DNS filtering, vpns, etc. on the firewall. Don’t feel like you need to hypervisor everything

permalink
report
parent
reply
3 points

Yeah, I did do a test-setup with OPNsense in a VM today and it mostly works. But I see where you are coming from and usually I also prefer setups that are easier to maintain and with less footguns. I guess I’ll sleep over it first.

permalink
report
parent
reply

Selfhosted

!selfhosted@lemmy.world

Create post

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.

Rules:

  1. Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

Community stats

  • 3.4K

    Monthly active users

  • 3.3K

    Posts

  • 71K

    Comments