<div dir='auto'>Avoiding GUIs means you want to go one of two paths: OpenBSD with of(4) or some very-up-to-date Linux distro like Fedora with the latest nftables.  Skip everything else.<div dir="auto">But why do you want to avoid a GUI completely?</div><div dir="auto">-Adam</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mar. 31, 2020 00:28, Alberto Abrao <alberto@abrao.net> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">That could be a way, but I was more inclined to do it the way I assume -  <br>
and the word is assume, as I have no idea - an ISP like Shaw is doing  <br>
it: they assign addresses that are public facing to machines they have  <br>
no access to, but they filter what goes in and out no problem. As we've  <br>
discussed a few months ago, it's what goes for residential IPs. <br>
<br>
It's more about the know how than just getting something that works. I  <br>
really need to step up my networking game. My setup here is nothing more  <br>
than a lab. As far as I know, a managed router would be enough for most  <br>
of my QoS needs, and the firewalls are doing their jobs on the two  <br>
servers (using static IPs) + the internal network router (which grabs a  <br>
residential DHCP address). But that would be too easy, I guess? <br>
<br>
And I am totally with you on the difference between small companies'  <br>
requirements (and budgets!) compared to big ones. Hell, I used to set up  <br>
OpenWRT routers with samba shares to replace aging Pentium III boxes  <br>
running XP for Samba duties *AND* the pwned ISP-supplied router that had  <br>
its DNS hijacked, and that was around 2015. The hard disk on that beige  <br>
case alone was on borrowed time...hardcore. Of course most Canadian  <br>
companies don't need to do something that extreme to save a buck, so you  <br>
can order something really nice and get the job done with room to spare,  <br>
ticking all the boxes, right? Nah... I am still SERIOUSLY looked down  <br>
upon when I argue that my solution meet the requirements set, yet cost  <br>
1/10th of what was quoted by an "enterprise" vendor, and I am not even  <br>
exaggerating. There's the solution of the issue and the process of  <br>
selling it, and the more expensive it is, the more enterprisey it  <br>
sounds, right? And THAT'S why I am trying to look pretty... =D <br>
<br>
I am not tied to any particular OS, as long as 1) it's open (e.g. not  <br>
Windows) and 2) no GUIs. My plan was to have something that would do QoS  <br>
and, after that is working, study how to move the firewall duties to it. <br>
<br>
I must make it clear that I don't expect anyone to walk me through it,  <br>
hold my hand or anything. Some recommended reading would be all it  <br>
takes, even if it's a monster tome. And I can't think of a better place  <br>
to ask for this than here, otherwise I will have tons of people selling  <br>
me Cisco stuff or whatever. <br>
<br>
And, once again, thank you everyone for chiming in. I really appreciate it. <br>
<br>
Alberto Abrao <br>
204-202-1778 <br>
204-558-6886 <br>
www.abrao.net <br>
<br>
On 2020-03-30 11:06 p.m., Trevor Cordes wrote: <br>
> On 2020-03-30 Alberto Abrao wrote: <br>
>> Doing it for a single external IP is manageable to me, the thing is <br>
>> the leap in doing it for multiple public IPs. I do know I have some <br>
>> heavy reading ahead, and I look forward to it. Any recommendations <br>
>> are very much appreciated. <br>
> That part is easier than you think.  I haven't done it yet, mainly <br>
> because I'm too cheap to spring for a plan with multiple statics, but <br>
> I'm pretty sure you'll just set up your single interface to listen on <br>
> multiple IPs.  Then use routing and/or packet-mangling-de-jour methods <br>
> to forward them to the correct internal boxes.  After firewall-checks, <br>
> of course. <br>
> <br>
> Easy for statics, but you might not be able to do more than 1 of your <br>
> DHCP dynamic on that interface, though??  Unless you can setup a 2nd <br>
> "fake" MAC on the same interface?  Others can chime in. <br>
> <br>
>> I used to do one-box-for-everything as well, mostly because I didn't <br>
>> have a lot of equipment to begin with. However, I see lots of people <br>
>> talking about security, and I can see having things on separate <br>
> I'm of the opinion that if you're a wizard it really doesn't matter if <br>
> it's all one box or not.  If they p0wn your firewall, chances are <br>
> they'll then hop into whatever internal, less protected, box they want <br>
> anyhow without much trouble.  The key is to not get p0wned.  I'm talking <br>
> from a personal and micro-business standpoint: for corporate of course <br>
> you'll want to throw money at separating everything. <br>
> <br>
> It's hard enough, and expensive enough, trying to keep X quality (read: <br>
> ECC) boxes going, let alone X+1 boxes (and more +1's for every new <br>
> task).  I'd rather have 1 boss ECC system that I know won't give me <br>
> grief do everything than a handful of cheap / small / esoteric boxes <br>
> (probably with no ECC).  It's my philosophy.  I understand it's not <br>
> shared by the writers of best practices.  YMMV. <br>
> <br>
> If you've already learned OpenBSD and like it, of course stick with it, <br>
> unless you've hit limitations.  As for iptables vs pfsense, I've yet to <br>
> run into a scenario tc/iptables/etc can't do, and I do some pretty <br>
> wacky esoteric stuff on many boxes.  However, here's a great example of <br>
> why you'd like Fedora rather than CentOS: the newer, handy iptables <br>
> features are generally bleeding edge and only to be found in distros <br>
> that give you the bleeding kernel.  If you're on the typical <br>
> multi-year-old RHEL kernel then you may find that what you want to do <br>
> isn't possible. <br>
_______________________________________________ <br>
Roundtable mailing list <br>
Roundtable@muug.ca <br>
https://muug.ca/mailman/listinfo/roundtable <br>
</p>
</blockquote></div><br></div>