Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list

[julian]

Synopsis: [patch] [ipfw] unbreak POLA for ipfw table list

State-Changed-From-To: open->closed
State-Changed-By: julian
State-Changed-When: Mon Feb 18 11:27:58 PST 2008
State-Changed-Why: 
Patch committed to -current and scheduled for MFC.


http://www.freebsd.org/cgi/query-pr.cgi?pr=120720
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/123174: [ipfw] table add value lists as ip/uint16 instead of uint32.

[julian]

Synopsis: [ipfw] table add value lists as ip/uint16 instead of uint32.

State-Changed-From-To: open->closed
State-Changed-By: julian
State-Changed-When: Mon Apr 28 12:15:05 PDT 2008
State-Changed-Why: 
fixed in all affected branches post release.
dupplicate of another bug (also closed) (I forget the number)

the change came as part of the change allowing:
ipfw table 1 add 1.2.3.4 5.6.7.8
ipfw add 100 fwd tablearg ip from table(1) to any



http://www.freebsd.org/cgi/query-pr.cgi?pr=123174
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/146372: [ipfw] ipfw setfib does not work on local outgoing connections

[julian]

Synopsis: [ipfw] ipfw setfib does not work on local outgoing connections

State-Changed-From-To: open->closed
State-Changed-By: julian
State-Changed-When: Fri May 7 15:00:00 PDT 2010
State-Changed-Why: 
Unfortunatly this is mostly unavoidable. The routing decision has already been 
made by the time that 
ipfw is called. There is a small possibility that  a change of fib could make 
the stack do teh same thing
as ipfw fwd and force he packet to go back to the start and get rerouted, but 
it's not quite as easy as that.

You should look at possibly setting the fib for the application in question or 
maybe jsut its socket
if you have source. contact me directly to get some ideas we may be able to 
work with you on.


http://www.freebsd.org/cgi/query-pr.cgi?pr=146372
___
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"

Re: Traffic quota features in IPFW

[Julian Elischer]

Luigi Rizzo wrote:

On Mon, Jul 18, 2005 at 06:34:56AM +, Walery Kokarev wrote:


And why can't one use divert(4) interface? It looks quite suitable for
that particular task.



no _that_ would really be a performance killer!

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


unless you divert to a netgraph socket within the kernel :-)
(or use the new ipfw netgraph diversion facility)


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: FreeBSD 6.0 - ipfw fwd with bridge mode

[Julian Elischer]

Özkan KIRIK wrote:

Hi,

i am trying to forward packets via ipfw in bridge mode.
is there any patch for 6.0-Release?

thanks for your interests,
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"



there are two patches to do this with 4.x

one by luigi and one by a company I know of.

neither is exactly correct for 6.0

The simplest one just "accepts" the packet as local which means that it
gets run through ipfw again in the IP stack at which time it is
REALLY forwarded.

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [patch] ipfw packet tagging

[Julian Elischer]

Vadim Goncharov wrote:


12.05.06 22:56 Luigi Rizzo wrote:


A question about features: is it worth adding functionality of matching
range of tags? For example:

ipfw add pass ip from any to any tagged 1-5,10,20



i think it is a useful feature, and if you reuse the existing code
for matching port ranges etc to implement it, performance should
be reasonably good.



OK, Andrey made new version of patches available:
http://butcher.heavennet.ru/patches/kernel/ipfw_tags/

Manpage patch is integrated as well as new untag/tagged range  
functionality,
based on existing port ranges matching code. Short test shown that it  
works.



I might suggest that the new 'tablearg' keyword be useable in a tag
command allowing a table to contain entries that give different tags.
(I don't think it is in 5 but it may be in 6.. (not sure))

would be cool however.


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw tracing

[Julian Elischer]

Andrey V. Elsukov wrote:

Hi, All!

I've make a small patch that add a rule action
tracing feature to ipfw2.

http://butcher.heavennet.ru/patches/kernel/ipfw_trace/

This patch can be usefull when you have too many
ipfw-rules. When some packets not pass ipfw - It is not
easy to determine rule which block these packets.

How to use:

# ipfw add 1 count tag  
# sysctl net.inet.ip.fw.trace_tag=
# tail -f /var/log/security

 - some tag number
 - rule for matching needed packets

What you think about that?



Can you show some sample usage and output?
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

IPFW update frequency

[Julian Elischer]

I have been looking at the IPFW code recently, especially 
with respect to locking.
There are some things that could be done to improve IPFW's 
behaviour when processing packets, but some of these take a

toll (there is always a toll) on the 'updating' side of things.

For example. I can make IPFW lock-free during processing 
of packets (i.e. not holding any locks while traversing the

list) which would solve problems we have with lock-order reversals
when it needs to look at the socket layer (which needs socket 
layer locks). Unfortunatly this would make it a lot more expensive

in the case where new rules are being added to the list. possibly a LOT
more expensive. Now, this would only matter if one was adding (or deleting)
hundreds of rules per second to the firewall, but as I've discovered,
there's always SOMEONE that is doing the very thing you imagine that
no-one would ever do.

In my imagination, most of the people who did this sort of thing don't
need to do it any more as tables obviate the need for that sort of thing.

Is there anyone out there who is adding hundreds (or even dozens) of rules
per second on a continuous basis, or who wants rule changing to
be a really efficient operation?
(does it matter to you if it takes a few milliSecs to add a rule?)

Julian
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW update frequency

[Julian Elischer]

Kevin Day wrote:


On Mar 30, 2007, at 3:40 PM, Julian Elischer wrote:

I have been looking at the IPFW code recently, especially with respect 
to locking.
There are some things that could be done to improve IPFW's behaviour 
when processing packets, but some of these take a

toll (there is always a toll) on the 'updating' side of things.

For example. I can make IPFW lock-free during processing of packets 
(i.e. not holding any locks while traversing the

list) which would solve problems we have with lock-order reversals
when it needs to look at the socket layer (which needs socket layer 
locks). Unfortunatly this would make it a lot more expensive

in the case where new rules are being added to the list. possibly a LOT
more expensive. Now, this would only matter if one was adding (or 
deleting)

hundreds of rules per second to the firewall, but as I've discovered,
there's always SOMEONE that is doing the very thing you imagine that
no-one would ever do.

In my imagination, most of the people who did this sort of thing don't
need to do it any more as tables obviate the need for that sort of thing.

Is there anyone out there who is adding hundreds (or even dozens) of 
rules

per second on a continuous basis, or who wants rule changing to
be a really efficient operation?
(does it matter to you if it takes a few milliSecs to add a rule?)

Julian


Would this apply to "dynamic rules", using the keep-state keyword? 
That'd be a killer for us.




no,

just to the main firewall list where rules a re put manually.


If not, the only problem I'd have is that my ipfw startup script adds 
about 20,000 rules on a reboot. 20,000 rules multiplied by any 
significant amount of time would be bad, just from a 
reboot-recovery-time angle. But, if it improved overall performance, I 
probably wouldn't mind too much. :)


now, what could I add to the firewall to make that come down to, say, 100 rules?

I have the following in my list of things to add:
** adding of 'variables (registers) to hold values for the duration of the 
filter run. **
ipfw add 100 set (register number) value
ipfw add 100 set (register number) tablearg ip from table (x) to any
ipfw [action] if (register number) gt value  (lt,le,ge,eq,neq)
ipfw [action] if (register number) in table (x)  (registers and table values 
can be addresses)
** computed skipto **
ipfw skipto tablearg ip from table (2) to any
** adding items to tables automatically **
ipfw loadto table 3 (source, value) ip from any to table (3)
** ability to select WHICH table arg **
ipfw skipto tablearg2 ip from table (1) to table (2)








___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW update frequency

[Julian Elischer]

Luigi Rizzo wrote:

On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote:
I have been looking at the IPFW code recently, especially 
with respect to locking.
There are some things that could be done to improve IPFW's 
behaviour when processing packets, but some of these take a

toll (there is always a toll) on the 'updating' side of things.


certainly ipfw was not designed with SMP in mind. 
If you can tell us what is your plan to make the list lock free

(which one, the static or dynamic ones ?) maybe we can comment more.

E.g. one option could be the usual trick of adding refcounts to
the individual rules, and then using an array of pointers to them.
While processing you grab a refcount to the array, and release it once
done with the packet. If there is an addition or removal, you duplicate
the array (which may be expensive for the large 20k rules mentioned),
manipulate the copy and then atomically swap the pointers to the head.


This is pretty close.. I know I've mentioned this to people several times over
the last year or so. the trick is to try do it in a way that the average packet
doesn't need to do any locks to get in and the updater does more work.
if you are willing to acquire a lock on both starting and ending
the run through the firewall it is easy.
(I already have code to do that..)
(see http://www.freebsd.org/~julian/atomic_replace.c (untested but
probably close.)
doing it without requiring that each packet get those locks however 
is a whole new level of problem.




This might even work for dynamic rules as the lists (the content of
each hash bucket) are typically short.


yep



cheers
luigi


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW update frequency

[Julian Elischer]

Freddie Cash wrote:

On Friday 30 March 2007 01:40 pm, Julian Elischer wrote:

I have been looking at the IPFW code recently, especially
with respect to locking.
There are some things that could be done to improve IPFW's
behaviour when processing packets, but some of these take a
toll (there is always a toll) on the 'updating' side of things.

For example. I can make IPFW lock-free during processing
of packets (i.e. not holding any locks while traversing the
list) which would solve problems we have with lock-order reversals
when it needs to look at the socket layer (which needs socket
layer locks). Unfortunatly this would make it a lot more expensive
in the case where new rules are being added to the list. possibly a LOT
more expensive. Now, this would only matter if one was adding (or
deleting) hundreds of rules per second to the firewall, but as I've
discovered, there's always SOMEONE that is doing the very thing you
imagine that no-one would ever do.

In my imagination, most of the people who did this sort of thing don't
need to do it any more as tables obviate the need for that sort of
thing.

Is there anyone out there who is adding hundreds (or even dozens) of
rules per second on a continuous basis, or who wants rule changing to
be a really efficient operation?
(does it matter to you if it takes a few milliSecs to add a rule?)


If the initial loading of a ruleset via a script counts, then yes.  We add 
600+ rules each time the script is run.  During testing, or when 
troubleshooting connection issues, the rules could be reloaded several 
times over 10 minutes.  We've moved away from adding rules dynamically, 
preferring to add rules to the script and reload them all.  Keeps the 
rules in memory in sync with the rules on disk.


Otherwise, no.  :)



the new rules might take a second or two to load.. a load may take 
a couple of milliseconds vs less than that for now. 


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW update frequency

[Julian Elischer]

AT Matik wrote:

On Friday 30 March 2007 17:40, Julian Elischer wrote:

I have been looking at the IPFW code recently, especially
with respect to locking.
There are some things that could be done to improve IPFW's
behaviour when processing packets, but some of these take a
toll (there is always a toll) on the 'updating' side of things.



Hi , 
would you mind to explain your way of "add a toll", do you mean kind of price 
for a benefit or something like that? Sorry I am not native american english 
speaker. 


a  toll is a cost.
so, yes (toll is not just American English)



If I understand this right I would say that it does not matter for adding 
rules, what is of interest is processing time when they exist already


exactly..




Is there anyone out there who is adding hundreds (or even dozens) of rules
per second on a continuous basis, or who wants rule changing to
be a really efficient operation?


even if ...
I have a system which takes additional custom parms from rc.conf. 
so lets say the admin configures a new IP or port he executes a script which 
flushes the old and executes the new rules


it doesn't matter the time it takes to execute the new rules - what certainly 
depends on machine capacities - what matters at the end is how fast the 
machine can process the rules at run-time ... whatever it is .. as long as it 
is faster ... not building the rule set  but running them under load



(does it matter to you if it takes a few milliSecs to add a rule?)


absolutely NOT


thankyou




João 








A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW update frequency

[Julian Elischer]

Thanks for the information..
The main thrust for me is to make it not hold any locks during processing.

performance is 2nd



Andre Oppermann wrote:

Julian Elischer wrote:

Luigi Rizzo wrote:

On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote:
I have been looking at the IPFW code recently, especially with 
respect to locking.
There are some things that could be done to improve IPFW's behaviour 
when processing packets, but some of these take a

toll (there is always a toll) on the 'updating' side of things.


certainly ipfw was not designed with SMP in mind. If you can tell us 
what is your plan to make the list lock free

(which one, the static or dynamic ones ?) maybe we can comment more.

E.g. one option could be the usual trick of adding refcounts to
the individual rules, and then using an array of pointers to them.
While processing you grab a refcount to the array, and release it once
done with the packet. If there is an addition or removal, you duplicate
the array (which may be expensive for the large 20k rules mentioned),
manipulate the copy and then atomically swap the pointers to the head.


This is pretty close.. I know I've mentioned this to people several 
times over
the last year or so. the trick is to try do it in a way that the 
average packet

doesn't need to do any locks to get in and the updater does more work.
if you are willing to acquire a lock on both starting and ending
the run through the firewall it is easy.
(I already have code to do that..)
(see http://www.freebsd.org/~julian/atomic_replace.c (untested but
probably close.)
doing it without requiring that each packet get those locks however is 
a whole new level of problem.


The locking overhead per packet in ipfw is by no means its limiting
factor.  Actually it's a very small part and pretty much any work on
it is lost love.  It would be much better spent time to optimize the
main rule loop of ipfw to speed things up.  I was profiling ipfw early
last year with an Agilent packet generator and hwpmc.  In the meantime
the packet forwarding path (w/o ipfw) has been improved but relative
to each other the number are still correct.

Numbers pre-taskqueue improvements from early 2006:
 fastfwd580357 pps
 fastfwd+pfil_pass565477 pps  (no rules, just pass packet on)
 fastfwd+ipfw_allow505952 pps  (one rule)
 fastfwd+ipfw_30rules401768 pps  (30 IP address non-matching rules)
 fastfwd+pf_pass476190 pps  (one rule)
 fastfwd+pf_30rules342262 pps  (30 IP address non-matching rules)

The overhead per packet is big.  Enabling of ipfw and the pfil/ipfw
per packet and their indirect function calls cause a loss of only
about 15'000 pps (0.9%).  On the other hand the first rule costs 12.9%
and each additional rule 0.6%.  All this is without any complex rules
like table lookups, state tracking, etc.

idlefastfwdfastfwd+ipfw_allow fastfwd+ipfw_30rules
cycles2596685731259821474325979732652596702381
cpu-clk-unhalted 7824023258224084725181876702483904362
instructions2317535132465533014923633462026009148
branches316786174329367191263118294700024
branch-mispredicts 197572235749100034618848407
dc-access14175328291594829984272241235192770
dc-refill-from-l2 2124476739543467384548311
dc-refill-from-system 89803102819658654661
dtlb-l2-hit62610435843930444812352018
dtlb-miss129255493130998112644
ic-fetch804423471138619583149432870371492
ic-miss23583483125051981947943
itlb-l2-hit0741212
itlb-miss42928282
lock-cycles77803352451
locked-instructions 41924
lock-dc-access62067
lock-dc-miss0000

Hardware is a dual Opteron 852 at 2.6GHz on a Tyan 2882 mainboard with
a dual Intel em network card plugged into a PCI64-133 slot.  Packets
are flowing from em0 -> em1.



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW update frequency

[Julian Elischer]

Luigi Rizzo wrote:

On Sat, Mar 31, 2007 at 10:21:02AM +0200, Andre Oppermann wrote:

Julian Elischer wrote:

Luigi Rizzo wrote:

On Fri, Mar 30, 2007 at 01:40:46PM -0700, Julian Elischer wrote:
I have been looking at the IPFW code recently, especially with 
respect to locking.
There are some things that could be done to improve IPFW's behaviour 

...

The locking overhead per packet in ipfw is by no means its limiting


i think you and Julian are looking at different issues.
if i understand julian's comment, the problem is that the list
is protected by a single lock, so no hope of parallelising
the work, and if one kernel thread is busy processing a packet
in the filter, others might be blocked for a long time
(in your case, the set of 30 rules is 765ns for ipfw and 1198ns
for pf).

Your tests presumably have little if any contention on the lock.

Specifically, if you compute the difference of the inverses
of those pps rates you see the following:

+pfil_pass  45.3 ns per packet

+ipfw_allow +253.4 ns/packet (setup and first rule)
+ipfw_30+17.67 ns/(packet * extra rule)

+pf_pass+376.9 ns/packet (setup and first rule)
+pf_30  +28.34 ns/(packet * extra rule)


the lock acquisition cost is in the 'setup' part but i cannot tell
how expensive it is.
Julian's suggested change (and surely the one i described)
replaces the lock/unlock pair on the rule list with a refcount add/dec
pair (with uncontested locks the cost should be similar), but especially
makes the operation non-blocking allowing running the input and
output paths in parallel.


-current now used a read-write lock so this is theoretically already possible..
trouble is that the lock is held whioch produces LORs when you
try access something that is further up the stack e.g. the UID rules.




factor.  Actually it's a very small part and pretty much any work on
it is lost love.  It would be much better spent time to optimize the
main rule loop of ipfw to speed things up.  I was profiling ipfw early
last year with an Agilent packet generator and hwpmc.  In the meantime
the packet forwarding path (w/o ipfw) has been improved but relative
to each other the number are still correct.


actually your numbers show that at least the rule setup (and the
processing of simple rules) is significantly faster (50% or so) in
ipfw2 than in pf.

I know that the setup time is expensive, but i am not sure that
one can save much - in both cases, you need to fetching a lot
of information, which is scattered in variable locations in
the mbuf and packet headers.

cheers
luigi
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bad test in /etc/rc.d/ip6fw

[Julian Elischer]

Sean McNeil wrote:

Hi Henrique,


For Firewall in IPV6 enable in kernel

options IPV6FIREWALL # Enable ipfirewall(4) for ipv6
options IPV6FIREWALL_VERBOSE # Enable log's in syslogd(4)
options IPV6FIREWALL_VERBOSE_LIMIT=100 # Set limite in syslogd in 100 
registers

options IPV6FIREWALL_DEFAULT_TO_ACCEPT # Enable default Open Firewall

And sorry my poor english :p


No problem.  You miss my point, however.  I have none of these in my 
kernel config yet I have net.inet6.ip6.fw.enable defined.  This prevents 
the /etc/rc.d/ip6fw script from kldload'ing the appropriate module. So 
either the code that creates the kernel parameter or the script needs to 
be changed so that they work in tandem.


my bad
fixing asap
the one in ipfw will be named differently.





Henrique Mattos

2007/4/2, Sean McNeil <[EMAIL PROTECTED]>:
I just noticed that ip6fw isn't loading the ip6fw kernel module 
because my kernel somehow already has the sysctl value in it.  This 
is FreeBSD -STABLE and I have the following in my kernel:


options INET# InterNETworking
options INET6   # IPv6 communications protocols

options IPFIREWALL
options IPFIREWALL_FORWARD
options IPDIVERT
options DUMMYNET

net.inet6.ip6.fw.enable managed to get in the kernel.

Cheers,
Sean
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"






___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bad test in /etc/rc.d/ip6fw

[Julian Elischer]

Sean McNeil wrote:

Hi Henrique,


For Firewall in IPV6 enable in kernel

options IPV6FIREWALL # Enable ipfirewall(4) for ipv6
options IPV6FIREWALL_VERBOSE # Enable log's in syslogd(4)
options IPV6FIREWALL_VERBOSE_LIMIT=100 # Set limite in syslogd in 100 
registers

options IPV6FIREWALL_DEFAULT_TO_ACCEPT # Enable default Open Firewall

And sorry my poor english :p


No problem.  You miss my point, however.  I have none of these in my 
kernel config yet I have net.inet6.ip6.fw.enable defined.  This prevents 
the /etc/rc.d/ip6fw script from kldload'ing the appropriate module. So 
either the code that creates the kernel parameter or the script needs to 
be changed so that they work in tandem.


please see if the following change makes a difference.
(you will need to apply this by hand).

In the mean time I will revert this MFC in total.

Index: ip_fw2.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.106.2.34
diff -u -r1.106.2.34 ip_fw2.c
--- ip_fw2.c31 Mar 2007 01:51:29 -  1.106.2.34
+++ ip_fw2.c3 Apr 2007 07:59:50 -
@@ -4349,7 +4349,7 @@
   SYSCTL_STATIC_CHILDREN(_net_inet6_ip6), OID_AUTO, "fw",
   CTLFLAG_RW | CTLFLAG_SECURE, 0, "Firewall");
   SYSCTL_ADD_PROC(&ip6_fw_sysctl_ctx, SYSCTL_CHILDREN(ip6_fw_sysctl_tree),
-   OID_AUTO, "enable", CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_SECURE3,
+   OID_AUTO, "enablefw", CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_SECURE3,
   &fw6_enable, 0, ipfw_chg_hook, "I", "Enable ipfw+6");
   SYSCTL_ADD_INT(&ip6_fw_sysctl_ctx, SYSCTL_CHILDREN(ip6_fw_sysctl_tree),
   OID_AUTO, "deny_unknown_exthdrs", CTLFLAG_RW | CTLFLAG_SECURE,




Henrique Mattos

2007/4/2, Sean McNeil <[EMAIL PROTECTED]>:
I just noticed that ip6fw isn't loading the ip6fw kernel module 
because my kernel somehow already has the sysctl value in it.  This 
is FreeBSD -STABLE and I have the following in my kernel:


options INET# InterNETworking
options INET6   # IPv6 communications protocols

options IPFIREWALL
options IPFIREWALL_FORWARD
options IPDIVERT
options DUMMYNET

net.inet6.ip6.fw.enable managed to get in the kernel.

Cheers,
Sean
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"






___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cvs commit: src/sys/netinet ip_fw.h ip_fw2.c ip_fw_pfil.c ip_input.c

[Julian Elischer]

Max Laier wrote:

On Tuesday 03 April 2007 10:16, Julian Elischer wrote:

julian  2007-04-03 08:16:05 UTC

  FreeBSD src repository

  Modified files:(Branch: RELENG_6)
sys/netinet  ip_fw.h ip_fw2.c ip_fw_pfil.c ip_input.c
  Log:
  Revert one of the MFCs from Friday as it produces an
  unacceptable ABI change. I will re-MFC this when I have tested a
version that brings back the desirable changes but leaves the ABI the
same.


Thanks for reverting ... but why did you rush in all these MFCs?  


pressure from work.. 


anyhow one again, this time a bit slower..


As part of a move to getting RELENG_6 and HEAD closer,
here is a small partial re-MFC of ip_fw_pfil.c version 1.21
This is mostly diff-reduction, but is a self contained 'cleanup'
that canbe extracted from the functional change in the major change
in the original diff. it obscures the actual change going on 
so I would like to commit it separatly.


this isthe 'cleanup' part of: 


ip_fw2.c 1.129
ip_fw.h 1.105
ip_fw_pfil.c 1.21
ip_input.c 1.319

" Allow ipv6 filtering to be seperately enabled. plus cleanup"

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cvs commit: src/sys/netinet ip_fw.h ip_fw2.c ip_fw_pfil.c ip_input.c

[Julian Elischer]

this time, with the patch :-)


Max Laier wrote:

On Tuesday 03 April 2007 10:16, Julian Elischer wrote:

julian  2007-04-03 08:16:05 UTC

  FreeBSD src repository

  Modified files:(Branch: RELENG_6)
sys/netinet  ip_fw.h ip_fw2.c ip_fw_pfil.c ip_input.c
  Log:
  Revert one of the MFCs from Friday as it produces an
  unacceptable ABI change. I will re-MFC this when I have tested a
version that brings back the desirable changes but leaves the ABI the
same.


Thanks for reverting ... but why did you rush in all these MFCs?  


pressure from work.. 


anyhow one again, this time a bit slower..


As part of a move to getting RELENG_6 and HEAD closer,
here is a small partial re-MFC of ip_fw_pfil.c version 1.21
This is mostly diff-reduction, but is a self contained 'cleanup'
that canbe extracted from the functional change in the major change
in the original diff. it obscures the actual change going on 
so I would like to commit it separatly.


this isthe 'cleanup' part of: 


   ip_fw2.c 1.129
   ip_fw.h 1.105
   ip_fw_pfil.c 1.21
   ip_input.c 1.319

   " Allow ipv6 filtering to be seperately enabled. plus cleanup"


Index: ip_fw_pfil.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw_pfil.c,v
retrieving revision 1.19.2.3
diff -u -r1.19.2.3 ip_fw_pfil.c
--- ip_fw_pfil.c3 Apr 2007 08:16:04 -   1.19.2.3
+++ ip_fw_pfil.c4 Apr 2007 00:08:03 -
@@ -417,28 +417,13 @@
 ipfw_hook(void)
 {
struct pfil_head *pfh_inet;
-#ifdef INET6
-   struct pfil_head *pfh_inet6;
-#endif
-
-   if (ipfw_pfil_hooked)
-   return EEXIST;
 
pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET);
if (pfh_inet == NULL)
return ENOENT;
-#ifdef INET6
-   pfh_inet6 = pfil_head_get(PFIL_TYPE_AF, AF_INET6);
-   if (pfh_inet6 == NULL)
-   return ENOENT;
-#endif
 
pfil_add_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet);
pfil_add_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet);
-#ifdef INET6
-   pfil_add_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet6);
-   pfil_add_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet6);
-#endif
 
return 0;
 }
@@ -447,31 +432,48 @@
 ipfw_unhook(void)
 {
struct pfil_head *pfh_inet;
-#ifdef INET6
-   struct pfil_head *pfh_inet6;
-#endif
-
-   if (!ipfw_pfil_hooked)
-   return ENOENT;
 
pfh_inet = pfil_head_get(PFIL_TYPE_AF, AF_INET);
if (pfh_inet == NULL)
return ENOENT;
+
+   pfil_remove_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet);
+   pfil_remove_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, 
pfh_inet);
+
+   return 0;
+}
+
 #ifdef INET6
+static int
+ipfw6_hook(void)
+{
+   struct pfil_head *pfh_inet6;
+
+   pfh_inet6 = pfil_head_get(PFIL_TYPE_AF, AF_INET6);
+   if (pfh_inet6 == NULL)
+   return ENOENT;
+
+   pfil_add_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet6);
+   pfil_add_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, pfh_inet6);
+
+   return 0;
+}
+
+static int
+ipfw6_unhook(void)
+{
+   struct pfil_head *pfh_inet6;
+
pfh_inet6 = pfil_head_get(PFIL_TYPE_AF, AF_INET6);
if (pfh_inet6 == NULL)
return ENOENT;
-#endif
 
-   pfil_remove_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet);
-   pfil_remove_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, 
pfh_inet);
-#ifdef INET6
pfil_remove_hook(ipfw_check_in, NULL, PFIL_IN | PFIL_WAITOK, pfh_inet6);
pfil_remove_hook(ipfw_check_out, NULL, PFIL_OUT | PFIL_WAITOK, 
pfh_inet6);
-#endif
 
return 0;
 }
+#endif
 
 static int
 ipfw_modevent(module_t mod, int type, void *unused)
@@ -483,28 +485,39 @@
if (ipfw_pfil_hooked) {
printf("IP firewall already loaded\n");
err = EEXIST;
-   } else {
-   if ((err = ipfw_init()) != 0) {
-   printf("ipfw_init() error\n");
-   break;
-   }
-   if ((err = ipfw_hook()) != 0) {
-   printf("ipfw_hook() error\n");
-   break;
-   }
-   ipfw_pfil_hooked = 1;
+   break;
+   } 
+   if ((err = ipfw_init()) != 0) {
+   printf("ipfw_init() error\n");
+   break;
}
+   if ((err = ipfw_hook()) != 0) {
+   printf("ipfw_hook() error\n");
+   break;
+   }
+#ifdef INET6
+   if ((err = ipfw6_hook()) != 0) {
+   ipfw_unhook();

Re: kern/111121: [ipfw] After the latest changes ipfw2 complains: "ipfw: opcode 50 size 2 wrong"

[Julian Elischer]

Synopsis: [ipfw] After the latest changes ipfw2 complains: "ipfw: opcode 50 
size 2 wrong"

State-Changed-From-To: open->closed
State-Changed-By: julian
State-Changed-When: Wed Apr 4 17:11:48 PDT 2007
State-Changed-Why: 
MFC reverted.



http://www.freebsd.org/cgi/query-pr.cgi?pr=21
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ipfw changes being contemplated..

[Julian Elischer]

I'm contemplating the following changes to functionality:
I'd like suggestions and comments...

1/ Commit capability
 In this change you declare a new firewall,
 and modify/build it, and then you 'commit' it so that
 the whole change is atomic.
 I have a current bug at work where automatic changes 
 are made to teh firewall, but sometimes packets can arrive

 between parts of a change and lead to odd behaviour.
 For example if I have a reset rule after a skipto, 
 and as part of the change I replace the skipto with something else,

 then for a moment, teh reset it exposed before the new rule is put in.
 this leads to a spurious reset being sent out and terminating 
 a perfectly innocent session.  I can code around these sorts 
 of things but I'd like to do:


 ipfw duplicate to 1   # make rule list 1 a copy of the current rules
 ipfw rules 1 delete 1000
 ipfw rules 1 add 1000 skipto 2000 tcp from any to me ...
 ... (400 other changes)
 ipfw commit 1


or
 ipfw new 1   # make rule list 1 a copy of the current rules
 ipfw rules 1 add 1000 skipto 2000 tcp from any to me ...
 ... (400 other changes)
 ipfw commit 1
 rules that are unchanged would maintain their statistics.

possibly I would not need a rule list number if the ipfw program
would automatically write to the existing set if there is no new 
(or duplicate) rule list, but would manipulate the 'growing' list

if it exists. (that way keeping the new behaviour as a superset
of the old behaviour).

2/ implements some local registers for each packet run.
  As each packet traverses the firewall the rules can assign
  values to some registers, which can be used to make decisions later.
  e.g.
 ipfw add 1000 loadregister 1 tablearg ip from any to table (2)
 ipfw add 2000 skipto 3000 register 1 gt 100


3/ 'computed goto' (fortran name)
  ipfw add 1000 skipto tablearg tcp from 1.1.1.1 to table (1) 


4/ tablearg to get an optional table number
  if a rule has 2 tables we need to be able to specify which.

5/
ability to have multiple firewalls.. (extension of (1))
 ipfw new 1 
 ipfw rules 1 add 

 
 ipfw commit 1 bridge "bridge0"

 different rule sets for different entry points.
 ethernet layer (Layer2), IP output, bridging, 
 IP input, different input interfaces?


6/ corrolory of 5
  ability for one firewall to call into another..
  ipfw new 2 
  ipfw add [IP tests]



  ipfw new 1
  ipfw rules 1 add 1000 check rules 2 mac-type ipv4
  commit 2 bridge



The syntax is not set on these. This is just to get ideas out there.
so I'm up for a discussion.

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw changes being contemplated..

[Julian Elischer]

Julian Elischer wrote:

I'm contemplating the following changes to functionality:
I'd like suggestions and comments...

1/ Commit capability
 In this change you declare a new firewall,
 and modify/build it, and then you 'commit' it so that
 the whole change is atomic.
 I have a current bug at work where automatic changes  are made to teh 
firewall, but sometimes packets can arrive

 between parts of a change and lead to odd behaviour.
 For example if I have a reset rule after a skipto,  and as part of the 
change I replace the skipto with something else,

 then for a moment, teh reset it exposed before the new rule is put in.
 this leads to a spurious reset being sent out and terminating  a 
perfectly innocent session.  I can code around these sorts  of things 
but I'd like to do:


 ipfw duplicate to 1   # make rule list 1 a copy of the current rules
 ipfw rules 1 delete 1000
 ipfw rules 1 add 1000 skipto 2000 tcp from any to me ...
 ... (400 other changes)
 ipfw commit 1


or
 ipfw new 1   # make rule list 1 a copy of the current rules
 ipfw rules 1 add 1000 skipto 2000 tcp from any to me ...
 ... (400 other changes)
 ipfw commit 1
 rules that are unchanged would maintain their statistics.

possibly I would not need a rule list number if the ipfw program
would automatically write to the existing set if there is no new (or 
duplicate) rule list, but would manipulate the 'growing' list

if it exists. (that way keeping the new behaviour as a superset
of the old behaviour).

2/ implements some local registers for each packet run.
  As each packet traverses the firewall the rules can assign
  values to some registers, which can be used to make decisions later.
  e.g.
 ipfw add 1000 loadregister 1 tablearg ip from any to table (2)
 ipfw add 2000 skipto 3000 register 1 gt 100


3/ 'computed goto' (fortran name)
  ipfw add 1000 skipto tablearg tcp from 1.1.1.1 to table (1)
4/ tablearg to get an optional table number
  if a rule has 2 tables we need to be able to specify which.

5/
ability to have multiple firewalls.. (extension of (1))
 ipfw new 1  ipfw rules 1 add 
 
 ipfw commit 1 bridge "bridge0"

 different rule sets for different entry points.
 ethernet layer (Layer2), IP output, bridging,  IP input, different 
input interfaces?


6/ corrolory of 5
  ability for one firewall to call into another..
  ipfw new 2   ipfw add [IP tests]


  ipfw new 1
  ipfw rules 1 add 1000 check rules 2 mac-type ipv4
  commit 2 bridge



The syntax is not set on these. This is just to get ideas out there.
so I'm up for a discussion.


p.s. this goes along with a planned internal change that changes
the way ipfw locking is done. 


BLUESKY:


Also One possibility of 6 would be to make a family of 
firewalls rather than one, that work together, 


e.g. L2FW (layer 2 firewall) that knows about MAC packets etc
but calls IPFW for ip packets should it want to do so.
IPFW in turn the ability to call TCPFW
for some sessions and TCPFW would know about 
modules that in turn know about different

protocols.

IPFW could be called from the IP layer, or from the FW of a lower layer.
each layer would have the ability to do some inspection of the payload to help
decide which higher layer might be relevant.

I can imagine an HTTPFW which does some small tests and if it needs to can 
divert the session to a proxy. It would know some basic rules of HTTP. for example.









___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw changes being contemplated..

[Julian Elischer]

Chuck Swiger wrote:

On Apr 18, 2007, at 1:58 PM, Julian Elischer wrote:

I'm contemplating the following changes to functionality:
I'd like suggestions and comments...

1/ Commit capability
 In this change you declare a new firewall,
 and modify/build it, and then you 'commit' it so that
 the whole change is atomic.

[ ... ]

5/
ability to have multiple firewalls.. (extension of (1))
 ipfw new 1  ipfw rules 1 add 
 
 ipfw commit 1 bridge "bridge0"

 different rule sets for different entry points.
 ethernet layer (Layer2), IP output, bridging,  IP input, different 
input interfaces?


6/ corrolory of 5
  ability for one firewall to call into another..
  ipfw new 2   ipfw add [IP tests]


  ipfw new 1
  ipfw rules 1 add 1000 check rules 2 mac-type ipv4
  commit 2 bridge


It seems to me that IPFW2 already has these three capabilities?
 From the manpage:


yes but I was thinking of taking it further so that you can apply differnet 
sets at different places..
I didn't express it very well,
I'll try express it better again in a second...

ipfw sets are curently impemented by adding a set number to each rule.
By enabling and disabling the sets one controls which rules are skipped over,
however they are still all in the same linked list of rules.
If you have a set of 1000 rules and disable 999 of them, the packet still
has to follow 1000 links.
I am suggesting to actually duplicate the whole ruleset.
including subsets. 
When different sets are turned on and off, we "recompile" an optimised
set of rules and 'commit' that set into the 'current' running ruleset 
(for that entrypoint?).


Allowing each ruleset to be independently assigned to a different 
entrypoint to some extent is an extension on this..









 Also, each rule belongs to one of 32 different sets , and there are 
ipfw

 commands to atomically manipulate sets, such as enable, disable, swap
 sets, move all rules in a set to another one, delete all rules in a 
set.
 These can be useful to install temporary configurations, or to test 
them.

 See Section SETS OF RULES for more information on sets.
[ ... ]
SETS OF RULES
 Each rule belongs to one of 32 different sets , numbered 0 to 31.  
Set 31

 is reserved for the default rule.

 By default, rules are put in set 0, unless you use the set N attribute
 when entering a new rule.  Sets can be individually and atomically
 enabled or disabled, so this mechanism permits an easy way to store 
mul-
 tiple configurations of the firewall and quickly (and atomically) 
switch

 between them.  The command to enable/disable sets is
[ ... ]

---Chuck


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw changes being contemplated..

[Julian Elischer]

AT Matik wrote:

On Wednesday 18 April 2007 18:08, Julian Elischer wrote:

Also One possibility of 6 would be to make a family of
firewalls rather than one, that work together,



Hi 


probably I do not understand what you are trying to achieve ...

basicly I am missing a reason for this "making it complicated"

the beauty of ipfw is it's easy use and easy to read, short, it is clear 
so why do you want to complicate it?



e.g. L2FW (layer 2 firewall) that knows about MAC packets etc
but calls IPFW for ip packets should it want to do so.


this comes from working within ipfw.
there is a bit of "mess" added to make it (an IP layer firewall)
know about and handle link level packets.

It might be cleaner to have a separate link level firewall
then to have the hacks in ipfw to make in know about L2 stuff.

This is not something I'm working on, just something that occurs 
to me every time I have to look inside the firewall code.




that is perfectly possible today as it is


I KNOW it can do it.. but it is a mess as far as information scope is concerned.




IPFW in turn the ability to call TCPFW
for some sessions and TCPFW would know about
modules that in turn know about different
protocols.


you can perfectly write sh functions which you call under certain 
circumstances, there is no need to reinvent the wheel


you can write sh functions in ipfw? 
I don't get your point here.






IPFW could be called from the IP layer, or from the FW of a lower layer.
each layer would have the ability to do some inspection of the payload to
help decide which higher layer might be relevant.


please give a real world reason and/or example for this need, which then of 
course could not be solved be actual ipfw functions or rc.firewall script 
engineering


I work on a product that monitors on a bridge and at the IP router level.
We have some of our own changes to ipfw.
the rules get to be fairly tricky when you have so many 
entry points coming into the same firewall.
front, but if I use a  "keep state" for a packet at one 
layer then I can not use "keep-state" in another

situation for anything that may see the same packet as there is no way
to keep separate states for different entry points.
having separate firewalls for diffrent entry points allows me to 
have different state at different layers even for the same packet.








I can imagine an HTTPFW which does some small tests and if it needs to can
divert the session to a proxy. It would know some basic rules of HTTP. for
example.


could you please let out your imagination and tell some practical and usefull 
example? Of course as well a case which could not be solved by ipfw as it is?


the later (HTTPFW) is just a fanciful idea and in fact I already do that by 
'fwd' rules to forward such packets to a proxy, however

there might be more general solutions.




João








A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw changes being contemplated..

[Julian Elischer]

Max Laier wrote:

On Wednesday 18 April 2007 22:58, Julian Elischer wrote:

I'm contemplating the following changes to functionality:
I'd like suggestions and comments...

1/ Commit capability


Isn't this already there with "set"s ?


kind of, but I expressed it badly..
see the next email.




  In this change you declare a new firewall,
  and modify/build it, and then you 'commit' it so that
  the whole change is atomic.
  I have a current bug at work where automatic changes
  are made to teh firewall, but sometimes packets can arrive
  between parts of a change and lead to odd behaviour.
  For example if I have a reset rule after a skipto,
  and as part of the change I replace the skipto with something else,
  then for a moment, teh reset it exposed before the new rule is put
in. this leads to a spurious reset being sent out and terminating a
perfectly innocent session.  I can code around these sorts of things
but I'd like to do:

  ipfw duplicate to 1   # make rule list 1 a copy of the current rules
  ipfw rules 1 delete 1000
  ipfw rules 1 add 1000 skipto 2000 tcp from any to me ...
  ... (400 other changes)
  ipfw commit 1


or
  ipfw new 1   # make rule list 1 a copy of the current rules
  ipfw rules 1 add 1000 skipto 2000 tcp from any to me ...
  ... (400 other changes)
  ipfw commit 1
  rules that are unchanged would maintain their statistics.

possibly I would not need a rule list number if the ipfw program
would automatically write to the existing set if there is no new
(or duplicate) rule list, but would manipulate the 'growing' list
if it exists. (that way keeping the new behaviour as a superset
of the old behaviour).




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw changes being contemplated..

[Julian Elischer]

Luigi Rizzo wrote:

On Wed, Apr 18, 2007 at 02:52:43PM -0700, Julian Elischer wrote:

Chuck Swiger wrote:

On Apr 18, 2007, at 1:58 PM, Julian Elischer wrote:

I'm contemplating the following changes to functionality:
I'd like suggestions and comments...

1/ Commit capability
 In this change you declare a new firewall,
 and modify/build it, and then you 'commit' it so that
 the whole change is atomic.

[ ... ]

...

I'll try express it better again in a second...

ipfw sets are curently impemented by adding a set number to each rule.
By enabling and disabling the sets one controls which rules are skipped over,
however they are still all in the same linked list of rules.
If you have a set of 1000 rules and disable 999 of them, the packet still
has to follow 1000 links.


if what you want is just optimising the walk through rules,
you could do just that, i.e. add a 'the_real_next_rule' field which
gets reset when a significant change occurs (e.g. enable/disable a
set, or add/delete a rule) and initialized lazily the first time
it needs to be dereferenced.
This is the same thing that ipfw does for skipto targets,
so the mechanism is already in place somehow.


it is  but it doesn't really give me what I want with "efficient computed 
skipto"

I think I'll firm up my proposal a bit before trying to explain too much more,
but if I have tow versions of the ruleset.. one a linked list that I can edit 
easily,
and one "compiled" version that is run, then I can put the compiled version int 
an array
and do binary searching to get quickly to a random rule number instead of 
traversing
a possibly long linked list.
I can also do some interesting tricks with reference counts on the array, to 
ensure that
I don't hold any lock when traversing the firewall, which allows me to bypass all the 
problems I am currently seeing with Lock-order-reversals.


Iplan on still having the cached hints but that won't work for
"skipto tablearg ip from me to any" as 'tablearg' could be anything.




cheers
luigi


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw with nat - allowing by MAC address

[Julian Elischer]

AT Matik wrote:

On Sunday 22 April 2007 06:13, Lubomir Georgiev wrote:

As a side note - I had found "sysctl net.link.ether.ipfw=1" and it was
enabled during my endless futile attempts.
I believe that my problem lies in my rules but I can't figure out what's
wrong with them So someone please help.


you do not read with attention ...

on a router (natd) you do not have layer2 traffic, obviously then you can not 
analise it, even loading if_bridge makes no sense since there is no such 
traffic so you're wasting your time


if you need to block MACs you need to do it on switch level or put a freebsd 
bridge between the stations and your natd gateway


you are incorrect.

The data will pass through the firewall as it enters and exits the system via
the ethernet interfaces. The trick is that it will also pass through the 
firewall
when it is routing in and out of the system at the IP level.

What I always do is something like:

ipfw add 10 skipto 1000 ip from any to any not layer2
# now we are only processing packets from the ethernet layer.
keep track of sessions with MAC addresses we don't want to NAT
ipfw add 100 skipto 3000 {mac spec} keep_state
[...]


# now we do layer 3 processing.
# divide up according to interface and direction.
ipfw add 100 skipto 1000 ip from any to any in recv ${inside_interface}
ipfw add 101 skipto 1100 ip from any to any out xmit ${inside_interface}
ipfw add 102 skipto 1200 ip from any to any in recv ${outside_interface}
ipfw add 103 skipto 1300 ip from any to any out xmit ${outside_interface}
# effectively we are not filtering anything else
ipfw add 104 accept ip from any to any

ipfw add 1000 allow ip from any to any
ipfw add 1100 allow ip from any to any
# Now the outside interface where NAT happens.
# first incoming packets are always sent to NAT of they are to us.
# unless the layer2 code exempted the session in question. They will go to 3000
ipfw add 1200 check-state
ipfw add 1201 divert natd ip from any to ${outside_address}
# The same number.. drop anything not diverted.
ipfw add 1201 drop ip from any to any 
# nat/divert will reinject the packet here.

ipfw add 1202 accept ip from any to any
# now the outgoing packets.
ipfw add 1300 check-state
ifpw add 1301 accept ip from ${outside_address} to any
ipfw add 1302 divert natd ip from any to any.
# anything NATD allows through will be reinjected here.
ipfw add 1303 accept ip from any to any

# when the layer2 packets come here, just let them go on..
ipfw add 3000 accept ip from any to any layer2
# but when the layer 3 packets come here.. do something completely different.
[]




João










A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw with nat - allowing by MAC address

[Julian Elischer]

Lubomir Georgiev wrote:

 I'd like to thank all the people who replied to the thread I started. Your
help has been invaluable. The reason I didn't immediately respond to Jao is
that I wanted to make sure I wasn't mistaking - I was sure that IPFW + 
NAT +

MAC address filtering in a single box was possible because I had seen it
with my own two eyes. I just didn't take the time to see the ruleset 
then. I

was going there in a couple of days and was going to shed some light on the
subject but it turns out I don't need to - Patrick and Julian have 
backed me

up.

 I am going to try out what you've recommended and post the results. Once
again thanks for all your efforts and Jao please do try not to go all "high
and mighty" over other seeking help when what we really want is one and the
same thing - to help each other, and that I think is the purpose of this
list.

 So, I'll keep you posted.



As I posted, I think you can use keep-state to pass state between 
layer 2 and layer 3 instances of the firewall.


the trick is to remmeber that "check-state" just re-runs the rule that
had the orginal keep-state, and that that rule can be almost anything, including
a skipto.


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw with nat - allowing by MAC address

[Julian Elischer]

Patrick Tracanelli wrote:

the trick is to remmeber that "check-state" just re-runs the rule that
had the orginal keep-state, and that that rule can be almost anything, 
including

a skipto.


What if it is a FWD?


true too..
though fwd will do nothing in Layer2

use skipto  to simulate what you want to do.



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw with nat - allowing by MAC address

[Julian Elischer]

ok so I just emailed how I would do this.. Did you not receive it?


Lubomir Georgiev wrote:
 OK people - here's the deal. I have tried the setup as described by 
*Patrick

Tracanelli at *click

but the shitty thing still doesn't want to just let it be! Since I don't
want to

00500   468   30071 deny log logamount 100 ip from any to any MAC any
any layer2 via xl0


 I'm trying to integrate a rule that just skips the natd but still allows
normal client -> freebsd box communication. The problem is -   I can
manipulate layer2 any way I like e.g. use skipto with MAC as described and
everything but as soon as I add a rule like this

ipfw add 500 skipto 1400 /after the divert natd/ all from any to any not
layer2

 I lose worldwide connectivity. And if I don't add this rule my whole
192.168.1.0/24 segment in enabled because of the

01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0
01205 divert 8668 ip from any to me in via fxp0

 Can someone please explain this? And just give the word and I'll send a
more substantial part of the ruleset and the different strategies /of
rulesets :)/ that I've tried.
 The bottom line - Patrick's setup doesn't work, at least here. I'm certain
that I've written the rules they're supposed to be /just change ip ranges,
if names etc./

 10x in advance and please do bare with me...



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw with nat - allowing by MAC address

[Julian Elischer]

Lubomir Georgiev wrote:

OK, so let's get started. Here's my ruleset -

00300   131732   19262748 skipto 1200 ip from any to any { MAC any
00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2


for a packet from a client through this machine to the internet:
on the first pass (packet in ethernet receive) this skips to 1203,1205 where 
nothing happens
because divert does not work on layer 2.

on the second pass (packet entering IP stack) it goes to 500 then 1203 where it 
doesn'r match  (not output for 1203 and not to "me" for 1205.
on the third pass (packet leaving IP stack, it goes to 500 then 1203 where 
it diverts (is outgoing and from 192.x.x.x.), returning just in time for 1205.
on the 4th pass it (packet being transmitted on an ethernet) it goes to 500 and 
thus 1400 because it now has different MAC



00500 47231941536 skipto 1400 ip from any to any layer2
01203684798449298 divert 8668 ip from 192.168.1.0/24 to any out via
fxp0
0120571215   16745674 divert 8668 ip from any to me in via fxp0
*01250   410160  534966441 queue 1 ip from any to any src-port 80 via fxp0
*01251   143290   14139299 queue 1 ip from any to any dst-port 80 via fxp0
*01300  2711668 1462734503 queue 2 ip from any to any not src-port 80 via
fxp0
01400 12581325 6691776490 allow ip from any to any

I've marked the dummynet rules with an asterisk. I'm using Patrick's 
ruleset
- since I'm only allowing internet access for a single machine I've 
combined

his first two rules into one. My internal network is 192.168.1.0/24 and my
external iface is fxp0. What I'm experiencing right now as I'm using this
set is this - I have internet on this machine I desired /OK/ and on all
others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. For 
me,

the rules that concern layer2 don't do what they're supposed to and thusly
the traffic reaches rule 1203 and 1205 and onward. Interestingly enough
traffic does hit the first and second rule. Here's my uname -

FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr  8 10:54:10
EEST
2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/bogoqho  i386

And my sysctl -

bogoqho# sysctl -a | egrep "one_pass\|ether"
bogoqho#

which as you can see returns nothing using the command you instructed me to
use.

If there's anything that would help you - just say the word... Let's
brainstorm :)



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw with nat - allowing by MAC address

[Julian Elischer]

Julian Elischer wrote:

Lubomir Georgiev wrote:

OK, so let's get started. Here's my ruleset -

00300   131732   19262748 skipto 1200 ip from any to any { MAC any
00:19:d2:36:b8:48 or MAC 00:19:d2:36:b8:48 any } layer2


for a packet from a client through this machine to the internet:
on the first pass (packet in ethernet receive) this skips to 1203,1205 
where nothing happens

because divert does not work on layer 2.

on the second pass (packet entering IP stack) it goes to 500 then 1203 
where it doesn'r match  (not output for 1203 and not to "me" for 1205.
on the third pass (packet leaving IP stack, it goes to 500 then 1203 
where it diverts (is outgoing and from 192.x.x.x.), returning just in 
time for 1205.
on the 4th pass it (packet being transmitted on an ethernet) it goes to 
500 and thus 1400 because it now has different MAC




What I meant to say is that keeping all this sort of thing in mind all the time
makes it hard to debug this, which is why in my example I alwyays send the 
different
passes to separate rules as quickly as possible.


00500 47231941536 skipto 1400 ip from any to any layer2
01203684798449298 divert 8668 ip from 192.168.1.0/24 to any 
out via

fxp0
0120571215   16745674 divert 8668 ip from any to me in via fxp0
*01250   410160  534966441 queue 1 ip from any to any src-port 80 via 
fxp0
*01251   143290   14139299 queue 1 ip from any to any dst-port 80 via 
fxp0

*01300  2711668 1462734503 queue 2 ip from any to any not src-port 80 via
fxp0
01400 12581325 6691776490 allow ip from any to any

I've marked the dummynet rules with an asterisk. I'm using Patrick's 
ruleset
- since I'm only allowing internet access for a single machine I've 
combined
his first two rules into one. My internal network is 192.168.1.0/24 
and my

external iface is fxp0. What I'm experiencing right now as I'm using this
set is this - I have internet on this machine I desired /OK/ and on all
others with ip 192.168.1.X /not OK, obviously :)/ regardless of MAC. 
For me,
the rules that concern layer2 don't do what they're supposed to and 
thusly

the traffic reaches rule 1203 and 1205 and onward. Interestingly enough
traffic does hit the first and second rule. Here's my uname -

FreeBSD bogoqho.com 6.1-RELEASE FreeBSD 6.1-RELEASE #1: Sun Apr  8 
10:54:10

EEST
2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/bogoqho  i386

And my sysctl -

bogoqho# sysctl -a | egrep "one_pass\|ether"
bogoqho#

which as you can see returns nothing using the command you instructed 
me to

use.

If there's anything that would help you - just say the word... Let's
brainstorm :)



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw with nat - allowing by MAC address

[Julian Elischer]

[EMAIL PROTECTED] wrote:

Ok, I got home (when I have some time) and tried exactly your rule set.
The main deal why it worked on my example and not your approach is:

- once packets get dropped (denied) on layer2, it will never reach upper
layers

Thus, NO OTHER action besides deny will avoid the packet getting into
ip_input or ip_output.

This is crystal-clear on man page, on PACKET FLOW session, and yes,
sometimes we just ignore the man pages, this si why I found very strange
when I tried your setup and it showed the exact behavior you described (as
I didnt expect).

What was happening:

When you skipped packets on layer2 to somewhere-else, it was ONLY skipped
for layer2. Since the packet was still in the network stack, when it
hitted upper layers (ip_input or ip_output) the rule MATCHED the packet.
In  your set, the DIVERT rule matched the packet, and it obviously got
diverted.



I'm adding code to make divert work at layer 2 too.
(We have that at work).
so be careful.



What I did to find it out was:

tail -f /var/log/security | grep 1203

Among other "debug funs", using the ruleset present in the body of this
message.

So, we can be sure that SKIPTO, ALLOW or anything else on Layer2 will
NEVER avoid a packet getting filtered on upper layers.

So, what we needed? A way to identify packets the we dont want to divert.
Which packets we dont want to divert? That ones that, while were flowing
on Layer, DID NOT match the ruleset comparing MAC address. We need to
point the finger and say:

- Hey, you dont have the allowed MAC address, so you wont get diverted

Or we could finger:

- Hey, you have the allowed MAC, so you will be diverted.

Doesnt matter for the system, matters for who is making the rulesets. But
how to do this?

My approach was tagging the ones that did not have the allowed MAC.

Please, read rule 501.

Its action is skipto. Why? Because I was lazy and did not want to rewrite
it as a "count" rule, because in fact, it does NOTHING to the current
ruleset. It skips to somewhere were there is no layer2 rules. So it skips
to nowhere and the packet reaches the "allow from any to any" while on
layer2 flow. Meaning, it only tags. That is enough.

Later, on rule 203 and 205 (selective divert) we only divert the packets
that was not tagged (the allowed MAC). Please note that rule 501 is about
the internal interface. If we make a mistake and do it for all interfaces,
our own (as "our own" pleas read: "the firewall, "me") packets will get
tagged 1. This is not what we want.

Please keep reading:

-

# MY TESTING RULESET

my_mac="00:17:31:df:bc:ab/48"
my_net="10.69.0.0/16"
ife="vr0" # external if
ifi="xl0" #internal

/sbin/sysctl net.link.ether.ipfw=1

ipfw -f f

ipfw add 300 skipto 1200 ip from any to any { MAC any $my_mac or MAC
$my_mac any } layer2 // try lubomir_s approach
#ipfw add 301 skipto 1200 ip from any to any MAC $my_mac any layer2 // not
needed since lubomir_s approach worked fine
#ipfw add 500 deny all from any to any layer2
ipfw add 501 skipto 1400 tag 1 log logamount 0 ip from any to any layer2
via $ifi // skipto only on L2 and tag for further ch
ipfw add 1200 count log all from any to any layer2 // somebody passed here
- check the logs
ipfw add 1203 divert 8668 log logamount 0 ip from $my_net to any out via
$ife not tagged 1
ipfw add 1205 divert 8668 log logamount 0 ip from any to me in via $ife
not tagged 1
ipfw add 1240 count log logamount 0 all from any to any diverted not
layer2 // lets see whos got here diverted
ipfw add 1250 queue 1 ip from any to any src-port 80 via $ife not layer2
ipfw add 1251 queue 1 ip from any to any dst-port 80 via $ife not layer2
ipfw add 1300 queue 2 ip from any to any not src-port 80 via $ife not layer2
ipfw add 1398 count log logamount 0 all from any to any diverted not
layer2 // lets see whos got here diverted - since one_pa
ipfw add 1399 count log logamount 0 all from any to any not diverted not
layer2 // lets see whos got here undiverted
ipfw add 1440 allow ip from any to any

ipfw queue 1 config weight 10 mask src-ip 0x00ff pipe 1
ipfw queue 2 config weight 2 mask src-ip 0x00ff pipe 1
ipfw pipe 1 config bw 4Mbit/s queue 30

-

Maybe the better and more clear (to read and understand) approach would be:

- tag on laye2 packets with the ALLOWED MAC
- on upper layers, only divert packets tagged 1
- be sure no other rule will tag packets with tag 1
- be sure ng_tag wont tag packets with tag 1

Anything else on FreeBSD besides ipfw and netgraph are able to tag
packets? Probably not right now. Maybe a geom class one day (hehe, just
kidding..). PF tags are not compatible with ipfw/netgraph ones so, no
special attention is required.

Hope I could help you better this turn.





OK, so let's get started. Here's my ruleset -

00300   131732   19262748 skipto 1200 ip from any to any { MAC any
00:19:d2:36:b8:48 or MAC 00

Re: ipfw with nat - allowing by MAC address

[Julian Elischer]

I'm surprised you haven't tried the firewall set I sent you..
I practically wrote the whole thing for you.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw with nat - allowing by MAC address

[Julian Elischer]

Lubomir Georgiev wrote:

 Yeah! People, we can congratulate ourselves! We've done it! With a few
modifications I've finally found the smallest working MAC filtered NAT
system. So here's what I ended up with - I'm including the queues just for
the entirety of the ruleset, they have nothing to do with the filtering.


I presume xl0 is the inside interface?

here is how you should comment your script.





# The following rules are applied at layer 2 and layer 3.
# Allow anything on the inside to talk to me directly if it wants to,
# * unless it wants to use port 8668  * (why 8668?)
ipfw add 00100 allow ip from any to me not dst-port 8668 via xl0
ipfw add 00101 allow ip from me not 8668 to any via xl0

#
# BTW also.. try not use the via keyword.. instead specify exactly what you want
# as it hides exactly what you are doing.. use in, out, recv and xmit
# (possibly in combination).

# Anything that is not to me directly is bound for the outside.
# At layer 2 we clobber any that are not 'blessed machines'.
ipfw add 00300 "allow ip from any to any { MAC 00:19:d2:36:b8:48 any or MAC any 
00:19:d2:36:b8:48 } layer2"
ipfw add 00800 "deny log logamount 200 ip from any to any MAC any any layer2 via 
xl0"

# easier written as
# ipfw add 800 deny log logamount 200 ip from any to any layer2

# In layer 2 we have no more packets by this point.
# In layer 3, only packets that escaped layer 2 alive get diverted
ipfw add 01203 divert 8668 ip from 192.168.1.0/24 to any out via fxp0
ipfw add 01205 divert 8668 ip from any to me in via fxp0

# The rest is for conditionning the traffic on the external link



01250 queue 1 ip from any to any src-port 80 not layer2 via fxp0
01251 queue 1 ip from any to any dst-port 80 not layer2 via fxp0
01300 queue 2 ip from any to any not src-port 80 not layer2 via fxp0
01500 allow ip from any to any
65535 deny ip from any to any


 Just one note - when I first reached this conclusion I had two very
strange *blackouts*. As if the 100 and the 101 rule just suddenly stop
working and I'm left out of the box e.g. I can't ssh in although the
diverting still works - I can ping hosts on the Internet. It seems to be
fine now and once I gain some knowledge I'm probably going to expand this
ruleset, but for now I've accomplished my goal!

 I have all of you to thank for that! Even though it wasn't easy /mostly
because of my ignorance I'm sure/ you pulled me through.


 Respect.




 One last request - if someone happens to have some free time and wishes to
donate it to me I'd really like to better understand the whole *layer*
thing. I have searched the Internet for answers on this as well as read the
ipfw man page, but I can't really understand it.

 \/  Peace.



and here is how I would write it:
#!/bin/sh

INSIDE="xl0"
OUTSIDE="fxp0"
BLESSED_MAC="00:19:d2:36:b8:48"
OUTSIDE_IP="1.1.1.1"

#
# START. ALL PACKETS FROM EVERYWHERE COME HERE. #
# A packet being routed comes here 4 times. #
#
# first split up the layer 2 packets and layer 3 packets
ipfw add 100 skipto 1000 ip from any to any not layer2

###
# ## START LAYER 2 PROCESSING #
# this happens as the packet is traversing
# the ethernet driver.
# A routed packet comes here TWICE.
#
# In layer 2 just allow packets not traversing the inside 
# interface as we have no interest in other interfaces.

# Now split up incoming and outgoing.
ipfw add 110 skipto 120 ip from any to any in

 PACKETS EXITING ${INSIDE} #
# packet is exiting the INSIDE ethernet
# If it is not from us, and not to a blessed machine, kill it.
ipfw add 111 allow ip from any to any not xmit ${INSIDE}

#ipfw add 112 allow ip from me to any 
#ipfw add 113 allow ip from any to any MAC {$BLESSED_MAC} any

#ipfw add 114 deny ip from any to any

# this is actually pointless as there will be no such traffic,
# so in fact just allow everything.
ipfw add 112 allow ip from any to any

#  PACKETS COMING IN THROUGH ${INSIDE} 
# If it is not to us, and not from a blessed machine, kill it.
ipfw add 120 allow ip from any to any not recv ${INSIDE}
ipfw add 122 allow ip from any to me
ipfw add 124 allow ip from any to any MAC any ${BLESSED_MAC}
ipfw add 126 deny log logamount 200 ip from any to any

##
# END OF ALL LAYER 2 PROCESSING  #
##
# START LAYER 3 PROCESSING   #
##
# SPLIT FOR DIRECTION
ipfw add 1000 skipto 1500 ip from any to any in

# ## OUTGOING PROCESSING 
# ignore everything not on "${OUTDSIDE}".. we just don't care.
# NAT anything that is not from my outside address.
ipfw add 1100 allow ip from any to any not xmit ${OUTSIDE}
ipfw add 1110 divert natd ip from not ${OUTSIDE_I

Re: kern/107305: [ipfw] ipfw fwd doesn't seem to work

[Julian Elischer]

Andrey V. Elsukov wrote:

The following reply was made to PR kern/107305; it has been noted by GNATS.





This was fixed in 6.[later] (6.2 at least, maybe 6.1)
(The need for the EXTENDED option)

 
 -- 
 WBR, Andrey V. Elsukov

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Policy Routing natd+ipfw

[Julian Elischer]

Jason Hills wrote:

Hello.

How can I do policy routing with ipfw+natd?

I started 2 natd processes, using natd.conf and natd2.conf
respectively, but things dont work. My rules are:

ext_ifi1="em0"
ext_ifi2="em1"

divert 8668 ip from $net1 to any out via $ext_if1
divert 8669 ip from $net2 to any out via $ext_if2

divert 8668 ip from any to any via $ext_if1
divert 8669 ip from any to any via $ext_if2

My defaultrouter is the one on $ext_if1.

It works for port 8668 but doesnt work for 8669 (the second xDSL link)



what version of freeBSD?

in -current you can implement a routing table via FWD and tables.
in  6.x you need to specify the next hop. and an more explicit rule.

the fwd rule is a terminal rule.. (processing does not continue, however
while divert is a termianl rule, the natd reinjects the packet back into the 
firewall at eh rule number AFTER thr rule that did the divert,

so you can treat it as if it was non terminating.

this means that you need to do the NAT before you do the FWD.



julian






___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Policy Routing natd+ipfw

[Julian Elischer]

Kirk Davis wrote:
 
Julian Elischer wrote:

in -current you can implement a routing table via FWD and tables.
in  6.x you need to specify the next hop. and an more explicit rule.


   Is there any information floating around on how to do this in current
using the FWD rules and tables? Any pointer on where to look.


man ipfw on -current

basically you can implement alternate routing tables..

ipfw table 1 add 0.0.0.0/0 4.5.6.7 # default route for table 1
ipfw table 1 add 2.3.4.0/24 5.4.3.2 # but not for packets to 2.3.4.x
ipfw table 2 add 0.0.0.0/0 7.6.5.4 #default route for table 2
ipfw table 2 add 2.3.4.0/24 6.5.4.3 # but differnet route for packets to 2.3.4.x



ipfw add 100 allow ip from 1.2.3.0/24 to any out
ipfw add 110 fwd tablearg ip from 1.2.4.0/24 to table(1) out
ipfw add 120 fwd tablearg ip from 1.2.5.0/24 to table(2) out








   Right now I am using fwd rules on our BGP router (Quagga & FreeBSD
6.2) to force one of our subnets out a particular interface and avoid
the routing table but I would prefer to do it more like a dual routing
table where I can make more routing decisions than just forcing all
packets from that subnet out the interface.  I could test it on one of
our current boxes.


julian


 Kirk


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Policy Routing natd+ipfw

[Julian Elischer]

Kirk Davis wrote:
 
Julian Elischer wrote:

in -current you can implement a routing table via FWD and tables.
in  6.x you need to specify the next hop. and an more explicit rule.


   Is there any information floating around on how to do this in current
using the FWD rules and tables? Any pointer on where to look.

   Right now I am using fwd rules on our BGP router (Quagga & FreeBSD
6.2) to force one of our subnets out a particular interface and avoid
the routing table but I would prefer to do it more like a dual routing
table where I can make more routing decisions than just forcing all
packets from that subnet out the interface.  I could test it on one of
our current boxes.


actually the kernel code is in the 6 branch but the 
ipfw program has not been taught how to set the values yet..






julian


 Kirk
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: a sysctl variable to query last ipfw rule number

[Julian Elischer]

A. Skrobov wrote:

Such a variable is useful in scripts that add blocks of rules
containing skipto actions; instead of hardcoding numbers for all the
rules, they could be derived dynamically.


I'm also looking at a version of skipto that uses RELATIVE numbering.
(called just 'skip') 
i.e.

ipfw add 100 skip 50 ip from xxx to yyy
ipfw add 120 some rule
ipfw add 150 count log ip from any to any # skip rule comes here.




As an additional bonus, keeping track of the last rule number reduces
overhead in add_rule when no rule number is specified (and partially
puts that overhead to remove_rule instead). Since rules are added more
often than they are deleted, this seems a performance improvement as
well.


The one problem I see with this is that you are using a sysctl.
This is ok for now but I'm (in the background) working on 
having more that one instance of a firewall.




Could someone please review my patch? It's made for a very old ipfw2
version, the one bundled with 5.4-RELEASE, but the relevant code
doesn't seem to have changed since then.

*** ip_fw2.c.origSun Feb  6 21:16:20 2005
--- ip_fw2.cTue May  8 23:38:37 2007
***
*** 191,196 
--- 191,197 

 static int fw_debug = 1;
 static int autoinc_step = 100; /* bounded to 1..1000 in add_rule() */
+ static unsigned int last_rule = 0;

 #ifdef SYSCTL_NODE
 SYSCTL_NODE(_net_inet_ip, OID_AUTO, fw, CTLFLAG_RW, 0, "Firewall");
***
*** 199,204 
--- 200,207 
 &fw_enable, 0, "Enable ipfw");
 SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, autoinc_step, CTLFLAG_RW,
 &autoinc_step, 0, "Rule number autincrement step");
+ SYSCTL_UINT(_net_inet_ip_fw, OID_AUTO, last_rule, CTLFLAG_RD,
+ &last_rule, 0, "Number of last added rule");
 SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, one_pass,
 CTLFLAG_RW | CTLFLAG_SECURE3,
 &fw_one_pass, 0,
***
*** 2585,2595 
 /*
  * locate the highest numbered rule before default
  */
! for (f = chain->rules; f; f = f->next) {
! if (f->rulenum == IPFW_DEFAULT_RULE)
! break;
! rule->rulenum = f->rulenum;
! }
 if (rule->rulenum < IPFW_DEFAULT_RULE - autoinc_step)
 rule->rulenum += autoinc_step;
 input_rule->rulenum = rule->rulenum;
--- 2588,2594 
 /*
  * locate the highest numbered rule before default
  */
! rule->rulenum = last_rule;
 if (rule->rulenum < IPFW_DEFAULT_RULE - autoinc_step)
 rule->rulenum += autoinc_step;
 input_rule->rulenum = rule->rulenum;
***
*** 2612,2617 
--- 2611,2618 
 }
 flush_rule_ptrs(chain);
 done:
+ if (last_rule < rule->rulenum)
+ last_rule = rule->rulenum;
 static_count++;
 static_len += l;
 IPFW_WUNLOCK(chain);
***
*** 2631,2637 
 static struct ip_fw *
 remove_rule(struct ip_fw_chain *chain, struct ip_fw *rule, struct ip_fw 
*prev)

 {
! struct ip_fw *n;
 int l = RULESIZE(rule);

 IPFW_WLOCK_ASSERT(chain);
--- 2632,2638 
 static struct ip_fw *
 remove_rule(struct ip_fw_chain *chain, struct ip_fw *rule, struct ip_fw 
*prev)

 {
! struct ip_fw *n, *f;
 int l = RULESIZE(rule);

 IPFW_WLOCK_ASSERT(chain);
***
*** 2647,2652 
--- 2648,2660 
 static_count--;
 static_len -= l;

+ if (rule->rulenum >= last_rule) /* it should always be <=, but who 
knows */

+ for (f = chain->rules; f; f = f->next) {
+ if (f->rulenum == IPFW_DEFAULT_RULE)
+ break;
+ last_rule = f->rulenum;
+ }
+
 rule->next = chain->reap;
 chain->reap = rule;

***
*** 2690,2695 
--- 2698,2705 
 prev = rule;
 rule = rule->next;
 }
+
+ last_rule = 0; /* how come static_count doesn't need the explicit 
reset? */

 }

 /**
***
*** 3454,3459 
--- 3464,3470 
 IPFW_LOCK_DESTROY(&layer3_chain);
 return (error);
 }
+ last_rule = 0;

 ip_fw_default_rule = layer3_chain.rules;
 printf("ipfw2 initialized, divert %s, "
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Policy Routing natd+ipfw

[Julian Elischer]

Julian Elischer wrote:



actually the kernel code is in the 6 branch but the ipfw program has not 
been taught how to set the values yet..


I just committed the change to RELENG_6 so the head of the 6 branch should be 
able to do this now.








julian


 Kirk
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Policy - based Routing problem Need help

[Julian Elischer]

Narek Gharibyan wrote:

Hi all,

I have a firewall/router with FreeBSD 6.2 installed on it. 2 ISP connection
and 2 LAN connections. I need to do a policy-based routing. All I need that
packets coming from one ISP interface return to that interface (incoming
connections' source based routing) and the other hand do a IP based routing
from the LAN (Some packets will goes out via ISP 1 some others via ISP 2
depending on IPs requested). I tried to do that with ipfw fwd but it didn't
work any way (e.g. with ip.forwarding enabled or no). Even I've disabled my
static routes, default gw. Just it do nothing. Sample configs are

ipfw add fwd ISP_gw from ${my lan} to any via ${eif}
ipfw add fwd ISP_gw from ${my lan} to any out via ${eif}
ipfw add fwd ISP_gw from any to any xmit ${eif}

Ipfw add fwd ISP_gw from any to any via ${eif} out

I don't use nat, proxy. Just need to route.


not using nat is a problem, because packets from the 
internet will all want to come 
back to you on only one of the interfaces.



usually what is done is to nat on both interfaces, and
use BGP or something to decide which interface is the most efficient
for the packet to go out on.. the return packet 
will come back the same way due to the NATing.


 


Please help

 


Regards,

Narek

 


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Policy - based Routing problem Need help

[Julian Elischer]

Narek Gharibyan wrote:

Hi all,

I have a firewall/router with FreeBSD 6.2 installed on it. 2 ISP connection
and 2 LAN connections. I need to do a policy-based routing. All I need that
packets coming from one ISP interface return to that interface (incoming
connections' source based routing) and the other hand do a IP based routing
from the LAN (Some packets will goes out via ISP 1 some others via ISP 2
depending on IPs requested). I tried to do that with ipfw fwd but it didn't
work any way (e.g. with ip.forwarding enabled or no). Even I've disabled my
static routes, default gw. Just it do nothing. Sample configs are

ipfw add fwd ISP_gw from ${my lan} to any via ${eif}
ipfw add fwd ISP_gw from ${my lan} to any out via ${eif}
ipfw add fwd ISP_gw from any to any xmit ${eif}




I believe you want to route INCOMING sessions right?

what is the topology of the rest of your network?




Ipfw add fwd ISP_gw from any to any via ${eif} out

I don't use nat, proxy. Just need to route.
 


Please help

 


Regards,

Narek

 


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: redirect traffic based on destination port to another interface

[Julian Elischer]

Rudy Setiawan wrote:

Hi,

I am trying to do a traffic redirection based on destination port to
another interface/gateway.
Currently, I have a freebsd box that does simple NAT and an Internet connection.
I am planning to install another internet connection and use the same
box to do some traffic redirection.


INTERNET1  freebsd box --- INTERNET2
 |
 |
   Local Area Network

LAN = 192.168.10.0/24 with interface em0
INTERNET1-GW = x.x.x.1 with em1
INTERNET2-GW = y.y.y.1 with rl0

My goal is to redirect any ssh traffic to INTERNET2-GW and I assume
that if it can be redirected through INTERNET2-GW then the packets
return will go through INTERNET2-GW also.



no, unless you first NAT the packets with the address of that interface.
(otherwise the packets will come back through your primary network).
if yo have cheep dlink or linksys or whatever DSL routers or whatever with NAT
on them then you can use that successfully and just use ipfw 'fwd' rules to 
select the interface to use.



Is it possible to do that way with ipfw or natd?


yes but you need both forwarding and nat..




Thank you

Regards,
Rudy




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: redirect traffic based on destination port to another interface

[Julian Elischer]

Rudy Setiawan wrote:

On 8/2/07, Julian Elischer <[EMAIL PROTECTED]> wrote:

Rudy Setiawan wrote:

Hi,

I am trying to do a traffic redirection based on destination port to
another interface/gateway.
Currently, I have a freebsd box that does simple NAT and an Internet connection.
I am planning to install another internet connection and use the same
box to do some traffic redirection.


INTERNET1  freebsd box --- INTERNET2
 |
 |
   Local Area Network

LAN = 192.168.10.0/24 with interface em0
INTERNET1-GW = x.x.x.1 with em1
INTERNET2-GW = y.y.y.1 with rl0

My goal is to redirect any ssh traffic to INTERNET2-GW and I assume
that if it can be redirected through INTERNET2-GW then the packets
return will go through INTERNET2-GW also.


no, unless you first NAT the packets with the address of that interface.
(otherwise the packets will come back through your primary network).
if yo have cheep dlink or linksys or whatever DSL routers or whatever with NAT
on them then you can use that successfully and just use ipfw 'fwd' rules to 
select the interface to use.


I see, hmm are you suggesting that the linksys should be placed
between the freebsd firewall and the internet? Then do a ipfw fwd
rules to in freebsd to select which interface to go and linksys will
do all the NAT-ing for those packets respectiveily right?


exactly



Thank you.

Regards,
Rudy


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: redirect traffic based on destination port to another interface

[Julian Elischer]

Rudy Setiawan wrote:

can you run two instances of natd?


yes.

you can even get natd to run two separate translation sets but I hav enever 
done it.
(phk added code to allow that some time ago I believe)

of course you don't need that if you have NAT devices on each link anyway.
($40 each..)




Thank you.

Regards,
Rudy


On 8/3/07, Julian Elischer <[EMAIL PROTECTED]> wrote:

Rudy Setiawan wrote:

On 8/2/07, Julian Elischer <[EMAIL PROTECTED]> wrote:

Rudy Setiawan wrote:

Hi,

I am trying to do a traffic redirection based on destination port to
another interface/gateway.
Currently, I have a freebsd box that does simple NAT and an Internet connection.
I am planning to install another internet connection and use the same
box to do some traffic redirection.


INTERNET1  freebsd box --- INTERNET2
 |
 |
   Local Area Network

LAN = 192.168.10.0/24 with interface em0
INTERNET1-GW = x.x.x.1 with em1
INTERNET2-GW = y.y.y.1 with rl0

My goal is to redirect any ssh traffic to INTERNET2-GW and I assume
that if it can be redirected through INTERNET2-GW then the packets
return will go through INTERNET2-GW also.


no, unless you first NAT the packets with the address of that interface.
(otherwise the packets will come back through your primary network).
if yo have cheep dlink or linksys or whatever DSL routers or whatever with NAT
on them then you can use that successfully and just use ipfw 'fwd' rules to 
select the interface to use.

I see, hmm are you suggesting that the linksys should be placed
between the freebsd firewall and the internet? Then do a ipfw fwd
rules to in freebsd to select which interface to go and linksys will
do all the NAT-ing for those packets respectiveily right?

exactly


Thank you.

Regards,
Rudy







___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: getting state to work properly

[Julian Elischer]

Vadim Goncharov wrote:

31.08.07 @ 00:41 Russell Fulton wrote:


Rule set appended -- anonymizing the rule set while keeping the sense
would be a lot of work and I don't want to trim it down for fear of
dropping something vital.  As this network is not exposed to the
internet and the firewall's  primary purpose is traffic shaping not
security I'll post it.

Attached.


Some summary points:


also bear in mind the way that state is done..
it's not documented anywhere but when you do a 'keep-state', the rule that
does the keep-state is stored away, and when a "check state" is run,
it effectively JUMPS TO the rule that did the keep-state.

If the rule contains some action that is not terminal, then EXECUTION CONTINUES
at that point!!!

for example


check-state
[...]
"some rules"
[...]
skipto xxx [packet definition] keep state


xxx: more rules


the first packet will execute all of "some rules"
but subsequent packets from thise sessions will skip straight to 
the skipto.


All packets will do the test in the skipto rule, and subsequent rules.





1) localhost traffic should be unconditionally allowed at the start of 
firewall, state here is useless.
2) antispoofing can be more clearly done with antispoof and verrevpath 
keywords. Like:


ipfw add 100 pass all from any to any via lo0
ipfw add 110 deny all from any to any in recv $extiface not verrevpath
ipfw add 111 deny log all from any to any in recv $intiface not antispoof
ipfw add 112 check-state

3) Using "setup" option while protocol is "all" is unclear - it will 
match only tcp, while you possibly ment to keep-state on every protocol, 
not just tcp.
4) Consider using sysctl net.inet.ip.fw.one_pass - it controls whether 
traffic after getting out from pipe will continue go through ipfw ruleset.
5) Don't forget that ipfw has two passes, input and output, so if you 
are sending traffic from A to B into pipe without "in" or "out" options, 
speed will be half of that specified in a pipe.








___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/116009: [ipfw] [patch] Ignore errors when loading ruleset from file + rule replacement command

[Julian Elischer]

The following reply was made to PR kern/116009; it has been noted by GNATS.

From: Julian Elischer <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED],  [EMAIL PROTECTED]
Cc:  
Subject: Re: kern/116009: [ipfw] [patch] Ignore errors when loading ruleset
 from file + rule replacement command
Date: Tue, 04 Sep 2007 04:06:25 -0700

 I added some code already last year to allow ipfw to continue on after some 
failures
 if the -q option is in use (especially delete). I certainly do agree that 
 bombing out is a less that optimal behaviour when automatic 
 use is required.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: source based forwarding code

[Julian Elischer]

Srimanta BSD wrote:

Hi,

 Can someone please send me the link to download Source Based Forwarding
implementation in FreeBsd 6.2 or other version.



we use the firewall(s) to do so..

Look in the ipfw man pages for the 'fwd' command for ipfw.
For pf there is another command, the name of which I forget right now.

 
Thanks,

Srimanta


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW Problem

[Julian Elischer]

Gardner Bell wrote:

I'm hoping some of you can help me out with the problem that I'm having
as I'm not very good when it comes to networking..

I've recently configured 6.3-PRERELEASE with IPFW/NATD to act as my
LAN's firewall/router.  After I initially access certain http sites,
particularly google groups and yahoo web mail I'm noticing subsequent
attempts take > 2mins to resolve the next link that I am interested in
reading.  


This appears to be caused by rule 01000 as the counter increases each
time I access one of the above mentioned sites.

Short of removing this rule, is there any other way that I can fix this
issue?  Below is a listing of my present ruleset and a tcpdump of a
Windows XP machine trying to access a link on google groups.

regards,

Gardner

mx1# ipfw show
00100   76  11134 allow ip from 127.0.0.1 to 127.0.0.1 via lo0
002000  0 deny log logamount 10 ip from 127.0.0.1 to any
003000  0 deny log logamount 10 ip from any to 127.0.0.1
004000  0 deny log logamount 10 ip from any to any not
verrevpath in
005000  0 deny log logamount 10 ip from any to any ipoptions
ssrr,lsrr,rr,ts in
006000  0 deny ip from any to any frag
007000  0 allow icmp from any to any icmptypes 0,3,11,12
00800 1081 452405 divert 8668 ip from any to any via bge0
009000  0 check-state
01000   36  17682 deny tcp from any to any established
01100 2704 853904 allow ip from any to any via bge1 keep-state
01200  262  57586 allow tcp from any to any dst-port 80 keep-state
013000  0 allow tcp from any to any dst-port 443 keep-state
01400  102   7752 allow udp from me to any dst-port 123 keep-state
015000  0 allow tcp from me to any dst-port 53 setup keep-state
01600  169  30563 allow udp from me to any dst-port 53 keep-state
017000  0 allow tcp from any to any dst-port 1863 setup
keep-state
018000  0 allow log logamount 10 udp from any to
255.255.255.255 dst-port 68 in via bge0
019000  0 allow tcp from x.x.x.x to x.x.x.x dst-port 22
keep-state
020000  0 deny log logamount 10 ip 


After many years fo doing ipfw rules at work I've cone to the conclusion that
one needs to be more explicit about what is going on that most ipfw rulesets 
are:


for example:
Assuming bge0 is on the outside, and bge1 is on the inside...

#split to incoming and outgoing (from this system) packets.
ipfw add 1 skipto 1000 ip from any to any in

 Output interface sorting #
# now do output processing. Split up according to interface:
ipfw add 100 allow ip from any to any via lo0
ipfw add 110 skipto 3400 ip from any to any out xmit bge0
ipfw add 120 skipto 2400 ip from any to any out xmit bge1
# what is left? should never happen.
ipfw add 130 drop log ip from any to any 


### Input interface sorting ###\
# split up according to source interface.
# do checking for lo0 an dloopback addr.
ipfw add 1000 accept ip from any to any via lo0
ipfw add 1010 drop log ip from any to 127.0.0.1/8

ipfw add 1020 skipto 2300 ip from any to any recv bge0
ipfw add 1030 skipto 3300 ip from any to any recv bge1

# should never happen so log it:
ipfw add 1040 drop log ip from any to any

#
### Per interface - per-direction filters ###
#


 Inside Interface input filters 
# trust the inside.
ipfw add 2300 accept ip from any to any


 Inside interface output filters ###
# things to do for packets leaving towards the inside.
ipfw add 2400 allow ip from any to any


#
 Outside interface input 
# process packets coming in from the Internet.
# do special processing for packets not of interest to NATD.
ipfw add 3300 skipto 1260 ip from any to not me
# If they are aimed at our inside address, pass them to NATD.
# it should pass on packets that are just to us if set up right.
ipfw add 3310 divert 8668 ip from any to me 
# packets diverted and reinjected come here

ipfw add 3320 accept ip from any to any

# for now no special processing..
ipfw add 3360 drop log ip from any to any

 Outside Interface output
# things we need to do for packets leaving via bge0 to the Internet.
# Nat packets that are suitable. Don't wast time NATing other packets.
ipfw add 3400 divert 8668 ip from not me to any recv bge1
#nat'd packets will turn up here when re-injected.
ipfw add 3410 allow ip from any to any.



now you can put in rules that are specific to exactly certain traffic
and know what the h*ck is going on.






___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW Problem

[Julian Elischer]

Gardner Bell wrote:

--- Julian Elischer <[EMAIL PROTECTED]> wrote:


Gardner Bell wrote:

I'm hoping some of you can help me out with the problem that I'm

having

as I'm not very good when it comes to networking..

I've recently configured 6.3-PRERELEASE with IPFW/NATD to act as my
LAN's firewall/router.  After I initially access certain http

sites,

particularly google groups and yahoo web mail I'm noticing

subsequent

attempts take > 2mins to resolve the next link that I am interested

in
reading.  


This appears to be caused by rule 01000 as the counter increases

each

time I access one of the above mentioned sites.

Short of removing this rule, is there any other way that I can fix

this

issue?  Below is a listing of my present ruleset and a tcpdump of a
Windows XP machine trying to access a link on google groups.

regards,

Gardner

mx1# ipfw show
00100   76  11134 allow ip from 127.0.0.1 to 127.0.0.1 via lo0
002000  0 deny log logamount 10 ip from 127.0.0.1 to any
003000  0 deny log logamount 10 ip from any to 127.0.0.1
004000  0 deny log logamount 10 ip from any to any not
verrevpath in
005000  0 deny log logamount 10 ip from any to any

ipoptions

ssrr,lsrr,rr,ts in
006000  0 deny ip from any to any frag
007000  0 allow icmp from any to any icmptypes 0,3,11,12
00800 1081 452405 divert 8668 ip from any to any via bge0
009000  0 check-state
01000   36  17682 deny tcp from any to any established
01100 2704 853904 allow ip from any to any via bge1 keep-state
01200  262  57586 allow tcp from any to any dst-port 80 keep-state
013000  0 allow tcp from any to any dst-port 443 keep-state
01400  102   7752 allow udp from me to any dst-port 123 keep-state
015000  0 allow tcp from me to any dst-port 53 setup

keep-state

01600  169  30563 allow udp from me to any dst-port 53 keep-state
017000  0 allow tcp from any to any dst-port 1863 setup
keep-state
018000  0 allow log logamount 10 udp from any to
255.255.255.255 dst-port 68 in via bge0
019000  0 allow tcp from x.x.x.x to x.x.x.x dst-port 22
keep-state
020000  0 deny log logamount 10 ip 

After many years fo doing ipfw rules at work I've cone to the
conclusion that
one needs to be more explicit about what is going on that most ipfw
rulesets are:


for example:
Assuming bge0 is on the outside, and bge1 is on the inside...

#split to incoming and outgoing (from this system) packets.
ipfw add 1 skipto 1000 ip from any to any in

 Output interface sorting #
# now do output processing. Split up according to interface:
ipfw add 100 allow ip from any to any via lo0
ipfw add 110 skipto 3400 ip from any to any out xmit bge0
ipfw add 120 skipto 2400 ip from any to any out xmit bge1
# what is left? should never happen.
ipfw add 130 drop log ip from any to any 


### Input interface sorting ###\
# split up according to source interface.
# do checking for lo0 an dloopback addr.
ipfw add 1000 accept ip from any to any via lo0
ipfw add 1010 drop log ip from any to 127.0.0.1/8

ipfw add 1020 skipto 2300 ip from any to any recv bge0
ipfw add 1030 skipto 3300 ip from any to any recv bge1

# should never happen so log it:
ipfw add 1040 drop log ip from any to any

#
### Per interface - per-direction filters ###
#


 Inside Interface input filters 
# trust the inside.
ipfw add 2300 accept ip from any to any


 Inside interface output filters ###
# things to do for packets leaving towards the inside.
ipfw add 2400 allow ip from any to any


#
 Outside interface input 
# process packets coming in from the Internet.
# do special processing for packets not of interest to NATD.
ipfw add 3300 skipto 1260 ip from any to not me


   should be 3360


# If they are aimed at our inside address, pass them to NATD.
# it should pass on packets that are just to us if set up right.
ipfw add 3310 divert 8668 ip from any to me 
# packets diverted and reinjected come here

ipfw add 3320 accept ip from any to any

# for now no special processing..
ipfw add 3360 drop log ip from any to any

 Outside Interface output
# things we need to do for packets leaving via bge0 to the Internet.
# Nat packets that are suitable. Don't wast time NATing other
packets.
ipfw add 3400 divert 8668 ip from not me to any recv bge1
#nat'd packets will turn up here when re-injected.
ipfw add 3410 allow ip from any to any.



now you can put in rules that are specific to exactly certain traffic
and know what the h*ck is going on.



I believe with IPFW not having one set structure to go by has indeed
confused me as a beginner. This template will definitely help out with
any furth

Re: Fragmented Packet Reassembly and IPFW2

[Julian Elischer]

Curby wrote:

Hi, this is slightly off-topic as it relates to IPFW2 in Mac OS X (as
of Tiger, 10.4.x).

I've read that when a FreeBSD machine running IPFW2 receives a
fragmented TCP packet (and let's say that the machine itself is the
intended destination), the packet is reassembled before it gets to
IPFW2, and IPFW2 sees a single TCP packet.  Basically, the (first)
question is whether this is the case in OS X.


I don't believe that happens in FreeBSD.. where did you hear that?
 *adds looking at the code to 10,000 item list of things to do*



Next, and especially if reassembly occurs before the firewall, what is
the point of the frag flag in a rule body, e.g.:

add 04010 deny log  all from any to any frag in

Question 2 in a nutshell: what's the point of "frag" if frags are
already being reassembled?  Is this meant to reject incoming frags
that aren't reassembled by the kernel (i.e. crap traffic)?  I'm
actually using the exact rule above in my laptop firewall
configuration, and the only time I've seen it triggering is at a
conference's wifi network, where other clients would be sending
multicast frags to 224.0.0.251.  (If that's crap traffic, why would it
be rampant at that conference?)  Thanks!
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Fwd: Fragmented Packet Reassembly and IPFW2

[Julian Elischer]

Curby wrote:

Julian and Vadim, thank you both for your replies.  Here's a really old quote:

"The ip_input() routine in the kernel then dequeues the packet,
performs sanity checks on the packet and determines the destination
for the packet. If the destination is the local computer, the kernel
will perform packet reassembly. "


The firewall is the first thing ip_input does. 
it happens BEFORE reassembly.




from http://usenix.net/events/bsdcon02/full_papers/lidl/lidl_html/index.html

Also, this poster is less sure but suggests that this might happen:
http://osdir.com/ml/freebsd.isp/2003-02/msg00091.html


he says "I think" and he's wrong.  check netinet/ip_input.c



I also think that Linux iptables only sees reassembled packets (at
least some of the time, e.g. when it is legitimate traffic destined
for the host itself), so this isn't altogether wild and crazy.


maybe, but you are asking about FreeBSD



If in fact reassembly does not happen, I should remove that rule as
frags will likely not match using a check-state rule because they lack
tcp/udp header information.  Is there a way in ipfw to allow frags
that claim to be related to a known-good first frag but drop others?
Something like check-state but for fragments 1 and above, in other
words.


not in ipfw. you might check pf and ipf



The odd thing is that I didn't see any dropped packets in my logs or
notice any disrupted traffic (e.g. in a web browser) before this
conference, where frags were suddenly flying all over.  Thanks again
for your help!


frags are usually the result of tunnelling.
People at a conference often have tunnels running.



--Mike
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list

[Julian Elischer]

Vadim Goncharov wrote:
In-Reply-To: <[EMAIL PROTECTED]>   
References: <[EMAIL PROTECTED]>


Hi Eugene Grosbein!

On Fri, 15 Feb 2008 23:42:16 +0700 (KRAT); Eugene Grosbein 
<[EMAIL PROTECTED]> wrote:



The command "ipfw table 1 list" used to format table values
associated with network addresses as 32-bit unsigned integers
until 6.3-RELEASE. Since 6.3-RELEASE, it interprets values
that are greater than 65535 as IP-addresses.



This change breaks many existing applications that expect the format
to be an integer, as it used to be since RELENG_4.
This change is not even documented. So, it breaks POLA and should be
corrected.



How-To-Repeat:



ipfw table 1 add 1.1.1.1 $(date +%s)
ipfw table 1 list



This used to show something like "1.1.1.1/32 1203093427" before change
but now it shows something like "1.1.1.1/32 71.181.191.179" instead.


Confirming. This breaks UNIX-time using scripts for many systems and was
introduced by ``ipfw fwd tablearg'' handling commit to 6.2-STABLE in May 
2007.


POLA should be unbroken as far as possible.



that was me..
It is my memory that
before that time tableargs were only used in 16 bit form.
there were no users in ipfw of the full 32 bit field.

I did not consider that someone would put a 32 bit number
in there just to print it out again.
(what would you do that for?)

It shows that even if you were involved in writing code
you can never predict what your users will do with it.

I'll add an argument to force the interpretation.

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list

[Julian Elischer]

The following reply was made to PR bin/120720; it has been noted by GNATS.

From: Julian Elischer <[EMAIL PROTECTED]>
To: Vadim Goncharov <[EMAIL PROTECTED]>
Cc: Eugene Grosbein <[EMAIL PROTECTED]>, freebsd-ipfw@freebsd.org, 
 [EMAIL PROTECTED]
Subject: Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list
Date: Mon, 18 Feb 2008 10:32:32 -0800

 Vadim Goncharov wrote:
 > In-Reply-To: <[EMAIL PROTECTED]>   
 > References: <[EMAIL PROTECTED]>
 > 
 > Hi Eugene Grosbein!
 > 
 > On Fri, 15 Feb 2008 23:42:16 +0700 (KRAT); Eugene Grosbein 
 > <[EMAIL PROTECTED]> wrote:
 > 
 >> The command "ipfw table 1 list" used to format table values
 >> associated with network addresses as 32-bit unsigned integers
 >> until 6.3-RELEASE. Since 6.3-RELEASE, it interprets values
 >> that are greater than 65535 as IP-addresses.
 > 
 >> This change breaks many existing applications that expect the format
 >> to be an integer, as it used to be since RELENG_4.
 >> This change is not even documented. So, it breaks POLA and should be
 >> corrected.
 > 
 >>> How-To-Repeat:
 > 
 >> ipfw table 1 add 1.1.1.1 $(date +%s)
 >> ipfw table 1 list
 > 
 >> This used to show something like "1.1.1.1/32 1203093427" before change
 >> but now it shows something like "1.1.1.1/32 71.181.191.179" instead.
 > 
 > Confirming. This breaks UNIX-time using scripts for many systems and was
 > introduced by ``ipfw fwd tablearg'' handling commit to 6.2-STABLE in May 
 > 2007.
 > 
 > POLA should be unbroken as far as possible.
 
 
 that was me..
 It is my memory that
 before that time tableargs were only used in 16 bit form.
 there were no users in ipfw of the full 32 bit field.
 
 I did not consider that someone would put a 32 bit number
 in there just to print it out again.
 (what would you do that for?)
 
 It shows that even if you were involved in writing code
 you can never predict what your users will do with it.
 
 I'll add an argument to force the interpretation.
 
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list

[Julian Elischer]

Eugene Grosbein wrote:

On Mon, Feb 18, 2008 at 11:52:41AM -0800, [EMAIL PROTECTED] wrote:


Synopsis: [patch] [ipfw] unbreak POLA for ipfw table list

State-Changed-From-To: open->closed
State-Changed-By: julian
State-Changed-When: Mon Feb 18 11:27:58 PST 2008
State-Changed-Why: 
Patch committed to -current and scheduled for MFC.



http://www.freebsd.org/cgi/query-pr.cgi?pr=120720


Shouldn't this PR be in "patched" state until MFC to both
RELENG_6 and RELENG_7?

Eugene Grosbein


possibly, but
I'll get the MFC reminder in my mail in 3 days.
I'm no longer tracking it in the bug system, so I closed it..


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW Established and Outside Traffic Problem

[Julian Elischer]

steve13th wrote:
Given: 
Running FREEBSD


What I want to do:
I am attempting to disable the following things:
Note H= host octet
1. disable pings
2. disable traffic originating from networks other than HHH.HH.HHH.0/24
3. allow traffic to originate from HHH.HH.HHH.11 and go back and forth with
the internet
Status:
I am able to block pings, but I can't have traffic with the internet

My rules

ipfw add 1 icmp from any to any icmp 0,8
ipfw add 2 allow tcp any to any established
ipfw add 3 allow all from HHH.HH.HHH.11/24 to any





oh where to start..

firstly realise that ipfw is called in every packet arraiving in every 
interface and every packet leaving on every interface.


you probably want to limit processing to packets coming and going on 
some interface. Assume em0 is your outside interface..


#divide up traffic to that we are interested in and that we are not
ipfw add 10 skipto 100 ip from any to any in recv em0
ipfw add 11 skipto 200 ip from any to any out xmit em0
ipfw allow ip from any to any

# incoming packets from the outside
ipfw add 100 drop ip from 127.0.0.0/8 to any
ipfw add 101 drip ip from any to 127.0.0.0/8
ipfw add 110 drop icmp from any to any icmp 0,8
ipfw add 120 check-state
[ add any other packets descriptions for incoming packets you may want 
to accept]

ipfw add 190 drop ip from any to any

# outgoing packets to the outside
ipfw add 200 ipfw allow ip from any to any keep-state
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [patch] ipfw_nat as a kld module

[Julian Elischer]

Vadim Goncharov wrote:
Hi Paolo Pisati! 


On Thu, 28 Feb 2008 16:11:34 +0100; Paolo Pisati wrote about '[patch] ipfw_nat 
as a kld module':


http://people.freebsd.org/~piso/ipfw_nat_module.patch
Any objection if i commit it?


Some comments:

* //comments are not in out style(9)


in case this is cryptic to you..
do
"man 9 style"


* IPFW_NAT_LOADED - again style(9), CAPSLOCK is used for constants
* lookup_nat() duplication - it is short, may be turn to #define macro in .h?
* struct ip_fw_chain moved to .h and no longer static, is this good?
  I suggest to move into it's own static chain in module, see next
* Instead of returning IP_FW_NAT function is called immediately from
  ipfw_chk(). This inconsistent with other modules of this sort, like divert
  and dummynet, where ipfw_chk() simply returns value and cookie to
  ipfw_check_*() functions in _pfil.c. If it is done like that, ip_fw2.c
  is dependent on modules in minimal way, as many of structures and code
  as possible should be moved to modules. This allows to change module
  without recompiling main ipfw - for example, your lookup_nat() and
  LIST_HEAD from ip_fw_chain could reside entirely in module - then it would
  be possible to easily switch from LIST to hash of some kind (imagine 500
  NAT instances). And so on.

Maybe I missed some points as I was looking briefly...



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION

[Julian Elischer]

Andrey V. Elsukov wrote:

Paolo Pisati wrote:

On Thu, Mar 13, 2008 at 09:21:11AM +, Vadim Goncharov wrote:

http://www.freebsd.org/cgi/query-pr.cgi?pr=80642
Yes, this is useful, but some minor changes are needed, I think. 
First, rename
it to "bytelimit" or somewhat. Second, allow this to use tablearg and 
possibly
ability to reference a counter to corresponding dynamic rule, to 
allow this to
act for a specific IP or connection without need to write many rules. 
Third,
add packet counter as well. That's all possible with one opcode, 
though...


if anyone post an updated patch, i'll commit it.


So, updated patch is here:
http://butcher.heavennet.ru/patches/kernel/ipfw/ipfw_counterlimit.diff

Now this option divided into two "counterlimit-bytes" and
"counterlimit-packets".
Rules example:
add allow ip from any to 10.0.0.1 counterlimit-bytes 100M \
in recv external_if
add allow ip from any to 10.0.0.1 counterlimit-pakets 50 \
in recv external_if

About Vadim's prepositions:
1. tablearg: it's possible, but now we use u32 argument in
tables, but counterlimits are 64-bits values. First of we
should extend our current table argument to 64 bit.


tables should be expanded to have different types of values..
32 but ints
IP addresses (currently I'm overlaying it on 32 bit ints)
IPV6 addresses.
skipto locations
byte limits..



2. dynamic rules: i think it should be implemented as extension
to current O_LIMIT opcode or something similar.

Also i have question about my current implementation. Does it
needed to have ability of "humanized" printing of limits, which
was implemented before?



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION

[Julian Elischer]

Vadim Goncharov wrote:
Hi Julian Elischer! 


On Tue, 18 Mar 2008 01:09:19 -0700; Julian Elischer wrote about 'Re: 
kern/80642: [ipfw] [patch] ipfw small patch - new RULE OPTION':


About Vadim's prepositions:
1. tablearg: it's possible, but now we use u32 argument in
tables, but counterlimits are 64-bits values. First of we
should extend our current table argument to 64 bit.

tables should be expanded to have different types of values..
32 but ints
IP addresses (currently I'm overlaying it on 32 bit ints)
IPV6 addresses.
skipto locations
byte limits..


Are you talking about tablearg-values (data), or keys too? And does that count
only IP addrs and integers of different sizes, or strings too?


In this case I'm talking about the args.

table keys DO need to be expanded to handle ipv6 stuff and other such 
things, but that is not what we were discussing.






___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate

[Julian Elischer]

here are some of my ideas for ipfw changes:

1/ redo locking so that packets do not have to get locks on the 
structure... I have several ideas on this
2/ allow separate firewalls to be used at different parts of the 
network stack (i.e allow multiple taboe sto co-exist)

3/ possibly keeping per CPU stats..

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [HEADS UP!] IPFW Ideas: possible SoC 2008 candidate

[Julian Elischer]

Vadim Goncharov wrote:
Hi Julian Elischer! 


On Mon, 24 Mar 2008 10:53:44 -0700; Julian Elischer wrote about 'Re: [HEADS 
UP!] IPFW Ideas: possible SoC 2008 candidate':


here are some of my ideas for ipfw changes:


1/ redo locking so that packets do not have to get locks on the 
structure... I have several ideas on this


Currently the main need for locking arises for rule byte/packet counters. The
easiest short-term solution


The main need for locking is that the rules can be changed while a 
processor is traversing the rule set.




2/ allow separate firewalls to be used at different parts of the 
network stack (i.e allow multiple taboe sto co-exist)


there are many places that ipfw is currently callable from.
ip_input(), ip_output(), ether_demux(), if_brige, ether_output()

it would be interesting tobe able to have differnt firewalls in these 
places (possibly per interface) so that state (e.g. keep_state)

can be kept seprately for one place then from another.

for example you may not want the result of 'keep state' on an
external interface to necessarily affect what happens to
packets from the same session when viewed traversing an internal 
interface.


Currently on my more complex ipfw rule sets I break the rule sets out
so that packets in different places traverse different rules
but it would be nice to have it explicitly supported.



Umm, could you explain it a little?..


3/ possibly keeping per CPU stats..


How that would be represented to user?


it wouldn't.. you'd add them together before presenting them.
but every time a packet changes a counter that is shared, there is a 
chance that it is being altered by another processor, so if you have

fine grained locking in ipfw, you really should use atomic adds,
which are slow, or accept possibl collisions (which might be ok)
but still cause a lot of cross cpu TLB flushing.





___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list

[Julian Elischer]

The following reply was made to PR bin/120720; it has been noted by GNATS.

From: Julian Elischer <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc:  
Subject: Re: bin/120720: [patch] [ipfw] unbreak POLA for ipfw table list
Date: Fri, 04 Apr 2008 11:12:39 -0700

 The change has been MFC'd to RELENG_6 and RELENG_7
 
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

addition to ipfw table..

[Julian Elischer]

this change allows one to type

ipfw table 2 add 1.1.1.1:255.255.255.0 0
in addition to the currently acceptable 1.1.1.1/24 0

The reason is that some programs supply the netmask in
that (mask) form and a shell script trying to add it to a table
has a hard time converting it to the currently acceptable form
(the latter).

I do know it won't handle non contiguous masks well but as the
ipfw ABI code only accepts a network mask length instead of a
mask, there's not much that can be done.
I may suggest a later fix for that but it will break the ABI.

comments?



Index: ipfw2.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.118
diff -d -u -r1.118 ipfw2.c
--- ipfw2.c 27 Feb 2008 13:52:33 -  1.118
+++ ipfw2.c 17 Apr 2008 02:46:34 -
@@ -5856,8 +5856,22 @@
ent.masklen = atoi(p);
if (ent.masklen > 32)
errx(EX_DATAERR, "bad width ``%s''", p);
-   } else
-   ent.masklen = 32;
+   } else {
+   p = strchr(*av, ':');
+   if (p) {
+   u_int32_t tempint;
+   *p++ = '\0';
+   if (!inet_aton(p, (struct in_addr *)&tempint ))
+   errx(EX_DATAERR,
+   "bad netmask ``%s''", p);
+   if (tempint)
+   ent.masklen =
+   33 - ffs((~ntohl(tempint)) + 1);
+   else
+   ent.masklen = 0;
+   } else
+   ent.masklen = 32;
+   }
if (lookup_host(*av, (struct in_addr *)&ent.addr) != 0)
errx(EX_NOHOST, "hostname ``%s'' unknown", *av);
ac--; av++;
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: addition to ipfw table..

[Julian Elischer]

Andrey V. Elsukov wrote:

Julian Elischer wrote:

I do know it won't handle non contiguous masks well but as the
ipfw ABI code only accepts a network mask length instead of a
mask, there's not much that can be done.
I may suggest a later fix for that but it will break the ABI.

comments?


What you think about my patch?



I like it.. :-)
I didn't know about contigmask()


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw and smtp port rewriting

[Julian Elischer]

Oleksandr Samoylyk wrote:

Hello freebsd-ipfw,

I'd like to make smtp port rewriting for any destination by means of ipfw.

With iptables I just used this rule in order to achieve this functionality:

iptables -t nat -A PREROUTING -i ppp+ -p tcp --dport 2525 -j DNAT 
--to-destination :25


Reading man ipfw and playing a bit with rules I composed this rule, 
which doesn't however work:


ipfw add fwd any,2525 tcp from any to any 25 via ${tun}

How to achieve the same functionality as in iptables for smtp port 
rewriting for any destination?


Thanks!



in current (and I think 7.0) you can use the 'nat' keyword
and may be able to achieve something with that.. just an idea.

fwd doesn't change the packet, jsut what you DO with the packet so
'fwd'ing to a different port is only effective if you are accepting 
the packet yourself, and not if you are sending it to the next hop.


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw route to multigateways

[Julian Elischer]

Rosli Sukri wrote:

hi

scenario:
users>[lan]freebsdipfw[wan]->{gw1,gw2}
where gw1 goes to isp1, and gw2 goes to isp2.


easily done but how do you ensure the return packets come back the 
same way?





requirements:
ftp, http, https traffic goes to gw1
telnet, ssh, mail and pop goes to gw2


in -current there are several ways to do this
including:
* multiple routing tables
  use a firewall rule to assign incoming packets to different routing
  tables for forwarding (setfib) (-current only)
* Forward rule
  ipfw add 100 fwd tablearg ip from IP1 to table 1 in xx0
  ipfw add 101 fwd tablearg ip from IP2 to table 2 in xx0
  and add routing entries into each table
  * or just use a single address if you don't need a table:
ipfw add 100 fwd ISP1 ip from IP1 to any in xx0
ipfw add 101 fwd ISP2 ip from IP2 to any in xx0

* natd..
  I'm not an expert in this but it can do some of this

* a combination of the above
  Natd can be used to NAT your outgoing packets so that the return
  packets come back the same way.. either only NAT the packets to one
  ISP or Nat them both with different NAT instances. use a fwd rule or
  setfib rule to decide which ISP to use and limit the NAT to
  processing  packets in or out of that interface.



can freebsd ipfw do this?
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: About IPFW for IPv6

[Julian Elischer]

Fabian Wenk wrote:

Hello Edwin

On 14.06.08 04:27, Edwin Sanjoto wrote:

Do you know how to set firewall for IPv6 using IPFW?


Just use ipfw the same like for IPv4, then since FreeBSD 6.x it does 
also support IPv6. If you still have an older version of FreeBSD, use 
ip6fw.




there are some features that are not yet suported.. (e.g. tables and 
fwd I believe)




bye
Fabian
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW+Dummynet Capability

[Julian Elischer]

Kazi A. Sharif wrote:

Hello Guys,
I was planning to install a heavy duty bandwidth manager for my ISP. I 
went through some documentation and installed IPFW and Dummynet in 
FreeBSD 7.0. Before I spent so much time on this I need to know the 
limitations that are already noticed:
1. If we compare IPFW+Dummynet with Allot or Emerging Technologies 
Bandwidth manager, how efficient is the IPFW+Dummynet?



probably not as efficient..

2. Is it possible to control/throttle 800/900Mbps bandwidth using 
recommended hardware?


It'll be pushing hard to do that.

3. Can I shape bandwidth for 3000 to 5000 clients with Dummynet where 
concurrent connectivity would be 2000 to 3000?


"maybe"

4. If I can serve 5000 users then what would be the performance 
decreasing ratio?


no idea
5. If I can not use Dummynet for my requirement then what are the 
recommendations?



a dedicated load controlling device.

You are going to have to do significant tuning with FreeBSD to be able
to do this, and if you do not want to become a guru in ipfw and 
network processing in the BSD kernel then it is a much better use

of your time to research some dedicated hardware.

If my boss told me I had to do this, I'd say, "I don't know if it's 
possible with FreeBSD.. I'll need to do some testing"

and if it was close I'd consider doing it because I have
confidencein my knowledge of the networking code, that I cold probably
hack the kernel enough to give me a specdial purpose kernel that could
do it, but  if it wasn't close I wouldn't bother.

My suspicion is that it won't be "close" at this time, but the only 
thing you can try is to simulate it.




Thanks in advance.
Sharif


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ipfw add skipto tablearg....

[Julian Elischer]

looking int he code I noticed that the following command gave
no error but didn't work..


ipfw add 1000 skipto tablearg ip from any to table(31)

and as I have a use for that, I implemented it..

see attached patch... (hopefully not stripped)

Of course it is hoped that the rules you are skipping to are nearby
as it iterates through the rules following the skipto to find the
target,
but
if you had a thousand table entries and wanted to sort them into
20 buckets, it could save you puting them into 20 different
tables and doing 20 table lookups on them.

here I sort into two categories.. possibly already a win..


[EMAIL PROTECTED]:cat ipfw-test.sh
#!/bin/sh
ipfw add 100 skipto 1 ip from any to not 1.1.1.0/24
ipfw add 1000 skipto tablearg ip from any to "table(31)"
ipfw add 2000 drop ip from any to any
ipfw add 2001 drop ip from any to any
ipfw add 3000 drop ip from any to any
ipfw add 3001 drop ip from any to any
ipfw add 1 count ip from any to any
ipfw table 31 add 1.1.1.1 2000
ipfw table 31 add 1.1.1.2 3000

[EMAIL PROTECTED]: ping 1.1.1.1
[...] (2 packets bounced)
[EMAIL PROTECTED]: ping 1.1.1.2
[...] (12 packets bounced)

[EMAIL PROTECTED]: ipfw show
00100  220  19633 skipto 1 ip from any to not 1.1.1.0/24
01000   14   1176 skipto tablearg ip from any to table(31)
020002168 deny ip from any to any
020010  0 deny ip from any to any
03000   12   1008 deny ip from any to any
030010  0 deny ip from any to any
1  209  18549 count ip from any to any
65535 1751 153792 allow ip from any to any


comments?



Index: ip_fw2.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v
retrieving revision 1.186
diff -u -r1.186 ip_fw2.c
--- ip_fw2.c9 May 2008 23:02:57 -   1.186
+++ ip_fw2.c1 Aug 2008 01:15:06 -
@@ -1738,10 +1738,11 @@
  */
 
 static struct ip_fw *
-lookup_next_rule(struct ip_fw *me)
+lookup_next_rule(struct ip_fw *me, u_int32_t tablearg)
 {
struct ip_fw *rule = NULL;
ipfw_insn *cmd;
+   u_int16_t   rulenum;
 
/* look for action, in case it is a skipto */
cmd = ACTION_PTR(me);
@@ -1751,10 +1752,18 @@
cmd += F_LEN(cmd);
if (cmd->opcode == O_TAG)
cmd += F_LEN(cmd);
-   if ( cmd->opcode == O_SKIPTO )
-   for (rule = me->next; rule ; rule = rule->next)
-   if (rule->rulenum >= cmd->arg1)
+   if (cmd->opcode == O_SKIPTO ) {
+   if (tablearg != 0) {
+   rulenum = (u_int16_t)tablearg;
+   } else {
+   rulenum = cmd->arg1;
+   }
+   for (rule = me->next; rule ; rule = rule->next) {
+   if (rule->rulenum >= rulenum) {
break;
+   }
+   }
+   }
if (rule == NULL)   /* failure or not a skipto */
rule = me->next;
me->next_rule = rule;
@@ -2475,7 +2484,7 @@
 
f = args->rule->next_rule;
if (f == NULL)
-   f = lookup_next_rule(args->rule);
+   f = lookup_next_rule(args->rule, 0);
} else {
/*
 * Find the starting rule. It can be either the first
@@ -3226,9 +3235,13 @@
if (cmd->opcode == O_COUNT)
goto next_rule;
/* handle skipto */
-   if (f->next_rule == NULL)
-   lookup_next_rule(f);
-   f = f->next_rule;
+   if (cmd->arg1 == IP_FW_TABLEARG) {
+   f = lookup_next_rule(f, tablearg);
+   } else {
+   if (f->next_rule == NULL)
+   lookup_next_rule(f, 0);
+   f = f->next_rule;
+   }
goto again;
 
case O_REJECT:
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPv6 tables?

[Julian Elischer]

Matt Dawson wrote:
Just a quick question: What would it take to have similar functionality to the 
IPv4 tables in ipfw for v6? Is there a specific reason it isn't there (other 
than the fact that I haven't got my finger out and learnt the neccessary to 
add it myself ;) )?


there is no reason except that is hasn't been done :-)


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPv6 tables?

[Julian Elischer]

Matt Dawson wrote:

On Wednesday 06 Aug 2008, [EMAIL PROTECTED] wrote:

On Tuesday 05 August 2008 16:42:25 Max Laier wrote:

On Tuesday 05 August 2008 16:33:04 Matt Dawson wrote:

Just a quick question: What would it take to have similar functionality
to the IPv4 tables in ipfw for v6? Is there a specific reason it isn't
there (other than the fact that I haven't got my finger out and learnt
the neccessary to add it myself ;) )?

In FreeBSD 7 and above all three firewall packages included with FreeBSD
understand both IPv4 and IPv6.  Read the ipfw(8) man page for details on
how to setup IPv6 rules.

Oh wait ... you asked something different.  Yeah, that would be nice to
have.   pf does it.  If you need a reference.


I did notice pf had tables that can handle both v4 and v6. I hadn't thought of 
reading pf's code to see how it's done, although pf's tables seem to handle 
handle both versions (without looking at the code, just the manpage).  I'm 
now wondering which approach would be less resource-hungry: Adding a 
separate "table6" structure or modifying tables to accept v6. The former, to 
my mind, is more economical with large tables.


Thanks to you and Julian for the replies. Looks like I have some code and 
things to read through.



I think I'd go for a single table structure, that only instantiates
the ipv4 or ipv6 table part of itself when you add anentry of that 
type.. then when you do a compare, it only looks in the apropriate 
half..  Since you always know which you have...

but it would be note to be able do a test against both types with one
ipfw rule.



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw add skipto tablearg....

[Julian Elischer]

Luigi Rizzo wrote:

On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote:

On Tue, 19 Aug 2008, Luigi Rizzo wrote:
 > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote:

...

 > > Until $someone adds a direct skipto target jump at the virtual machine
 > > code level - big recalc hit when adding/deleting rules/sets I suppose -
 > > it's still the fastest way to get from a to b, where b > a
 > 
 > you mean with tables-based skipto targets ? Because the regular

 > skipto has been a constant-time op forever, even in ipfw1 i believe,
 > invalidating the target cache on a change and recomputing it the
 > fly at the first request.

Thanks; I'd completely missed the caching of skipto targets before, and 
it's all so well commented too.  blushing, but glad for the good news.


But yes I was pondering Julian's patch, which has to lookup_next_rule 
every time, and also Mike's bending of divert reentry rule number in 
ipfw-classifyd with similar intent, which also has to hunt forward in 
linear time for its target rule - or am I missing something else here?


well, you can use a hash table to support that. It shouldn't be so bad
to implement, flow tables already use hash tables so one can reuse the same 
code.


one COULD, but I know I use this feature only with a number (20 or less)
following rules, each of which is a skipto itself to some further awat 
location...or a simple drop..


Shall we say we "leave it as an exercise for the reader" ?




 > > Speaking of which, should ipfw whinge when asked to skip backwards,
 > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd
 > > and a local test months ago.
 > 
 > right... but the error can only be reliably detected in the kernel,

 > as the rule number is not always known when the rule is added.

Yes I meant at run-time.  On second thoughts, it'd be too easy a way to 


actually you can do it at insertion time, it's just that you cannot
do it in userland as other checks before inserting the rule.

cheers
luigi


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw add skipto tablearg....

[Julian Elischer]

Luigi Rizzo wrote:

On Wed, Aug 20, 2008 at 04:06:05AM +1000, Ian Smith wrote:

On Tue, 19 Aug 2008, Luigi Rizzo wrote:
 > On Tue, Aug 19, 2008 at 11:12:04PM +1000, Ian Smith wrote:

...

 > > Until $someone adds a direct skipto target jump at the virtual machine
 > > code level - big recalc hit when adding/deleting rules/sets I suppose -
 > > it's still the fastest way to get from a to b, where b > a
 > 
 > you mean with tables-based skipto targets ? Because the regular

 > skipto has been a constant-time op forever, even in ipfw1 i believe,
 > invalidating the target cache on a change and recomputing it the
 > fly at the first request.

Thanks; I'd completely missed the caching of skipto targets before, and 
it's all so well commented too.  blushing, but glad for the good news.


But yes I was pondering Julian's patch, which has to lookup_next_rule 
every time, and also Mike's bending of divert reentry rule number in 
ipfw-classifyd with similar intent, which also has to hunt forward in 
linear time for its target rule - or am I missing something else here?


well, you can use a hash table to support that. It shouldn't be so bad
to implement, flow tables already use hash tables so one can reuse the same 
code.


 > > Speaking of which, should ipfw whinge when asked to skip backwards,
 > > which it can't, confirmed on a recent browse re Mike's ipfw-classifyd
 > > and a local test months ago.
 > 
 > right... but the error can only be reliably detected in the kernel,

 > as the rule number is not always known when the rule is added.

Yes I meant at run-time.  On second thoughts, it'd be too easy a way to 


actually you can do it at insertion time, it's just that you cannot
do it in userland as other checks before inserting the rule.


you can't do it at insertion time if it's a tablearg style skipto..
but such a rule will simply continue at the next rule as if it
did not match.



cheers
luigi


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

anyone have a netgraph node to do ipfw filtering?

[Julian Elischer]

I think someone sent me a link to an ng_ipfw_filter node once
but I've lost it...

(I think it was called ng_ipfw but that name is now taken by the
netgraph/ipfw 'ipfw netgraph' packet divert option).

Something that lets you do ipfw filtering on packets as they
travel across a graph.

As I said,I've seen one but lost it...

Julian


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: anyone have a netgraph node to do ipfw filtering?

[Julian Elischer]

Bjoern A. Zeeb wrote:

On Thu, 11 Sep 2008, Julian Elischer wrote:

Hi,


I think someone sent me a link to an ng_ipfw_filter node once
but I've lost it...

(I think it was called ng_ipfw but that name is now taken by the
netgraph/ipfw 'ipfw netgraph' packet divert option).

Something that lets you do ipfw filtering on packets as they
travel across a graph.

As I said,I've seen one but lost it...


I could be wrong but did you mean?
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_ipfw.c




no that's the one I refer to in themail wiich is the inverse of what I 
want



that one allows ipfw to send things to netgraph. I want one
to allow a netgraph graph to filter things with ipfw...


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: anyone have a netgraph node to do ipfw filtering?

[Julian Elischer]

Eugene Grosbein wrote:

On Thu, Sep 11, 2008 at 11:12:29PM -0700, Julian Elischer wrote:


that one allows ipfw to send things to netgraph. I want one
to allow a netgraph graph to filter things with ipfw...


ng_bpf? not exactly ipfw filtering, but filtering :-)



No it needs to be ifpw for the job I'm doing..there is already a lot 
of code that manipulate ipfw rules that I want to reuse.

(heavy use of tables etc.).




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW fwd issue.

[Julian Elischer]

Dan Johnson wrote:

After beating my head against this for days I ran out of places to look for
information, and almost sent this as a help request instead of an
observation. So excuse the present tense.


All I am actually trying to accomplish is a simple (This worked flawless
last i tried under 4.5) squid transparent proxy.


so, what revision are you trying to do this on?
I think in 6.1 it was disabled without an extra option. (see in LINT)



I'm using this rule before the nat rule:

00100 fwd 127.0.0.1,3128 log ip from any to any 80 out

When I attempt to hit port 80 on an external server, the security log shows
the rule was processed, and claims it was forwarded to 127.0.0.1,3128. OK

Watching tcpdump -nnvvei lo0 shows no relevant activity. BUT, watching
tcpdump -nnvvei xl1 (external iface) shows the port 80 SYN being sent to the
remote web server with the original source ip address from 192.168.0.0/24,
still using the destination MAC of my default gateway. This is with or
without the squid daemon running. And when i do have it running i have it on
the local console with debugging enabled (incase a stray packet actually
makes it in.)


that sounds a bit like the problem I mention above...
however, sending it to 127.0.0.1 doesn't mean it goes through lo0 so 
you'll never see it there.




The same holds true if i setup the fwd to my xl1 interface ip address, or
another host ex 192.168.0.30.

Running tcpdump (Linux) eth0 in promisc on 192.168.0.30 also doesn't show
any traffic being forwarded its way when configured to do so. So I'm
inclined to beleive this isn't just an error on tcpdumps part (as there is
an open issue reported with tcpdump and ipfw fwd) but that the traffic
really isn't being modified.

The only thing I was doing that is unique is I recompiled the ipfw module to
include -DIPFIREWALL_NAT and -DIPFIREWALL_FORWARD instead of adding the
whole mess to the base kernel.


ah that will fail because the IPFIREWALL_FORWARD option has to change 
things in teh tcp and Ip code too.




After noting that I was using a module, I said screw it, and compiled IPFW
into the base kernel, viola now it works fine. 


yeah the whole ip stack need to be compiled with those options..


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IPFW fwd issue.

[Julian Elischer]

Dan Johnson wrote:

On Fri, Oct 3, 2008 at 12:01 AM, Julian Elischer <[EMAIL PROTECTED]>wrote:


Dan Johnson wrote:


After beating my head against this for days I ran out of places to look
for
information, and almost sent this as a help request instead of an
observation. So excuse the present tense.


All I am actually trying to accomplish is a simple (This worked flawless
last i tried under 4.5) squid transparent proxy.


so, what revision are you trying to do this on?
I think in 6.1 it was disabled without an extra option. (see in LINT)



7.0-Release.  In my research I'd found that in 6 and I believe some point in
5.x  the option IPFIREWALL_FORWARD_EXTENDED was needed for this
configuration, but apparently it was switched back for 7.


yeah that was me switching it back.. the whole feature is kinds 
useless without being able to do that..

man ssh






 I'm using this rule before the nat rule:

00100 fwd 127.0.0.1,3128 log ip from any to any 80 out

When I attempt to hit port 80 on an external server, the security log
shows
the rule was processed, and claims it was forwarded to 127.0.0.1,3128. OK

Watching tcpdump -nnvvei lo0 shows no relevant activity. BUT, watching
tcpdump -nnvvei xl1 (external iface) shows the port 80 SYN being sent to
the
remote web server with the original source ip address from 192.168.0.0/24
,
still using the destination MAC of my default gateway. This is with or
without the squid daemon running. And when i do have it running i have it
on
the local console with debugging enabled (incase a stray packet actually
makes it in.)


that sounds a bit like the problem I mention above...
however, sending it to 127.0.0.1 doesn't mean it goes through lo0 so
you'll never see it there.






The same holds true if i setup the fwd to my xl1 interface ip address, or
another host ex 192.168.0.30.

Running tcpdump (Linux) eth0 in promisc on 192.168.0.30 also doesn't show
any traffic being forwarded its way when configured to do so. So I'm
inclined to beleive this isn't just an error on tcpdumps part (as there is
an open issue reported with tcpdump and ipfw fwd) but that the traffic
really isn't being modified.

The only thing I was doing that is unique is I recompiled the ipfw module
to
include -DIPFIREWALL_NAT and -DIPFIREWALL_FORWARD instead of adding the
whole mess to the base kernel.


ah that will fail because the IPFIREWALL_FORWARD option has to change
things in teh tcp and Ip code too.



Thats what I figured might have been the case, odd that there were no errors
logged in the firewall logs though.





After noting that I was using a module, I said screw it, and compiled IPFW
into the base kernel, viola now it works fine.


yeah the whole ip stack need to be compiled with those options..



Hopefully next person with this issue wont bang their head on the wall as
long once this thread is indexed. :)




 ___

freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"




___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw rules optimitsing

[Julian Elischer]

Anatoliy wrote:

Greetings to all.

I have a problem to optimise ipfw rules.
When I have started to search for the decision there were some questions
How it is possible to find out how many
loading gives this or that rule or all corrected as a whole.
Prompt as it better to make in practice?
As it would be desirable to learn as dynamic pipes the quantity 
influences productivity,

how many calculations in a second occur thus etc.
if what or sysctl displaying expressly or by implication it is variables 
the information?


thnx, an sorry for bad English.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


This sounds like something that would be a useful project..
(to profile ipfw)

you could try kernel bb profiling if it still works or you could try 
other ways to work it out..


So far we do not have this information so if you do it we would be
very interested.

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Portforwarding - still the same issue

[Julian Elischer]

Leander S. wrote:

Roman Kurakin schrieb:

John Hay wrote:

On Mon, Oct 20, 2008 at 11:19:22PM +0200, Leander S. wrote:
 

Hi,

I'm trying to set up something like a HotSpot. Goal is it to force 
unregistred users to get redirected to the Captive Portalsite where 
they'll be able to agree my licence therms and get some information 
... etc. ...


So fact is I need an IPFW rule which forwards Port 80,443,8080 
Traffic to another Port i.e. 8080 --> where my Apache will already 
wait for serving the Captive Portalsite back to the request.


So I did read the man and saw something like the fwd rule and the 
Kernel Option for it - so I added the option - rcompiled the Kernel 
and gave my Firewall the following fwd rule in an extra script:


  ${fwcmd} add 01100 fwd ${LAN_IP},8080 tcp from ${LAN} to any 
80,443,8080 in via ${LAN_if}

Try to make the rule stateful, eq add 'setup keep-state'. Also add 
some logging in the rule

and add the last one additional deny with the logging.
Oh-oh ...  Can't log right now - have to recompile the kernel before ... 
sry.

You have to catch it where it is going out and not in. Fwd only works
when packets are out bound.


I think you can forward an incoming packet out again..
I am sure I have done that.

I don't think so ?! And what sence would it make? Because think twice 
... I want to fwd incoming HTTP:80 packages to make them look like 
HTTP:8080 packages ... the outgoing ones are uninteresting because it's 
apache's job to send back Websitedata on port 8080 where it's listening 
anyway.
  

But how this works for me?

ipfw  fwd 192.168.0.4,3128 log logamount 1000 tcp from 172.22.4.0/24 
to 172.22.4.254 dst-port 3128 setup in via vr0 keep-state


rik

John
 

I tried:

[...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me dst-port 80 setup 
in via ath0 keep-state


as well as this one too:

[...] fwd 127.0.0.1,8080 tcp from 192.1.1.0/24 to me src-port 80 
dst-port 8080 setup in via ath0 keep-state


^^
But sadly without success - "root$  ipfw show" doesn't even show me at 
least one package going through  not even blocked ones ... 0 0;-)





what version of FreeBSD..
forwarding was crippled in an early 6.x revision I think.
you needed to ad another option as well.




But here is my szenario again:

127.0.0.1 is my FreeBSDMashine wehre IPFW acts and Apache22 Listens on 
port 8080.


192.1.1.0/24 is the ath0 Interface where Wirlessclients will try to 
klick http://google:80 BUT accidently should be fwded & run into my 
PortalSite:8080
192.1.1.1 is the Interfaces IP Adress. 192.1.1.1:8080 would you also 
bring as well as 127.0.0.1:8080 to the portalsite.



Regards,

Leander
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Any plans or desire for "bulk addition" to tables?

[Julian Elischer]

David Wolfskill wrote:

On my systems that are directly connected to network not known to be
relatively "safe," I use ipfw a fair bit.

Of late, I've taken to augmenting the usual rules that are sensitive to
specific ports and the like with (early) rules that check certain ipfw
tables; they are used in the following way:

* Traffic where an endpoint is found in table 1 is blocked.  Period.

* Traffic where the source address is in table 2 is not permitted to
  initiate a 22/tcp connection.

* Traffic where the source address is in table 3 is not permitted to
  initiate a 80/tcp or a 443/tcp connection.

Reasons for the above are somewhat off-topic for the list; I'll merely
comment that they have to do with perceived failure to respond to
observed attempts at abuse: I will protect my networks.

In any case, I've cobbled up a moderately complex mechanism for
maintaining the tables in question, and table 1 (in particular) has
grown to be rather large:

d254(8.0-C)[1] sudo ipfw table 1 list | wc -l
Password:
   11230
d254(8.0-C)[2] ^1^2
sudo ipfw table 2 list | wc -l
1743
d254(8.0-C)[3] ^2^3
sudo ipfw table 3 list | wc -l
  50
d254(8.0-C)[4] 


Unfortunately, the only way I've found to populate a given table is to
issue

ipfw table ${table} add ${netblock}


you can read in a file of entries

i.e.

ipfw -q filename

where each line is of the form
table N add IP VAL

this increases the speed many times as you are not starting
ipfw(1) for each entry.



for each "netblock" in the table (assuming that I don't care about the
optional "value" parameter -- which I haven't found a use for).


oh I have lots of use for that...



Issuing something on the order of 13K "ipfw table ... add" commands
during the single- to multu-user transition tends to slow down the
effective boot time a bit -- especially when I'm booting up CURRENT on
my laptop (with WITNESS & INVARIANTS specified).


I add many thousands using hte method described above and it trakse a 
second or so


you can alternatively do:

myscript|ipfw -q /dev/stdin

where
'myscript' generates the values.




Would some way to teach ipfw(8) how to perform some sort of "bulk add"
of a bunch of table entries in a single command invocation be of
interest to anyone else?

Please include my address on responses, as I'm not subscribed to [EMAIL 
PROTECTED]
(I've tweaked Reply-To to provide an MUA hint.)

Peace,
david


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: change specific linux iptables rule set to ipfw rule set

[Julian Elischer]

Son, Yeongsik wrote:

One of linux server contains rule set like these:

iptables -A INPUT -p tcp --syn --dport 80 - m connlimit --conlimit-above 20
-j DROP
iptables -A INPUT -m recent --name KIN -rcheck --seconds 300 -j DROP
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 5
-m recent --name KIN -set -j DROP

simply means,
drop ip try to connect tcp port 80 over 20 connections.
when it happens, drop ip for 5 minutes.

iptables -A INPUT -p udp --dport 53 -m length --length 512:65535 -j DROP

briefly,
drop ip try to connect udp port 53 which packet length is 512 ~ 65535.

I want using those rules on freebsd servers, but I don't know those kind of
sophisticated functions of ipfw.

Is that possible freebsd?



not in ipfw but I think pf can do that.

Some people may have done that with ipfw using an external agent,
but I don't know who/how.



Let me share your knowledge.
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

rc.firewall quick change

[Julian Elischer]

At home I use the following change.


basically, instead of doing 8 rules before and after the nat,
use a table and to 1 rule on each side.


any objections?

(warning, cut-n-paste patch.. will not apply)

Index: rc.firewall
===
--- rc.firewall (revision 184948)
+++ rc.firewall (working copy)
@@ -231,19 +231,24 @@
${fwcmd} add deny all from ${onet} to any in via ${iif}

# Stop RFC1918 nets on the outside interface
-   ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif}
-   ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif}
-   ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif}
+   ${fwcmd} table 1 add 10.0.0.0/8
+   ${fwcmd} table 1 add 172.16.0.0/12
+   ${fwcmd} table 1 add 192.168.0.0/16

# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes 
RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and 
class E)

# on the outside interface
-   ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif}
-   ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif}
-   ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif}
-   ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif}
-   ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif}
+   ${fwcmd} table 1 add 0.0.0.0/8
+   ${fwcmd} table 1 add 169.254.0.0/16
+   ${fwcmd} table 1 add 192.0.2.0/24
+   ${fwcmd} table 1 add 224.0.0.0/4
+   ${fwcmd} table 1 add 240.0.0.0/4

+# Stop the above nets with the table
+
+   ${fwcmd} add deny all from any to "table(1)" via ${oif}
+
+
# Network Address Translation.  This rule is placed here 
deliberately
# so that it does not interfere with the surrounding 
address-checking
# rules.  If for example one of your internal LAN machines 
had its IP

@@ -260,19 +265,8 @@
esac

# Stop RFC1918 nets on the outside interface
-   ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif}
-   ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif}
-   ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif}
+   ${fwcmd} add deny all from "table(1)" to any via ${oif}

-   # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes 
RESERVED-1,
-   # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and 
class E)

-   # on the outside interface
-   ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif}
-   ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif}
-   ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif}
-   ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif}
-   ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif}
-
# Allow TCP through if setup succeeded
${fwcmd} add pass tcp from any to any established

___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rc.firewall quick change

[Julian Elischer]

Ian Smith wrote:

On Thu, 13 Nov 2008, Julian Elischer wrote:
 > At home I use the following change.
 > 
 > 
 > basically, instead of doing 8 rules before and after the nat,

 > use a table and to 1 rule on each side.
 > 
 > 
 > any objections?


Only that if people are already using tables for anything, chances are 
they've already used table 1 (well, it's the first one I used :)  How 
about using table 127 for this as a rather less likely prior choice?


yes I thought of that..
in fact it should be ${BLOCKTABLE} and let the user define what he 
wants. (defaulting to 99 or something).
Remember though that a user wouldn't be using 'simple' if he's using 
his own tables etc.






Apart from that, this will speed up 'simple' on a path every packet 
takes, which has to be a good thing.


While I'm at it, I'll offer my own rc.firewall patch again in the 
following message.  Perhaps you'd care to review it in this context?


cheers, Ian

 > (warning, cut-n-paste patch.. will not apply)
 > 
 > Index: rc.firewall

 > ===
 > --- rc.firewall (revision 184948)
 > +++ rc.firewall (working copy)
 > @@ -231,19 +231,24 @@
 > ${fwcmd} add deny all from ${onet} to any in via ${iif}
 > 
 > # Stop RFC1918 nets on the outside interface

 > -   ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif}
 > -   ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif}
 > -   ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif}
 > +   ${fwcmd} table 1 add 10.0.0.0/8
 > +   ${fwcmd} table 1 add 172.16.0.0/12
 > +   ${fwcmd} table 1 add 192.168.0.0/16
 > 
 > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes

 > RESERVED-1,
 > # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class
 > E)
 > # on the outside interface
 > -   ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif}
 > -   ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif}
 > -   ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif}
 > -   ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif}
 > -   ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif}
 > +   ${fwcmd} table 1 add 0.0.0.0/8
 > +   ${fwcmd} table 1 add 169.254.0.0/16
 > +   ${fwcmd} table 1 add 192.0.2.0/24
 > +   ${fwcmd} table 1 add 224.0.0.0/4
 > +   ${fwcmd} table 1 add 240.0.0.0/4
 > 
 > +# Stop the above nets with the table

 > +
 > +   ${fwcmd} add deny all from any to "table(1)" via ${oif}
 > +
 > +
 > # Network Address Translation.  This rule is placed here deliberately
 > # so that it does not interfere with the surrounding address-checking
 > # rules.  If for example one of your internal LAN machines had its IP
 > @@ -260,19 +265,8 @@
 > esac
 > 
 > # Stop RFC1918 nets on the outside interface

 > -   ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif}
 > -   ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif}
 > -   ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif}
 > +   ${fwcmd} add deny all from "table(1)" to any via ${oif}
 > 
 > -   # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes

 > RESERVED-1,
 > -   # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class
 > E)
 > -   # on the outside interface
 > -   ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif}
 > -   ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif}
 > -   ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif}
 > -   ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif}
 > -   ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif}
 > -
 > # Allow TCP through if setup succeeded
 > ${fwcmd} add pass tcp from any to any established
 > 
 > ___

 > freebsd-ipfw@freebsd.org mailing list
 > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
 > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
 > 
___

freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rc.firewall quick change

[Julian Elischer]

Julian Elischer wrote:

Ian Smith wrote:

On Thu, 13 Nov 2008, Julian Elischer wrote:
 > At home I use the following change.
 >  >  > basically, instead of doing 8 rules before and after the nat,
 > use a table and to 1 rule on each side.
 >  >  > any objections?

Only that if people are already using tables for anything, chances are 
they've already used table 1 (well, it's the first one I used :)  How 
about using table 127 for this as a rather less likely prior choice?


yes I thought of that..
in fact it should be ${BLOCKTABLE} and let the user define what he 
wants. (defaulting to 99 or something).
Remember though that a user wouldn't be using 'simple' if he's using his 
own tables etc.




so here's a slightly improved diff:

Index: rc.firewall
===
--- rc.firewall (revision 184948)
+++ rc.firewall (working copy)
@@ -216,11 +216,13 @@
#  firewall_simple_inet:Inside network address.
#  firewall_simple_oif: Outside network interface.
#  firewall_simple_onet:Outside network address.
+   #  firewall_block_table:Table to use blocking stuff.

 
# set these to your outside interface network
oif="$firewall_simple_oif"
onet="$firewall_simple_onet"
+   tbl=${firewall_block_table:-99}
 
# set these to your inside interface network
iif="$firewall_simple_iif"
@@ -231,19 +233,24 @@
${fwcmd} add deny all from ${onet} to any in via ${iif}
 
# Stop RFC1918 nets on the outside interface
-   ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif}
-   ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif}
-   ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif}
+   ${fwcmd} table ${tbl} add 10.0.0.0/8
+   ${fwcmd} table ${tbl} add 172.16.0.0/12
+   ${fwcmd} table ${tbl} add 192.168.0.0/16
 
# Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1,
# DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E)
# on the outside interface
-   ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif}
-   ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif}
-   ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif}
-   ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif}
-   ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif}
+   ${fwcmd} table ${tbl} add 0.0.0.0/8
+   ${fwcmd} table ${tbl} add 169.254.0.0/16
+   ${fwcmd} table ${tbl} add 192.0.2.0/24
+   ${fwcmd} table ${tbl} add 224.0.0.0/4
+   ${fwcmd} table ${tbl} add 240.0.0.0/4
 
+# Stop the above nets with the table
+
+   ${fwcmd} add deny all from any to "table(${tbl})" via ${oif}
+
+
# Network Address Translation.  This rule is placed here deliberately
# so that it does not interfere with the surrounding address-checking
# rules.  If for example one of your internal LAN machines had its IP
@@ -260,19 +267,8 @@
esac
 
# Stop RFC1918 nets on the outside interface
-   ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif}
-   ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif}
-   ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif}
+   ${fwcmd} add deny all from "table(${tbl})" to any via ${oif}
 
-   # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1,
-   # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E)
-   # on the outside interface
-   ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif}
-   ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif}
-   ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif}
-   ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif}
-   ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif}
-
# Allow TCP through if setup succeeded
${fwcmd} add pass tcp from any to any established
 
___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rc.firewall quick change

[Julian Elischer]

Bruce Evans wrote:

On Fri, 14 Nov 2008, Julian Elischer wrote:


Ian Smith wrote:

On Thu, 13 Nov 2008, Julian Elischer wrote:
 > At home I use the following change.
 >  >  > basically, instead of doing 8 rules before and after the nat,
 > use a table and to 1 rule on each side.
 >  >  > any objections?

Only that if people are already using tables for anything, chances 
are they've already used table 1 (well, it's the first one I used :)  
How about using table 127 for this as a rather less likely prior choice?


yes I thought of that..


Separate rules provide more statistics.


true but generally people don't need to distinguish between those,
and if you do then you probably want to log them.



in fact it should be ${BLOCKTABLE} and let the user define what he 
wants. (defaulting to 99 or something).


I use shell variables giving lists of interfaces to be blocked so that
there aren't very many rules:

%%%
rfc1918n=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
dmanningn=0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4

${fwcmd} add deny log all from any to ${rfc1918n} via ${oif}
${fwcmd} add deny log all from any to ${dmanningn} via ${oif}

... (divert rule)

${fwcmd} add deny log all from ${rfc1918n} to any via ${oif}
${fwcmd} add deny log all from ${dmanningn} to any via ${oif}
%%%

I use separate lists mainly for documentation purposes but they also
provide separate statistics.

Remember though that a user wouldn't be using 'simple' if he's using 
his own tables etc.


Separate rules are also simplest for documentation purposes.

Apart from that, this will speed up 'simple' on a path every packet 
takes, which has to be a good thing.


Are tables faster than lists of addresses?  I would expect lists to be
slightly more efficient.


I think the table is faster for mor ethan about 8 addresses (so we
are borderline) but it's be hard to test..  You however use two rules
so that would be slower.

In my sites I tend to have other stuff put in those tables too




Bruce


___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: rc.firewall quick change

[Julian Elischer]

Doug Barton wrote:

Julian Elischer wrote:

I think the table is faster for mor ethan about 8 addresses (so we
are borderline) but it's be hard to test..  You however use two rules
so that would be slower.


I'm not a firewall expert so I won't comment on the specifics but I do
want to say that as a general rule "it works + fast/efficient" is MUCH
more important for default settings than "it works really well" or "it
works + more features." For better or worse we live in a world where
most users don't read the manuals, and that includes the ones running
"benchmarks" with default settings.


I think the change is better from the point of view that it is easier 
to read (for me) and behaves better.




OTOH I do think it would be entirely appropriate to include a "better"
example commented out next to the "fast" default. I take a similar
approach with the default named.conf and have had good feedback from
users who appreciate pointers to more information when they actually
do get curious.


hth,

Doug



___
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ipfw amd bridge

[Julian Elischer]

Olivier Nicole wrote:

Hi,

I remember reqading in the past (4.x) that on a machine with bridged
interfaces, only layer 2 rules of ipfw would apply.


not quite.
there are rules that do not work when called from a layer two
point. e.g. divert does not work, nor does 'fwd' (without patches).
Rules not specifically labeled "layer2" will still process packets,
but rules labeled "not layer2" will not do so. (as expected).

note if_bridge and bridge are different and may have
behavioral differences in this regard.





Is this still the case with 6.4, 7.1?

best regards,

Olivier
___
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"

Re: ipfw amd bridge

[Julian Elischer]

Olivier Nicole wrote:

Thanks,


I remember reqading in the past (4.x) that on a machine with bridged
interfaces, only layer 2 rules of ipfw would apply.

not quite.
there are rules that do not work when called from a layer two
point. e.g. divert does not work, nor does 'fwd' (without patches).


And what would be the patches (if any exists)?


note if_bridge and bridge are different and may have
behavioral differences in this regard.


I think it will be if_bridge (as bridge is obsolete).

Bests,

Olivier

 


I gave some to adrian (cc'd)..
I don't have them available right now..



___
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"

Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets?

[Julian Elischer]

Luigi Rizzo wrote:

On Tue, Mar 17, 2009 at 11:02:48PM +0100, Paolo Pisati wrote:

Luigi Rizzo wrote:

Thinking more about it, i believe that calling reass as an explicit
firewall action is useless, because if ip_reass fails due to lack of
all fragments you are back to square one:
what do I do with this fragment ?
 
AFAIK ip_reass() never fails: if it's the last fragment it reassembles 
the packet and return it, else it queues the fragment for later

reassembly.


Ok then we may have a plan:

you could do is implement REASS as an action (not as a microinstruction),
with the following behaviour:

- if the packet is a complete one, the rule behaves as a "count"
  (i.e. the firewall continues with the next rule);

- if the packet is a fragment and can be reassembled, the rule
  behaves as a "count" and the mbuf is replaced with the full packet;

- if the packet is a fragment and cannot be reassembled, the
  rule behaves as a "drop" (i.e. processing stops)
  and the packet is swallowed by ipfw.

This seems a useful behaviour, but it must be documented very
clearly because it is not completely intuitive. Perhaps we should
find a more descriptive name.


So what is the behaviour when you reassemble a 5K packet,
and then it has to be forwarded out another interface with 1500 MTU.



Good progress!

cheers
luigi
___
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"

Re: keep-state rules inadequately handles big UDP packets or fragmented IP packets?

[Julian Elischer]

Luigi Rizzo wrote:

On Tue, Mar 17, 2009 at 03:39:45PM -0700, Julian Elischer wrote:
...

Ok then we may have a plan:

you could do is implement REASS as an action (not as a microinstruction),
with the following behaviour:

- if the packet is a complete one, the rule behaves as a "count"
 (i.e. the firewall continues with the next rule);

- if the packet is a fragment and can be reassembled, the rule
 behaves as a "count" and the mbuf is replaced with the full packet;

- if the packet is a fragment and cannot be reassembled, the
 rule behaves as a "drop" (i.e. processing stops)
 and the packet is swallowed by ipfw.

This seems a useful behaviour, but it must be documented very
clearly because it is not completely intuitive. Perhaps we should
find a more descriptive name.

So what is the behaviour when you reassemble a 5K packet,
and then it has to be forwarded out another interface with 1500 MTU.


Good point. One option would be that when REASS is called from the
output path, it always act as "count" and never calls ip_reass()

Would that work ? The firewall in the output path is called before
fragment, locally generated packets are not fragmented, and if
don't want stray fragment you should have already called "reass"
in the inbound path through the firewall ?


yeah but what if you reassemble on input, and then the packet is routed?



cheers
luigi


___
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"

Re: pls help on 3 interfaces

[Julian Elischer]

Lin Zhao wrote:

hi all, wish my english is enough :-)
my freebsd has 3 interfaces, like this,

    switch1
 | --  fxp0|
 ||  |-
internal ||freebsd71 |
 |rl0 |  |-
 | --  fxp1|
    switch2


first set your routingtable so that teh 'special' addresses
go via switch2, then set up NAT as follows:

like this:

    switch1
 | --  fxp0|
 ||   NAT1(*)|-
internal ||freebsd71 |
 |rl0 |  NAT2|-
 | --  fxp1|
    switch2

(*) If you want, NAT1 may be left out if you use routable
addresses on your internal network.

The reason for the NAT is to make sure that outgoing packets
have a source address that will make the return packets come back 
through switch2, otherwise, even if you have a route

making the outgoing packets go via switch2, the return packets
will still comeback via switch1.




we're in the internal and want to visit outside
we use fxp0 for default outside address and it works well
but for some reason, i want to use fxp1 for some special outside address
how can i do for it?
thanks a lot.


Lin Zhao
SCGY,USTC,PRC


___
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"

Re: pls help on 3 interfaces

[Julian Elischer]

Lin Zhao wrote:

too much thx for Julian Elischer & John Nielsen.
i've tried it, and it seems working now, 
but i don't know if i'm right in setting natd2
i just add one line in /etc/services as "natd2 8669" 
and run a command: natd -n fxp1 -p 8669
seems so stupid.  


I assume you mean "simple" instead of stupid... :-)
I don't think you need natd2 in /etc/services...
but as long as the ipfw and natd agree in the port number
it should work.


You didn't say if you have nat already.
but if you do then I believe natd can do more than one nat
with a single instance now.

(phk added that some time ago)
but I have never done it, so I can not tell you how... read the man 
page...


also the in-kernel nat available in ipfw can do this and you can also 
do multiple NATS with that too but once again, I haven't done it

myself.



Lin

ÔÚÄúµÄÀ´ÐÅÖÐÔø¾­Ìáµ½:

From: John Nielsen 
Reply-To: 
To: freebsd-ipfw@freebsd.org, Lin Zhao 

Subject: Re: pls help on 3 interfaces
Date:Wed, 18 Mar 2009 23:23:56 -0400

On Wednesday 18 March 2009 10:36:15 pm Lin Zhao wrote:

hi all, wish my english is enough :-)
my freebsd has 3 interfaces, like this,

    switch1

 | --  fxp0|
 |
 ||  |-

internal ||freebsd71 |

 |rl0 |  |-
 | --  fxp1|

    switch2

we're in the internal and want to visit outside
we use fxp0 for default outside address and it works well
but for some reason, i want to use fxp1 for some special outside
address how can i do for it?
thanks a lot.
Is the FreeBSD box performing network address translation (NAT)? I'm going 
to assume that it is and everything is being aliased through fxp0. I'm 
also assuming you're using ipfw since you wrote to the ipfw list.


If the IP addresses which you'd like to reach via fxp1 are static, you 
should be able to do something like the following:


Configure static routes on the FreeBSD machine for the the special outside 
addresses using the gateway of fxp1's network as the router.
Configure an additional NAT rule (if still using natd now might be a good 
time to switch to in-kernel ipfw NAT..) to alias through fxp1.
Configure ipfw to direct traffic to/from the special outside addresses to 
the new NAT instance instead of the default.


I actually used a similar setup recently. If you care to confirm my 
assumptions above I can give you a more step-by-step guide.


JN

___
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"

Re: FreeBSD 7.1 IPv6 multihoming problem

[Julian Elischer]

zgabe wrote:
Hi All, 


I am using laptop, FreeBSD 7.1 connecting to two ISPs (wlan and ppp) and I
have IPv6 addresses. 'netstat -rn' says there is only one default gateway
(for example wlan's default gateway). My problem is the following: 
If I ping the ppp tunnel from an other computer, my laptop recieves the

ICMP6 echo request over the ppp tunnel, but it answers over the wlan
interface. I read some similar posts (only ipv4) about forwarding with IPFW,
but I was unable to solve my problem until now.

I built a kernel with the following options: 
options IPFIREWALL 
options IPFIREWALL_VERBOSE 
options IPFIREWALL_DEFAULT_TO_ACCEPT 
options IPFIREWALL_FORWARD 

and put these lines to my rc.conf 
firewall_enable="YES" 
firewall_type="open" 

as the handbook says. 

I use the following command as root: 
ipfw add 101 fwd pppgateway ipv6 from pppaddress to any 


(pppgateway and pppaddress ipv6 addresses)

It throws "getsockopt(IP_FW_ADD): Invalid argument" error! 


I have tried to set the following variables but the problem is still the
same. 
sysctl -w net.inet.ip.forwarding=1 and 
sysctl -w net.inet6.ip6.forwarding=1 

Can anybody help me? 




the theory with multihoming is that unless you are the holder of a 
class-C (/24) you basically have to do it using NAT.

You have to make some subset of  your traffic use one NAT while the
remainder uses another (or is untranslated).
Unfortunately we don't have NAT for IPV6. I don't know how that
gets solved..

___
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"

Re: IPFW MAX RULES COUNT PERFORMANCE

[Julian Elischer]

Daniel Dias Gonçalves wrote:

Hi,

My system is a FreeBSD 7.1R.
When I add rules IPFW COUNT to 254 IPS from my network, one of my 
interfaces increases the latency, causing large delays in the network, 
when I delete COUNT rules, everything returns to normal, which can be ?


My script:


of course adding 512 rules, *all of which hav eto be evaluated* will 
add latency.


you have several ways to improve this situation.

1/ use a differnet tool.
By using the netgraph netflow module you can get
accunting information that may be more useful and less impactful.

2/ you could make your rules smarter..

use skipto rules to make the average packet traverse less rules..

off the top of my head.. (not tested..)

Assuming you have machines 10.0.0.1-10.0.0.254
the rules below have an average packet traversing 19 rules and not 256 
for teh SYN packet and 2 rules for others..
you may not be able to do the keep state  trick if you use state for 
other stuff but in that case worst case will still be 19 rules.


2 check-state
5 skipto 1 ip from not 10.0.0.0/24 to any
10 skipto 2020 ip from not 10.0.0.0/25 to any  # 0-128
20 skipto 1030 ip from not 10.0.0.0/26 to any  # 0-64
30 skipto 240 ip from not 10.0.0.0/27  to any  # 0-32
40 skipto 100 ip from not 10.0.0.0/28  to any  # 0-16
[16 count rules for 0-15]
80 skipto 1 ip from any to any
100 [16 count rules for 16-31] keep-state
140 skipto 1 ip from any to any
240 skipto 300 ip from not 10.0.0.32/28
[16 rules for 32-47] keep-state
280 skipto 1 ip from any to any
300 [16 count rules for 48-63] keep-state
340 skipto 1 ip from any to any
1030 skipto 1240 ip from not 10.0.0.64/27 to any
1040 skipto 1100 ip from not 10.0.0.64/28 to any
   [16 count rules for 64-79] keep-state
1080 skipto 1 ip from any to any
1100 [16 rules for 80-95] keep-state
1140 skipto 1 ip from any to any
1240 skipto 1300 ip from not 10.0.0.96/28 to any
[16 count rules for 96-111] keep-state
1280 skipto 1 ip from any to any
1300 [16 rules for 112-127] keep-state
1340 skipto 1 ip from any to any
2020 skipto 3030 ip from not 10.0.0.128/26 to any
2030 skipto 2240 ip from not 10.0.0.128/28 to any
[16 count rules for 128-143] keep-state
2080 skipto 1 ip from any to any
2100 [16 rules for 144-159] keep-state
2140 skipto 1 ip from any to any
2240 skipto 2300 ip from not 10.0.0.32/28 to any
[16 count rules for 160-175] keep-state
2280 skipto 1 ip from any to any
2300 [16 count rules for 176-191] keep-state
2340 skipto 1 ip from any to any
3030 skipto 3240 ip from not 10.0.0.192/27 to any
3040 skipto 3100 ip from not 10.0.0.192/28 to any
[16 count rules for 192-207] keep-state
3080 skipto 1 ip from any to any
3100 [16 rules for 208-223] keep-state
3240 skipto 1 ip from any to any
3240 skipto 3300 ip from not 10.0.0.224/28 to any
[16 count rules for 224-239] keep-state
3280 skipto 1 ip from any to any
3300 [16 count rules for 240-255] keep-state
3340 skipto 1 ip from any to any

1 #other stuff

in fact you could improve it further with:
1/ either going down to a netmask of 29 (8 rules per set)
or
2/ instead of having count rules make them skipto
so you would have:
3300 skipto 1 ip from 10.0.0.240 to any
3301 skipto 1 ip from 10.0.0.241 to any
3302 skipto 1 ip from 10.0.0.242 to any
3303 skipto 1 ip from 10.0.0.243 to any
3304 skipto 1 ip from 10.0.0.244 to any
3305 skipto 1 ip from 10.0.0.245 to any
3306 skipto 1 ip from 10.0.0.246 to any
3307 skipto 1 ip from 10.0.0.247 to any
3308 skipto 1 ip from 10.0.0.248 to any
3309 skipto 1 ip from 10.0.0.249 to any
3310 skipto 1 ip from 10.0.0.240 to any
3311 skipto 1 ip from 10.0.0.241 to any
3312 skipto 1 ip from 10.0.0.242 to any
3313 skipto 1 ip from 10.0.0.243 to any
3314 skipto 1 ip from 10.0.0.244 to any
3315 skipto 1 ip from 10.0.0.245 to any

thus on average, a packet would traverse half the rules (8).

3/ both the above  so on average they would traverse  4 rules plus one 
extra skipto.


you should be  able to do the above in a script.
I'd love to see it..

(you can also do skipto tablearg in -current (maybe 7.2 too)
which may also be good.. (or not))


julian



___
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"

Re: IPFW MAX RULES COUNT PERFORMANCE

[Julian Elischer]

Daniel Dias Gonçalves wrote:

Very good thinking, congratulations, but my need is another.
The objective is a Captive Porrtal that each authentication is 
dynamically created a rule to ALLOW or COUNT IP authenticated, which I'm 
testing is what is the maximum capacity of rules supported, therefore 
simultaneous user.


Understand ?


I think so.


do not add rules.
have a single rule that looks in a table
and add entries to the table when needed.


Thanks,

Daniel

Julian Elischer escreveu:

Daniel Dias Gonçalves wrote:

Hi,

My system is a FreeBSD 7.1R.
When I add rules IPFW COUNT to 254 IPS from my network, one of my 
interfaces increases the latency, causing large delays in the 
network, when I delete COUNT rules, everything returns to normal, 
which can be ?


My script:


of course adding 512 rules, *all of which hav eto be evaluated* will 
add latency.


you have several ways to improve this situation.

1/ use a differnet tool.
By using the netgraph netflow module you can get
accunting information that may be more useful and less impactful.

2/ you could make your rules smarter..

use skipto rules to make the average packet traverse less rules..

off the top of my head.. (not tested..)

Assuming you have machines 10.0.0.1-10.0.0.254
the rules below have an average packet traversing 19 rules and not 256 
for teh SYN packet and 2 rules for others..
you may not be able to do the keep state  trick if you use state for 
other stuff but in that case worst case will still be 19 rules.


2 check-state
5 skipto 1 ip from not 10.0.0.0/24 to any
10 skipto 2020 ip from not 10.0.0.0/25 to any  # 0-128
20 skipto 1030 ip from not 10.0.0.0/26 to any  # 0-64
30 skipto 240 ip from not 10.0.0.0/27  to any  # 0-32
40 skipto 100 ip from not 10.0.0.0/28  to any  # 0-16
[16 count rules for 0-15]
80 skipto 1 ip from any to any
100 [16 count rules for 16-31] keep-state
140 skipto 1 ip from any to any
240 skipto 300 ip from not 10.0.0.32/28
[16 rules for 32-47] keep-state
280 skipto 1 ip from any to any
300 [16 count rules for 48-63] keep-state
340 skipto 1 ip from any to any
1030 skipto 1240 ip from not 10.0.0.64/27 to any
1040 skipto 1100 ip from not 10.0.0.64/28 to any
   [16 count rules for 64-79] keep-state
1080 skipto 1 ip from any to any
1100 [16 rules for 80-95] keep-state
1140 skipto 1 ip from any to any
1240 skipto 1300 ip from not 10.0.0.96/28 to any
[16 count rules for 96-111] keep-state
1280 skipto 1 ip from any to any
1300 [16 rules for 112-127] keep-state
1340 skipto 1 ip from any to any
2020 skipto 3030 ip from not 10.0.0.128/26 to any
2030 skipto 2240 ip from not 10.0.0.128/28 to any
[16 count rules for 128-143] keep-state
2080 skipto 1 ip from any to any
2100 [16 rules for 144-159] keep-state
2140 skipto 1 ip from any to any
2240 skipto 2300 ip from not 10.0.0.32/28 to any
[16 count rules for 160-175] keep-state
2280 skipto 1 ip from any to any
2300 [16 count rules for 176-191] keep-state
2340 skipto 1 ip from any to any
3030 skipto 3240 ip from not 10.0.0.192/27 to any
3040 skipto 3100 ip from not 10.0.0.192/28 to any
[16 count rules for 192-207] keep-state
3080 skipto 1 ip from any to any
3100 [16 rules for 208-223] keep-state
3240 skipto 1 ip from any to any
3240 skipto 3300 ip from not 10.0.0.224/28 to any
[16 count rules for 224-239] keep-state
3280 skipto 1 ip from any to any
3300 [16 count rules for 240-255] keep-state
3340 skipto 1 ip from any to any

1 #other stuff

in fact you could improve it further with:
1/ either going down to a netmask of 29 (8 rules per set)
or
2/ instead of having count rules make them skipto
so you would have:
3300 skipto 1 ip from 10.0.0.240 to any
3301 skipto 1 ip from 10.0.0.241 to any
3302 skipto 1 ip from 10.0.0.242 to any
3303 skipto 1 ip from 10.0.0.243 to any
3304 skipto 1 ip from 10.0.0.244 to any
3305 skipto 1 ip from 10.0.0.245 to any
3306 skipto 1 ip from 10.0.0.246 to any
3307 skipto 1 ip from 10.0.0.247 to any
3308 skipto 1 ip from 10.0.0.248 to any
3309 skipto 1 ip from 10.0.0.249 to any
3310 skipto 1 ip from 10.0.0.240 to any
3311 skipto 1 ip from 10.0.0.241 to any
3312 skipto 1 ip from 10.0.0.242 to any
3313 skipto 1 ip from 10.0.0.243 to any
3314 skipto 1 ip from 10.0.0.244 to any
3315 skipto 1 ip from 10.0.0.245 to any

thus on average, a packet would traverse half the rules (8).

3/ both the above  so on average they would traverse  4 rules plus one 
extra skipto.


you should be  able to do the above in a script.
I'd love to see it..

(you can also do skipto tablearg in -current (maybe 7.2 too)
which may also be good.. (or not))


julian



___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr

Re: IPFW MAX RULES COUNT PERFORMANCE

[Julian Elischer]

Daniel Dias Gonçalves wrote:

Julian,

You could give an example of rules with tables?


I'm sorry I forgot that you want to count packets from each client.
tables won't work for that.


for counting I suggest the technique I show below,
but for just allowing, you can add allowable addresses to
a table,
e.g. table 1 add 1.2.3.4

and test it with

allow ip from table (1) to any




Julian Elischer escreveu:

Daniel Dias Gonçalves wrote:

Very good thinking, congratulations, but my need is another.
The objective is a Captive Porrtal that each authentication is 
dynamically created a rule to ALLOW or COUNT IP authenticated, which 
I'm testing is what is the maximum capacity of rules supported, 
therefore simultaneous user.


Understand ?


I think so.


do not add rules.
have a single rule that looks in a table
and add entries to the table when needed.


Thanks,

Daniel

Julian Elischer escreveu:

Daniel Dias Gonçalves wrote:

Hi,

My system is a FreeBSD 7.1R.
When I add rules IPFW COUNT to 254 IPS from my network, one of my 
interfaces increases the latency, causing large delays in the 
network, when I delete COUNT rules, everything returns to normal, 
which can be ?


My script:


of course adding 512 rules, *all of which hav eto be evaluated* will 
add latency.


you have several ways to improve this situation.

1/ use a differnet tool.
By using the netgraph netflow module you can get
accunting information that may be more useful and less impactful.

2/ you could make your rules smarter..

use skipto rules to make the average packet traverse less rules..

off the top of my head.. (not tested..)

Assuming you have machines 10.0.0.1-10.0.0.254
the rules below have an average packet traversing 19 rules and not 
256 for teh SYN packet and 2 rules for others..
you may not be able to do the keep state  trick if you use state for 
other stuff but in that case worst case will still be 19 rules.


2 check-state
5 skipto 1 ip from not 10.0.0.0/24 to any
10 skipto 2020 ip from not 10.0.0.0/25 to any  # 0-128
20 skipto 1030 ip from not 10.0.0.0/26 to any  # 0-64
30 skipto 240 ip from not 10.0.0.0/27  to any  # 0-32
40 skipto 100 ip from not 10.0.0.0/28  to any  # 0-16
[16 count rules for 0-15]
80 skipto 1 ip from any to any
100 [16 count rules for 16-31] keep-state
140 skipto 1 ip from any to any
240 skipto 300 ip from not 10.0.0.32/28
[16 rules for 32-47] keep-state
280 skipto 1 ip from any to any
300 [16 count rules for 48-63] keep-state
340 skipto 1 ip from any to any
1030 skipto 1240 ip from not 10.0.0.64/27 to any
1040 skipto 1100 ip from not 10.0.0.64/28 to any
   [16 count rules for 64-79] keep-state
1080 skipto 1 ip from any to any
1100 [16 rules for 80-95] keep-state
1140 skipto 1 ip from any to any
1240 skipto 1300 ip from not 10.0.0.96/28 to any
[16 count rules for 96-111] keep-state
1280 skipto 1 ip from any to any
1300 [16 rules for 112-127] keep-state
1340 skipto 1 ip from any to any
2020 skipto 3030 ip from not 10.0.0.128/26 to any
2030 skipto 2240 ip from not 10.0.0.128/28 to any
[16 count rules for 128-143] keep-state
2080 skipto 1 ip from any to any
2100 [16 rules for 144-159] keep-state
2140 skipto 1 ip from any to any
2240 skipto 2300 ip from not 10.0.0.32/28 to any
[16 count rules for 160-175] keep-state
2280 skipto 1 ip from any to any
2300 [16 count rules for 176-191] keep-state
2340 skipto 1 ip from any to any
3030 skipto 3240 ip from not 10.0.0.192/27 to any
3040 skipto 3100 ip from not 10.0.0.192/28 to any
[16 count rules for 192-207] keep-state
3080 skipto 1 ip from any to any
3100 [16 rules for 208-223] keep-state
3240 skipto 1 ip from any to any
3240 skipto 3300 ip from not 10.0.0.224/28 to any
[16 count rules for 224-239] keep-state
3280 skipto 1 ip from any to any
3300 [16 count rules for 240-255] keep-state
3340 skipto 1 ip from any to any

1 #other stuff

in fact you could improve it further with:
1/ either going down to a netmask of 29 (8 rules per set)
or
2/ instead of having count rules make them skipto
so you would have:
3300 skipto 1 ip from 10.0.0.240 to any
3301 skipto 1 ip from 10.0.0.241 to any
3302 skipto 1 ip from 10.0.0.242 to any
3303 skipto 1 ip from 10.0.0.243 to any
3304 skipto 1 ip from 10.0.0.244 to any
3305 skipto 1 ip from 10.0.0.245 to any
3306 skipto 1 ip from 10.0.0.246 to any
3307 skipto 1 ip from 10.0.0.247 to any
3308 skipto 1 ip from 10.0.0.248 to any
3309 skipto 1 ip from 10.0.0.249 to any
3310 skipto 1 ip from 10.0.0.240 to any
3311 skipto 1 ip from 10.0.0.241 to any
3312 skipto 1 ip from 10.0.0.242 to any
3313 skipto 1 ip from 10.0.0.243 to any
3314 skipto 1 ip from 10.0.0.244 to any
3315 skipto 1 ip from 10.0.0.245 to any

thus on average, a packet would traverse half the rules (8).

3/ both the above  so on average they would traverse  4 rules plus 
one extra skipto.


you sho

Re: Does ipfw support interface groups?

[Julian Elischer]

Ermal Luçi wrote:

Hello,

can ipfw use somehow interface groups as pf(4) can?

From a quick glance at documentation and not so through look at code

it does not but i am sending this just if i missed something during my
search!

Thanks,



no, but you can do "em*"

___
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"

Re: Does ipfw support interface groups?

[Julian Elischer]

Freddie Cash wrote:


Skipto is very powerful, and we use it in some cases.  But I try not
to use it very often, as it can lead to spaghetti rules that are hard
to follow.  :)  We have one firewall where it takes a good 10 minutes
to track the path a packet takes through the rulelist, as there are so
many skipto rules and multiple interfaces/vlans (it's scheduled for a
rewrite this summer).


don't forget you can now do a skipto tablearg  :-)



___
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"

Re: Rules processing in ipfw: processing ends with rule 65535 or first match?

[Julian Elischer]

Freddie Cash wrote:

Over the years, various how-tos and docs that I've read comparing ipfw
to ipf and pf have categorised them as such:

  - ipf/pf compares the packet against every rule in the ruleset, and
the last matching action is used once the end of the ruleset is
reached (last-match-wins)

  - ipfw compares the packet against the rules, and stops processing
the rulesset once a rule matches (first-match-wins)

And, if one wants to get the ipfw behaviour in ipf/pf, they can use
the "quick" keyword, which stops processing of the ruleset as soon as
one of those rules matches.

IOW, for a ruleset with 1000 rules, ipf/pf will scan every single rule
for every single packet; and ipfw will only scan the ruleset up to the
first matching rule.  In theory, the ipfw method would be a lot
faster, and less intensive.

However, reading through the man page for ipfw(8) on FreeBSD 7.2, it
lists the following (Description section):
The packet passed to the firewall is compared against each
of the rules in the firewall ruleset.  When a match is found, the action
corresponding to the matching rule is performed.



the packet is compared against each rule it encounters
however it might not encounter a rule by 3 means:

1/ it matches a rule before the rule in question and stops processing
2/ it bypasses the rule in question due to matching a rule with a
   skipto action.
3/ it matches a check-state rule and effectively shortcuts to the
   exact rule that is needed for that session, skipping all
   intermediate rles.




And, later, in the Packet Flow section:
Also note that each packet is always checked against the complete rule-
set, irrespective of the place where the check occurs, or the source of
the packet.

These make it sound like ifpw processes the entire ruleset for every
packet, regardless of when a match occurs.

So, which is it?  Is ipfw a first-match-wins and rule processing ends
setup?  Or does it check every single rule for every single packet?



___
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"