[ previous ] [ next ] [ threads ]
 
 From:  "Chris Dickens" <chris at object dash zone dot net>
 To:  "Chris Buechler" <cbuechler at gmail dot com>
 Cc:  "Mono Dev List" <m0n0wall dash dev at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall-dev] Redesigning m0n0wall filter rules
 Date:  Fri, 8 Feb 2008 10:49:43 -0500
Chris:

I am at a top-tier datacenter paying premium dollars where I'm at.  My
server is located on a shared VLAN with IP addresses assigned out of a
shared subnet of /24.  Head over to www.datacenterknowledge.com, scroll
down the right side under Categories and find "Peak 10" - that's them.
With, I believe, 13 datacenters all across the south-east.  In fact,
another of my customers has a server at one of the lower-tier (high
volume) datacenters ($100 per month boxes) and they use the exact same
configuration.  This is not an uncommon scenerio whatsoever.

If I were to ask my datacenter to give me a hosted/managed firewall and
they chose to implement it using m0n0wall without making any changes to
the routing infrastructure, how would that be possible while assuring
connectivity to all other customers in my subnet and simultaneously
protect me from their traffic?

Please tell me this, I just can't wait to hear the answer.

Oh, and assuming they decided to implement your internal vs. external
DNS architecture using the same LAN infrastructure; How is it humanly
possible to implement if all of those customer's DNS namespaces are
constantly changing as their own customers sign up and cancel services?
Once the customer adds a domain to their DNS server, they must always
tell your people to make necessary internal DNS changes, otherwise they
risk all of your other customers being disconnected from it.  That
sounds like an incredible waste of yours and the customer's time.  I
can't see it being reasonable to consider at all in a datacenter - The
whole system needs to be completely hands-off.  The fact that all of the
other firewalls available support NAT reflection, attests to me that the
need very much exists for the feature and that it should be there.

I do totally realize that a customer with hundreds of domains would have
said routing regime and their own dedicated firewalls, but it's not
uncommon whatsoever to have many small customers with hundreds of
domains who need a workable firewall outside of their own box, and in
typical shared VLAN fashion it's not possible with m0n0.

This will be my final list post about this.  My points are very concise
and valid.  Many others have agreed with me both on-list and off-list.
Apparently the need amongst the top-tier developers in this community is
not the same, so here we are four years later, still lacking the
functionality.

I'm willing to put down the same $200 bounty again if anyone on-list
thinks they can put it in place.  At $250, I can buy a Sonicwall.

--Chris

-----Original Message-----
From: Chris Buechler [mailto:cbuechler at gmail dot com] 
Sent: Friday, February 08, 2008 1:04 AM
Cc: Mono Dev List
Subject: Re: [m0n0wall-dev] Redesigning m0n0wall filter rules

On Feb 7, 2008 10:37 PM, Chris Dickens <chris at object dash zone dot net> wrote:
> It's impossible to fix if you're using m0n0 at a datacenter level.

m0n0wall is used in a ton of data centers, I have it in multiple ones
myself. You don't NAT in a hosted environment like that. Any serious
hosting environment should never NAT customers, whether or not your
firewall supports NAT reflection. Nor should you have multiple
customers' servers on the same subnet where you can't control traffic
between customers. To do things right, each customer needs a routed
public IP subnet even if it's just a /30.

You can still work around it if you force customers to use your DNS
servers.

This isn't an easy problem to properly solve. If you want it so badly,
you need to either up your bounty until somebody is interested,
implement it yourself, or stop griping because nobody here wants or
deserves to hear it. It's certainly not going to motivate anyone to do
this, more likely the opposite.

-Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: m0n0wall dash dev dash unsubscribe at lists dot m0n0 dot ch
For additional commands, e-mail: m0n0wall dash dev dash help at lists dot m0n0 dot ch