Hi
Maybe bit late, but here is my general setup which may be something in your direction.
The evil WAN (cable-modem) directly attached to the core switch. The core switch get all untagged packages and assign the VLAN 666 to it. from this point the evil VAN traffic is limited to this VLAN.
This is the minimal setup on the WAN side.
Then i.e. with an ESXi host on the other side running a pfSense vm appliance, just route the evil 666 WAN tagged to the ESXi vSwitch and to a dedicated WAN portgroup configured to VLAN 666.
The pfSense VM has two virtual interfaces, one LAN and one for WAN. The WAN interface is attached to the WAN portgroup and the LAN interface is attached to a LAN portgroug.
In this case pfSense can act like any physical installation as router for NATing etc.
The cool thing is… if you have multiple host and using vSphere you can move the running pfsense from one host the the other without any interruption of the WAN link to the network :)
This all with just a single NIC. I use an Intel NUC by the way for running my minimal required VMs like the pfSense. So if I'm on holidays, I just shutdown all other hosts which consumes a lot more of power and still can access by VPN and do some stuff.
This setup is also useful if have to debug your ISP connection... just attach a VM directly to the WAN... debug.. and then just destroy the VM to be sure to not contaminate your LAN.
Additional Note about security:
My first fear was, that on a core switch failure due any reason and he is falling back to his default configuration, I would have the evil WAN in my local network. Depending on how much you trust your switch, you can minimize the chance for this by putting a cheap VLAN capable switch between your cable modem and your core switch. I did this, just let the cheap VLAN capable switch tag everything on the "WAN" port to VLAN 666. Then configure the core switch to only allow tagged VLAN 666 on the incoming port.
With this setup, only the hopefully rare case where both switches resets to the default configuration, would be a BIG problem.
In the case of the cheap switch fails and sends unexpected untagged packages, the core switch would drop it on the incoming port.
In the case of the core switch fails and reverts to default configuration, the incoming port would not allow the incoming tagged packages.
For me it's the few bucks worth for the additional cheap switch to handle this cases, because even the switches runs fine... the human factor (me in this case) is the biggest thread :)
I don't have to care if I reset one of the switches to factory default due any reason.
For sure most would say, don't let the traffic from the internet flow over the core switch, but in my home lab i don't care, as long as you know what you are doing.
And as always, the human is the biggest risk here.
Hope this help someone or maybe someone can give some feedback about this setup besides it's not best practice :)
It's running now for about 2 years without any problems.