[ previous ] [ next ] [ threads ]
 From:  bmah at acm dot org (Bruce A. Mah)
 To:  "Federico Krum" <federico at thehost dot com dot ar>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Servers with public IPs
 Date:  Fri, 03 Oct 2003 21:42:11 -0700
If memory serves me right, "Federico Krum" wrote:

> I have wrote an email to the list before asking for the configuration to =
> use monowall as a firewall using public IPs on the DMZ insted of nating.
> I have read Bruce Mah  site for the patches... but found the =
> disadvantage that the implementation is not fully integrated with the =
> web interface, have to patch the distro each time that new things come =
> out and Im not always sure that the patches can be applyed over new =
> versions.

I agree this is suboptimal but there's basically nothing else I can do
unless Manuel wants to pull in some part of my patches.  I haven't
looked at pb16 yet, BTW.

(I don't understand your "not fully integrated with the web interface" 

> So , probably, the next question is for Manuel;
> Considering that there is no gnu or free  firewall as nice as m0n0 out =
> there with the capability of using public IPs over the dmz.....
> ...Would be very dificult or time consuming to make this feature be =
> built in m0n0wall?

I personally don't think it'd be that difficult.  Manuel has indicated
(and I concur) that the use of bridge(4) bridging doesn't work very well
for a majority of users.  So any solution would have to allow for the
original ng_bridge(4) plus what was in my patch...maybe by letting the
user decide which type of bridging they want.  Of the three patch files
on my Web page:

filter.inc.diff should have no effect on the original bridging behavior,
because firewall rules don't affect ng_bridge(4) bridging.  It can 
probably be applied regardless.

The bridge configuration patch in interfaces.inc.diff can perhaps be
made conditional (i.e. add a checkbox somewhere in the Web interface to 
select which type of bridging, if any, to use).

rc.diff can, I think, be applied without any ill effect...it's a no-op 
for the ng_bridge(4) users.

If you (plural) want to see this, try to get Manuel to adopt the above 
approach.  Better yet, someone give him some patches that actually 
implement what I described above.  :-)