[ previous ] [ next ] [ threads ]
 From:  "Patterson, Derek" <dpatterson at gsi dash kc dot com>
 To:  "sai" <sonicsai at gmail dot com>, "Chris Buechler" <cbuechler at gmail dot com>
 Cc:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: Failed m0n0wall implementation, need help...
 Date:  Fri, 21 Oct 2005 07:53:50 -0500
Sorry I've been a bit busy and unable to respond to the original
message.   The real reason that we are migrating from shorewall to mono
for this project is because of the ease of adding new rules and not
needing to stop and restart the firewall each time we add new rules,
nats, etc.  We still use shorewall in our production environments, but
for this what we need is the ability for some not so network savvy
people to be able to add rules without the potential for bringing down
the whole corporate network for extended periods of time.  At this time
it takes close to 15 minutes to restart the shorewall for this, and we
make changes almost daily.  If I was here 24 hours a day, needless to
say that we probably wouldn't be migrating :)
In my opinion m0n0wall is great for some of our less complex
environments, and the fact that it runs in such a small footprint is
attractive to some of our clients.

I'll try to get around to posting some of the XML and error messages I
am getting with the current problem box.  


-----Original Message-----
From: sai [mailto:sonicsai at gmail dot com] 
Sent: Thursday, October 20, 2005 1:33 AM
To: Chris Buechler
Cc: m0n0wall at lists dot m0n0 dot ch
Subject: Re: Failed m0n0wall implementation, need help...

This is OT..
.. but since there is a huge discussion about the future of mono,
could you tell us why you are migrating from shorewall to mono?
shorewall is quite highly thought of and it would be interesting to
find out what you didn't like about it/what you liked about mono


On 10/20/05, Chris Buechler <cbuechler at gmail dot com> wrote:
> On 10/19/05, Patterson, Derek <dpatterson at gsi dash kc dot com> wrote:
> >
> > That's the first problem, even with allowing all
> > traffic out of a VLAN and into another VLAN with a permit all I get
> > traffic that is blocked even without a rule to block it.
> >
> My first guess is the antispoofing rules, and a wrong subnet mask, or
> missing static route, or something of that nature.  need more
> specifics of exactly how this is all setup and what you're seeing
> getting dropped.
> > The bigger problem is that it seems like I can only tell one
> > about the default routes into our datacenter.  There doesn't seem to
> > a global routing option where I can tell all VLANs, interfaces, etc
> > the internal side about the route into the datacenter.
> >
> Your default route is the default route for all networks (from
> m0n0wall's perspective, and assuming it's the default gateway on all
> these VLAN's).
> > Once I create
> > the route on one interface it will not allow it on another
> > even though the other interfaces cannot seem to use that "known"
> >
> That's not true, you probably have something messed up there.
> > And finally the third issue is one that I realize is unsupported,
> > maybe someone has had some success in a work around.  As bad a
> > as it is, some of our devices have to be able to access a public IP
> > the LAN/VLAN side of things.  Unfortunately it isn't an option at
> > point to remove that capacity.
> >
> Will need to route a whole subnet of public IP's over to one of the
> VLAN's.  Otherwise you'll end up with a big mess.
> >
> > As a side question, I have been trying to find a spec sheet that
> > me how many VLAN's m0n0wall can support
> 32 is maximum supported total number of interfaces (VLAN or physical).
>  More than that will likely work fine, though when you get more than
> that you might really slow down the webGUI and it isn't supported.
> > as well as what the network
> > throughput would be for a machine of the class shown above.
> In a typical LAN/WAN setup, that should do 800-900+ Mb.  Throw VLAN's
> into the mix, and I'm not sure.
> > We are also
> > interested in any HA(high availability) news beyond that it's a
> > item.
> 1.3 looks like it's going to end up with CARP and pfsync, but that's
> still yet to be determined.
> > I can provide more details on the specifics, but as this point I am
> > trying to find the right path to take towards resolving these
> >
> a network diagram and your config.xml would be helpful.  this is way
> too complex to easily figure out any other way.
> -Chris
> ---------------------------------------------------------------------
> 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