[ previous ] [ next ] [ threads ]
 From:  "Chris Dickens" <chris at object dash zone dot net>
 To:  "Tonix \(Antonio Nati\)" <tonix at interazioni dot it>, "Mono Dev List" <m0n0wall dash dev at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall-dev] Redesigning m0n0wall filter rules
 Date:  Thu, 7 Feb 2008 15:33:32 -0500
I asked for NAT port bouncing years ago and m0n0wall still can't do
that.  Heck, I offered money for someone to fix the problem - offer
since withdrawn because there's apparently a lot of resistence in this
crowd to making any change to Monowall.

Lacking this ability which is available in virtually every other
appliance I've ever seen pretty much makes it useless for a datacenter
class firewall solution.  Thankfully I've managed to put in enough
work-arounds that it's not causing me much trouble in my setup with
multiple virtual servers.  You may find that if m0n0wall doesn't suite
you as it is, Tonino, then you'd be better to move along.  From what I
can tell, everyone here uses m0n0 for the captive portal with WiFi
hotspots and is raking in money selling it to whoever will pay them to
put them in.  Nobody doing anything really serious.

I stay subscribed to the mailing list, hoping that one day someone will
find a real solution and I can be off of version 1.0.

*Sigh* (Bracing for impact of flames coming in very soon)


-----Original Message-----
From: Tonix (Antonio Nati) [mailto:tonix at interazioni dot it] 
Sent: Thursday, February 07, 2008 2:58 PM
To: Mono Dev List
Subject: Re: [m0n0wall-dev] Redesigning m0n0wall filter rules

Lee Sharp ha scritto:
> Tonix (Antonio Nati) wrote:
>> If monowall people is so closely bind to the WAN, LAN, OPT1 model, 
>> there is very few to discuss. Then it's time to start a m1n1 project,

>> with wider views.
> I am not sure where you got this, but it ain't from us.  Many of the 
> core people on this list have at least one (or many more) firewall 
> with 10+ interfaces on it.  However we often support people that have 
> multiple interfaces for absolutely no reason.  One guy wanted to 
> bridge 5 interfaces because he could not afford a switch!  So we teach

> the LAN WAN Opt1 model to beginners because they are beginners.  We 
> also use the inbound model because it is simple to understand.  
> Complexity breads mistakes which lead to insecurity.  The Pix is a 
> very secure firewall, but is often deployed insecurely by people who 
> do not understand it. Not a surprise as the Pix is a lesson in user 
> unfriendliness...

So, you think helping people giving less choises.
Add a system flag about which kind of rules can be enabled: inbound,
outbound, mixed.
Give the opportunity to make more, and each one can chose his own model
(based on his own experience).

>> But if you consider that this firewall is very used because of the 
>> speed, and because of the speed is used in a lot of big 
>> configurations, where people has:
> [snip vlan party]
>> than you may see that
>>    * ONE  outbound rule written in the server VLAN eliminates the
>>      for other 11 rules which should be written in each of the other
>>      interfaces.
> Only if all other interfaces are wide open inbound.  This is not what 
> I do on any system I manage.

Why??? You don't need to open inbound on other interfaces for allowing
outbound. It depends on the position of the rule.

> [ snip ]
>> I hope monowall is ready to make the step to be a more complete 
>> firewall.
> We have made a conscious decision to not make m0n0wall the HP 
> All-In-One-Printer of firewalls.  m0n0wall is meant to be lean, mean, 
> and above all secure.  So far what you have proposed gives some small 
> convenience at a substantial cost in complexity and security.
> However, the biggest problem is that you seem to not want to consider 
> that there are other ways of doing this.  It would be easy to add a 
> script on each interface page, "Create reciprocal inbound rules."  
> When you click that it gives all the usual fields but the interface 
> field would allow you to ctl-click all or some of the interfaces.

In which position in the other interfaces lists? Before all? After all?

> As to management, I agree that a page that would allow you to view all

> interfaces filtered by a given parameter would be nice.  This only 
> requires some php programming, and NO CHANGES TO THE CORE OF M0N0WALL.

Also what I ask requires only PHP programming. No change to the core,
just a different way of writing rules.

> Also there is a m0n0wall management project that could allow you to 
> write a firewall client to make rules however you want them. However, 
> if you are dead set on core changes, then by all means fork it.  There

> are several forks of m0n0wall, and all have made a positive 
> contribution. (FreeNAS, pfSense, AskoziaPBX)  You can even find the 
> devs of those projects all over the m0n0wall lists.  You may have 
> something a lot of other people want.  I, however, am not one of 
> them.  And judging by the lack response here, neither are a lot of 
> other developers.  However, (I seem to be using that word a lot) if 
> you do fork the project, I would give you any information and help 
> that I could.  I am sure that most of the other people here would as 
> well, if you keep us on good terms.

I appreciate your help, but I'm not willing to fork, unless I have no
choice (just because I have too much work.to do on other products).
Before forking I will consider also other open source firewalls, as well
as funding m0n0 (or pfsense) for making what I ask.



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

        Inter@zioni            Interazioni di Antonio Nati
   http://www.interazioni.it      tonix at interazioni dot it

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