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?
You must log in or # to comment.
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]
Try VyOS. I run it on APU2 myself. No GUI no convolution.
I keep wanting to look into that one. Can it be easily extended from the Debian repositories?
nope, it is very deeply customized debian. Need to be installed from scratch.
I come from VyOS and really liked it, but still prefer opnsense for the GUI, constant updates and plugins. VyOS started losing appeal once they opted for subscription stable iso access (even if they did give me a free subscription for some comment contribution in their repo). Also, I have to admit, that VyOS needs a fraction of the resources needed by opnsense.
Open source projects need to make money somehow. I found VyOS method quite acceptable. They giving good instruction and tools to build your own stable ISO. So do not be lazy or contribute somehow. Unfortunately their paid support costs too much. I was considering trying to push VyOS to be used as virtual router at my work, but it costs more than Cisco C8000v
I’d been running OPNsense in a VM for some time. I used xen as a hypervisor, but that shouldn’t really be a requirement. Passed the nics through and it was golden! All the benefits of a VM - quick boot-up, snapshots on the hypervisor - it’s truly glorious :)
Sounds great. What about hardware acceleration features of the NIC? I read somewhere that its better to disable the support for that in OPNsense when running it in a VM?
Another option is to pass through the PCIe devices to the VM.
I just saw that option. What would be the advantages and disadvantages of this?
I guess when I pass the actual NIC device the hardware acceleration should work?
Edit: Looks like my host system does not support this, at least that is the error I get when trying ;)
For one you offload the entire processing and driver handling to the VM, so if the OS wants to do something funky, it can.
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. 😆
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?
