[ previous ] [ next ] [ threads ]
 
 From:  "Chris Dickens" <chris at object dash zone dot net>
 To:  <freaky at bananateam dot nl>
 Cc:  <m0n0wall dash dev at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall-dev] VLAN's and separating traffic
 Date:  Fri, 6 Apr 2007 10:27:24 -0400
Not sure, but it sounds like you're attempting to place m0n0wall in a
Datacenter type scenerio.  It's almost useless in this case.  It's not
necessarily the developer's fault, but as I have been explained the core
routing/NAT routines in whatever foundation that m0n0wall uses cannot
support bouncing connections internally off of the NATs.  For example, if
one customer's mail server attempts to locate another customer's mail
server, it will start with a DNS query to the internet root servers, get the
external IP of the other customer's server.  A connection would be attempted
to the external IP of the second customer's server and the packet will be
dropped because NAT will not bounce internally - only through the external
interface.  This echos the results of my own personal tests/experience.

M0n0wall works in a datacenter, but you need one installation/one server per
customer in these cases to get around this problem.

--Chris

-----Original Message-----
From: freaky at bananateam dot nl [mailto:freaky at bananateam dot nl] 
Sent: Friday, April 06, 2007 8:21 AM
To: m0n0wall dash dev at lists dot m0n0 dot ch
Subject: [m0n0wall-dev] VLAN's and separating traffic

Already sent this to the general list yesterday, but it's probably better
suit here.

----------

Hey there,

I've got an issue which should be easily solvable (I think) if m0n0wall
would like to go in that direction.

First I'll kind of give an explanation what we like/need in order for your
understanding.

The company I work for does hosting (applications/terminals) for the SMB.
This means we have servers running for customers in their own VLAN's. We
also have a SSL-VPN appliance which doesn't have support for VLAN's. In
the future the SSL-VPN appliance will be replaced by it's expensive big
brother which does.

So we would like m0n0wall to do the routing this would mean:

* Allow the VLAN's to access the internet
* Route the VPN to the VLAN based on source (customer x should be able to
route to customer y's vlan)
* VLAN's should not be allowed to communicate between each other, unless
specifically allowed.

As we are starting up and have quite some prospects, the number of VLAN's
will be growing quite rapidly (or so we hope). And this is were the
problem lies.

I think I can narrow the issue down to the fact there is no option to
specifiy the destination interface. Normally one would create a rule 'src
interface vlan x, src subnet vlan x, destination any, protocol any allow'
to give the vlan's internet access. This will however also allow them to
communicate between each other, which is exactly what we don't want.

Now you could a deny rule on every vlan for every other vlan, but this
will become an administrative nightmare very soon. Next to that, with
every new vlan this will become more and more unmanagable.

Now I'm only familiar with linux myself. In linux (iptables to be exact)
this would easily be solved by adding a '-o <dest interface>' to the
firewall rule. Doubt this would be any different in *BSD.

This raises quite a few questions:

* Are there people willing to implement it?
* Is it going to cause trouble with other parts of the m0n0wall scripts
* I don't mind looking into doing it (not really a programmer nor a *BSD
guy), would it be much work?
* Does it fit in the m0n0wall project targets, etc.
* Is the m0n0wall community interested in such a feature (atleast 1 guy I
spoke to on #m0n0wall/freenode is I guess, he's doing it with the deny
rules now but also found it quite hard to manage).

Would also like to point out that although I like m0n0wall as a product I
find it very strange it would allow traffic between vlan's this easily.
I'd like to think they weren't separated for nothing and like to keep it
that way :). Then again, it isn't really the area the product is targeted
for.

Any comments/suggestions are very welcome.

In any case, thanks for the great product and keep up the good work.


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




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