On 03/26/12 11:57, Julian Elischer wrote:
On 3/25/12 12:26 AM, Da Rock wrote:
On 03/25/12 15:08, Julian Elischer wrote:
On 3/24/12 7:08 PM, Da Rock wrote:
On 03/25/12 02:56, Ian Smith wrote:
On Sat, 24 Mar 2012, Da Rock wrote:
> On 03/18/12 02:31, Julian Elischer wrote:
> > On 3/17/12 1:36 AM, Da Rock wrote:
> > > On 03/14/12 17:09, Rémy Sanchez wrote:
>
[everything deleted]..
ok I'm going to write a little blurb here, as someone who has,
1/ contributed to ipfw
2/ written python code to manipulate ipfw real-time (for code
running in cisco appliances.. guess which ones)
3/ used it for many weird things at many times.
If I may ask, what kind of weird things and how?
some examples (I've forgotten some I'm sure)
used the 'fwd' rule and tables to implement multiple routing tables,
before I actually added multiple routing tables to the system.
used level2 firewalling (plus some patches) to implement a transparent
firewalling bridge.
(a firewalling cable so to speak.)
used fwd, (with some patches) to implement transparent redirection to
a web proxy.
here are my rules for using ipfw..
1/ always use a script to make your firewalls..
start by siabling everything
end by re-enabing
comment extensively
2/ as soon as you start, split your flows to different rule ranges.
even if that means duplicating rules... Once you have a set of
rules for
"incoming rules on re0" you never have to spend cpu cycles testing
"in recv re0"
on any further rules. It also means you don't have to think of
every run of rules
from the perspective of several different flows.
yes you may have 7 different sets of rules if you have 3 interfaces
and lo0, but
you won't go insane. Inside rulesets can just be "allow ip from any
to any" if you trust your inside interfaces.
3/ get really familiar with all the things you can do with tables.
e.g. skipto tablearg/
4/ use skipto creatively but remember you can oly skip forwards.
5/ remember that keep-state rules, when matched will duplicate
whatever the original did
so .... skipto 1000 ip from a to b keep-state will skip to
1000 whenever the state matches.
this can lead to some really creative rulesets.
6/ when using NAT remember that rules before and after NAT are
looking at different packets and
that rules before nat are in local addresses going out but external
addresses coming in, and teh opposite for after NAT. I always try
catch incoming sessions that are actuallydestimed for the local
machien before NAT so that my incoming sessions and local services
still work if NAT fails.
Wow! That is really helpful. Why isn't *that* in the handbook?
I had considered breaking everything up into sections and using
skipto, but I _hadn't_ picked up on the fact that you can only go
forwards- good catch there.
That is in the man page..
Yep. But that didn't mean it registered... :)
I'm assuming you can use tags like in pf? Would that work well in
such an environment where it is all sectioned?
I have never needed tags. But I know others that use them.. they do
add some overhead per packet.
When you speak of sets, how are they used? Are you using the sets
feature mentioned in the man ipfw(8)? I'm still a little confused on
how these would be used as yet, but I intend to investigate further
because the comments in the man page intrigued me in the reference to
"hot swapping" sets on an attacked firewall to further close it up.
I have sets for each interface..
so I can switch on firewalling and nat on each interface individually
for testing or if something goes wrong.
A differnet NAT interface for each interface is also useful.
theoretically a single natd process can do multiple contexts at once
with different port numbers etc,
but the one time I tried it, it didn;t work so I switched to multiple
instances of natd.
I have to look into how exactly that works yet. It sounds useful to my
own needs in some way I haven't quite out
As for my motto: "dont trust anyone." So I disable all and only let
in what is required under strict conditions- even on the internal
interfaces. This is a test scenario atm though, and I will set about
locking it all up and implementing a production setup *if* IPSec works.
I've used IPSEC successfully with home-grown tunnels using netgraph
ksocket nodes connected to netgraph ng_iface interfaces. Now that we
can have multiple stack instances it gets even more interesting, as
you can forward other jails to do tunnel encapsulation and such.
the variety and number of options you have to achieve any task is
getting bewilderingly high.
for any task you can probably get 3 or 4 completely different
suggestions as to how it can be done,
Amen to that! I'm still trying to sort through it all for my own needs.
I have not yet used the new 'subroutine' functionality in current
but am looking forward
to playing with it.
That sounds interesting. How would that work? Are we talking about a
switch from old procedural-like to more OO-like?
As I said, I haven't really looked but I gather it's like a 'skipto'
except that you can 'return'
Hmm, I think I see that - that would be extremely useful (especially
considering my thoughts on using skipto before I knew it was only pass
forward).
I'll be back with more questions I'm sure... Meanwhile I have to go
and put this stuff into practice :)
go read the man pages for ipfw, divert, netgraph (AND all it's module
types), the route command including the 'newish' setfib stuff, the
jail command with specific reference to having a separate complete
networking stack in each jail (including it's own firewall), (and
ifconfig vnet command), natd, ipfw nat options, mpd (a port)and ppp.
and as if that wasn't enough.. pf, tun, if_bridge, epair, gif, stf,
and I'm sure I forgot a bunch.
I'm still going through it all (amongst other tasks), but I did come
across one thing: why nat only ip4 (simple/client/open)? Isn't nat still
a possibility on ipv6 (for one of the original reasons it was used on
ip4- anonymity)?
there will be test next week :-)
I'll be ready :P
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
