[RndTbl] Main firewall / router for public facing subnet

Alberto Abrao alberto at abrao.net
Tue Mar 31 00:33:55 CDT 2020

By the way, there's another project I have... which is to consolidate 
all the stuff I've been spreading out a ECC-capable monster machine like 
Trevor mentioned, in order to learn to virtualize things other than 
Hyper-V instances for Windows Images. I even have the monster here - a 
power hog, and quite noisy, but hey! Still, to get there, I first need 
to finish spreading it all out. Heh!

Alberto Abrao

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

More information about the Roundtable mailing list