Re: [IPCop-devel] Tarpit, Bridging and Xen patches for Experimental

[Franck B. <fbo...@ch...>]

Approach 1) is good for an addon (simple).
Approch 2) is better.

Both needs serious touches into IPCop. Complicated
Too late for 1.4 except that 'brctl' and other stuff could
be included in it for specialist.

For IPCop 2, it is also too late. This one is just a good
exercice for wasting time and dev power.

Fortunately, after 2 will come IPCop 3. This one will
bring in all good ideas in it.
-filrewall mode : transparent (true bridging) or normal or
NATing, any number of NIC, real or virtual (vpn).
-gui stuff (eg apache, perl cgi) runs outside of the FW
in separe machine or VM. GUI supervising several IPCops.
-squid,dhcp or other 'non really firewall' tools installed also
in separeted VM.
-remove all oldies support. (IPCop1.4 do it well).
-load balacing
-and firewall redundancy.
-concentrate on Intel platform (IPCop 2 will do well with
exotic machinaty).

You can do all this today with debian but it takes long time to
setup. More subtil, peoples in the IT jobs, managing firewalls
or other network tools, often 'ssh it' and play with VI, tcpdump,
tail -f, netstat for solving runtime problem reported by clients.



Paul, if you have time, spend it on future project !

Franck 


Le Saturday 26 July 2008 14:00:10 Paul Schulze, vous avez écrit :

> > 1) Have a separate setup dialog in the setup to combine multiple
> > interfaces to a bridge, maybe a separate tool, if it is to be an
> > add-on. This is quiet simple but might introduce consistency
> > problems with the networking setup. Though it leaves the well-known
> > setup parts untouched and adds only options for people who should
> > know what they are doing. However, since bridges intrude quiet
> > deeply into the system (kernel level support needed, downing and
> > upping network interfaces on runtime and so on), this approach
> > might not be the preferable one.
> >
> > 2) Use bridges for Green, Blue and Orange interfaces in every setup
> > and just add interfaces to the selected bridge as they are
> > assigned. In setup, change the network device configuration from a
> > device -> zone to a zone -> device structure, which would in my
> > opinion be the more intuitive approach anyways, since you seem to
> > be planning to have multiple devices per zone. I don't think this
> > would be any more complicated than any other approach, but it has
> > the downside of introducing more logic in form of the bridge code
> > to all installations. This might however be true for any routing
> > too. But it would also remove the need for configuring a name for
> > each bridge and more than one IP per zone, which would make
> > multiple interfaces per zone very comfortable (with the option to
> > maybe add more IPs if necessary). And anyone who wants some real
> > routing/firewalling between interfaces in one zone will have to
> > know what he is doing anyways.
> >
> > Both approaches would however require the kernel and setup to at
> > least know what bridges are and how to handle them, which is the
> > main focus of my current bridging patches. I will probably start
> > working on approach 1 or 2 soon, but I first have to get around
> > learning Newt. Let me know what you think about these ideas, I'm
> > always open for comments or suggestions.
> >
> > Cheers,
> >
> >
> > Paul.