<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>