Rocket Surgeon

  • 8 Posts
  • 213 Comments
Joined 1 year ago
cake
Cake day: March 10th, 2025

help-circle

  • Cool. Yes, this looks reasonable. It looks logical.

    So, my main recommendation is consider the use of virtual bridges to manage the network instead of passthrough. And I recommend installing and using the OVS style virtual bridge.
    https://pve.proxmox.com/wiki/Open_vSwitch

    This gives you flexibility going forward. Say you want to run something out in the DMZ instead of behind the firewall, well you just attach that VM to the DMZ bridge instead. And it gives you an easy way to provision network for VMs. You just attach them to the LAN bridge.

    (RoaS is a terrible name. Router on a Stick. It means your router is on the same switch as its clients, and all the communications go up and down that one port. It’s a perfectly legit way to manage a network, but sorta ugly and not what you are doing with your fancy 3-port rig. :)



  • There’s a few things we don’t know here.

    • Are you hosting more VMs on Proxmox that need network via a virtual switch?
    • Are you providing network to other physical devices as well via a switch, so you need to output to that?
    • Do you want OPNsense to be your gateway and assign IPs, or do you have a router?
    • As you have 3 NICs and sound like you want to use them, let’s assume you aren’t doing RoaS, but this could all be done on one (very busy) NIC.

    There’s nothing wrong with your plan, but that’s not how I would do it.
    I don’t pass through NICs. I bond them or I bridge them.
    In a virtual world, this sort of task is done with virtual switches. OVS switches at my job.
    OVS is a lot easier to use than oldskool linux bridges that come installed with Proxmox. There’s already a dropdown in Network where you can build with OVS objects, but you need to add the package.
    apt install openvswitch-switch

    • MGT. For your setup, I might consider (the onboard!) eth3 as my mgt NIC. That might be handy some day if you have to remove that card. Your server will still be online.

    • DMZ WAN. I would run the WAN line straight to eth1. Add eth1 to a ‘dmz’ virtual switch. Add the OPNsense WAN leg to this dmz virtual switch, so the OPNsense (and nothing else) can directly talk to the upstream router.

    • LAN Virtual. Create a ‘protected network’ virtual switch. Add the OPNsense LAN leg to this virtual switch. VMs can be a member of this downstream protected network and access any services provided by the OPNsense.

    • LAN Local. If you need to share the OPNsense protected network back out to other devices, add eth2 to to the protected network switch, and ethernet cable out from eth2 to a dumb switch. Plug other external devices into the dumb switch, and they will be downstream from and protected by your OPNsense, accessing its services.

    Feel free to ignore me here. I build a lot of big things, so I use enterprise-scale techniques. There’s nothing wrong with your pass-through plan.
    And … you can do this! I have a somewhat similar setup on my laptop with HyperV, so I can distribute wired (work VPN) and wireless (everything else) internet to guest VMs and the main OS. I made two virtual switches in HyperV.

    • The first switch gets exclusive access to my NIC attached to my VPN device. This is the OPNsense WAN leg.
    • The second switch is the OPNsense LAN leg and VMs are members.

    Good luck!