[RndTbl] Main firewall / router for public facing subnet
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!
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
> 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
More information about the Roundtable