Greetings all! I hope everything in your world is good.
I am running 26.x on a "white box" Xeon-based system with 32GB of RAM. This device also has 2 SFP ports, and several copper ports available.
I am using the SPF ports for WAN coming in and uplink to a managed switch for my LAN. This is achieved by completely removing the BGW-320 box that AT&T provides from the equation, and running a script (via 8311 on Discord) that customizes an XGS-PON stick from fs.com to "emulate" the BGW-320.
AT&T (fiber) is providing the connectivity and I have signed up for a plan that is 2Gig up/down. I also pay an additional monthly fee for a 5-pack of static IPs that I have yet to leverage, but are looking to utilize ASAP. It is my understanding that AT&T delivers the initial IP address via DHCP, but then the static IPs I have assigned to me are available to allocate as I need to. I want to isolate a home lab, as well as some other services on different IPs apart from my "production" network.
That leads me to my need for specific advice on how to actually implement one or more of these static IPs. What are best practices in this scenario for both the logical and physical configuration? Can I even configure the available copper ports on the white box? If so, how do I literally do this within the current configuration?
- OR -
Should I bring the WAN connection on the SFP module into an entirely separate smart/dumb switch and manually assign the static IPs to each of the remaining SFP ports on this new switch I would add? I'd actually prefer to use a "dumb" switch for this so that it is essentially invulnerable to being compromised as it would be wide open to the internet.
Thanks, I am just having a difficult time conceptualizing the practical and theoretical application of this configuration modification, and I would really appreciate specific configuration steps to take within OPNSense to realize this future state of use.
You can use virtual IPs on the WAN interface even if the initial IP is obtained through DHCP. While VIPs can be used to gain access to a WAN bridge like a modem or ONT, you can also create additional routeable IPs like that.
The normal way to go forward would be to place the real servers behind those IPs behind OpnSense in one or more separate (V)LAN(s).
With that, you can do whatever you like with the WAN IPs, like port-forwarding them to the internal hosts or simply using a reverse proxy, just as you please. By using a reverse proxy, you can also lay the burden of gettings ACME certificates on OpnSense.
I do it like that and I use separate VLANs for any DMZ host, such that when one gets compromised, it cannot reach any other DMZ host directly. Also, my DMZ targets usually are VMs or LXCs on a trunked virtualisation host.
You can even do both OpnSense and your VMs on the same host using that concept, see this (https://forum.opnsense.org/index.php?msg=220167). If you do not have to pay monthly for each physical machine, like in a home setup, I would prefer to separate OpnSense and the virtualisation host, however.
Quote from: StarsAndBars on Today at 08:03:04 PMI'd actually prefer to use a "dumb" switch for this so that it is essentially invulnerable to being compromised as it would be wide open to the internet.
As long as you don't misconfigure the access to the webGUI and SSH of the Managed Switch there should be no downside for using one IMHO :)