ipfw on just inbound and not outbound
Apologies if this is something silly but I want to completely eliminate ipfw from outgoing traffic perspective. I just want to have it on incoming. I can always add "allow ip from any to any out" as the first rule but that is still ipfw doing something. Is there a way to tell ipfw to not look at outbound traffic at all? OR, the rule I mentioned is the best that can be done here? cheers, Hiren ps: Please keep me cc'd as I am not subscribed. pgpJ8vmqMPW5x.pgp Description: PGP signature
Re: ipfw on just inbound and not outbound
On Apr 14, 2015, at 2:09 PM, hiren panchasara wrote: > Apologies if this is something silly but I want to completely eliminate > ipfw from outgoing traffic perspective. I just want to have it on > incoming. I can always add "allow ip from any to any out" as the first > rule but that is still ipfw doing something. > > Is there a way to tell ipfw to not look at outbound traffic at all? > > OR, the rule I mentioned is the best that can be done here? Blocking outbound traffic can be more important to security than blocking inbound traffic-- for one reason, see BCP 38 / RFC-2827. The rule you've suggested is the best that can be done, aside from disabling IPFW entirely. Regards, -- -Chuck ___ 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 on just inbound and not outbound
On 4/15/15 5:09 AM, hiren panchasara wrote: Apologies if this is something silly but I want to completely eliminate ipfw from outgoing traffic perspective. I just want to have it on incoming. I can always add "allow ip from any to any out" as the first rule but that is still ipfw doing something. Is there a way to tell ipfw to not look at outbound traffic at all? no OR, the rule I mentioned is the best that can be done here? yes this touches on something I've been thinking of for a while.. per interface/direction rule sets. but that doesn't exist yet. you could write a kernel module that would disconnect the outgoing packet filter hooks but "hack" comes to mind as a description there. actually you could use the ipfw netgraph hook and only hook it up for incoming packets, but it would probably be not much more efficient than just having the rule, and more complicated to set up. cheers, Hiren ps: Please keep me cc'd as I am not subscribed. ___ 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 on just inbound and not outbound
On Thu, 16 Apr 2015 11:41:54 +0800, Julian Elischer wrote: > On 4/15/15 5:09 AM, hiren panchasara wrote: > > Apologies if this is something silly but I want to completely eliminate > > ipfw from outgoing traffic perspective. I just want to have it on > > incoming. I can always add "allow ip from any to any out" as the first > > rule but that is still ipfw doing something. > > > > Is there a way to tell ipfw to not look at outbound traffic at all? > no > > > > OR, the rule I mentioned is the best that can be done here? > yes > > this touches on something I've been thinking of for a while.. per > interface/direction rule sets. > but that doesn't exist yet. > > you could write a kernel module that would disconnect the outgoing packet > filter hooks > but "hack" comes to mind as a description there. > > actually you could use the ipfw netgraph hook and only hook it up for > incoming packets, > but it would probably be not much more efficient than just having the rule, > and more complicated to set up. I'm wondering if the cost of that one rule is even worth worrying about. Hiren, you might try running iperf (ono): a) after 'ipfw disable firewall' b) after just 'ipfw add 2 allow ip from any to any' c) after say 1000 rules before getting to (b) by such as: for i in `jot - 0 999`; do ipfw add $((i*10+1000)) count ip from any to any done to then calculate a cost per rule. Tens or hundreds of ns? Of course, whether that cost is significant depends on the sort of pps rates you're having (or hoping :) to deal with on the box in question .. > > cheers, > > Hiren > > > > ps: Please keep me cc'd as I am not subscribed. cheers, Ian ___ 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 on just inbound and not outbound
Ian, It's not so much the induced latency, but the CPU usage. Simply invoking ipfw causes a noticeable amount of overhead, and with a single rule it clocks in at 5% on the hardware in question. This ranks ipfw_chk in as the 2nd hungriest function, just below tcp_output in the IRQ handler threads with a single rule. With 3 rules, it overtakes the top spot (each adding ~ .3% -.5%). If there were an easy way to gain back that 5% on outbound traffic, we'd gladly take it. It sounds like being able to disconnect paths from ipfw might be a science project for the future, though it does seem it could garner some wider interest. Jason On Thu, Apr 16, 2015 at 12:12 AM, Ian Smith wrote: > On Thu, 16 Apr 2015 11:41:54 +0800, Julian Elischer wrote: > > On 4/15/15 5:09 AM, hiren panchasara wrote: > > > Apologies if this is something silly but I want to completely eliminate > > > ipfw from outgoing traffic perspective. I just want to have it on > > > incoming. I can always add "allow ip from any to any out" as the first > > > rule but that is still ipfw doing something. > > > > > > Is there a way to tell ipfw to not look at outbound traffic at all? > > no > > > > > > OR, the rule I mentioned is the best that can be done here? > > yes > > > > this touches on something I've been thinking of for a while.. per > > interface/direction rule sets. > > but that doesn't exist yet. > > > > you could write a kernel module that would disconnect the outgoing packet > > filter hooks > > but "hack" comes to mind as a description there. > > > > actually you could use the ipfw netgraph hook and only hook it up for > > incoming packets, > > but it would probably be not much more efficient than just having the rule, > > and more complicated to set up. > > I'm wondering if the cost of that one rule is even worth worrying about. > > Hiren, you might try running iperf (ono): > > a) after 'ipfw disable firewall' > > b) after just 'ipfw add 2 allow ip from any to any' > > c) after say 1000 rules before getting to (b) by such as: > > for i in `jot - 0 999`; do > ipfw add $((i*10+1000)) count ip from any to any > done > > to then calculate a cost per rule. Tens or hundreds of ns? > > Of course, whether that cost is significant depends on the sort of pps > rates you're having (or hoping :) to deal with on the box in question .. > > > > cheers, > > > Hiren > > > > > > ps: Please keep me cc'd as I am not subscribed. > > cheers, Ian ___ 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 on just inbound and not outbound
Getting back to this now to see if I can avoid ipfw on outgoing packets. @@ -500,7 +507,7 @@ ipfw_hook(int onoff, int pf) hook_func = (pf == AF_LINK) ? ipfw_check_frame : ipfw_check_packet; (void) (onoff ? pfil_add_hook : pfil_remove_hook) - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); + (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh); return 0; } Should this do the right thing? I'll report back once I test this patch. cheers, Hiren pgp_LDVxUm8hJ.pgp Description: PGP signature
Re: ipfw on just inbound and not outbound
On 05/21/15 at 12:42P, hiren panchasara wrote: > Getting back to this now to see if I can avoid ipfw on outgoing packets. > > @@ -500,7 +507,7 @@ ipfw_hook(int onoff, int pf) > hook_func = (pf == AF_LINK) ? ipfw_check_frame : ipfw_check_packet; > > (void) (onoff ? pfil_add_hook : pfil_remove_hook) > - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); > + (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh); > > return 0; > } > > Should this do the right thing? I'll report back once I test this patch. I am still seeing ipfw_chk() getting called in my iperf test. Now, if I also remove PFIL_IN, i.e if I do: - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); + (hook_func, NULL, PFIL_WAITOK, pfh); I don't see ipfw_chk() getting triggered. Somehow incoming traffic is affecting the outgoing traffic? I'd appreciate any inputs/thoughts. I'll keep poking at this. Cheers, Hiren pgpGcsn2tpQgt.pgp Description: PGP signature
Re: ipfw on just inbound and not outbound
On 05/21/15 at 02:05P, hiren panchasara wrote: > On 05/21/15 at 12:42P, hiren panchasara wrote: > > Getting back to this now to see if I can avoid ipfw on outgoing packets. > > > > @@ -500,7 +507,7 @@ ipfw_hook(int onoff, int pf) > > hook_func = (pf == AF_LINK) ? ipfw_check_frame : ipfw_check_packet; > > > > (void) (onoff ? pfil_add_hook : pfil_remove_hook) > > - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); > > + (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh); > > > > return 0; > > } > > > > Should this do the right thing? I'll report back once I test this patch. > > I am still seeing ipfw_chk() getting called in my iperf test. Now, if I > also remove PFIL_IN, i.e if I do: > - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); > + (hook_func, NULL, PFIL_WAITOK, pfh); > > I don't see ipfw_chk() getting triggered. > > Somehow incoming traffic is affecting the outgoing traffic? It seems I screwed up something in testing and the following does seem to do the right thing: - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); + (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh); I confirmed this with pmcstat callgraphs that ipfw_chk() is not getting called in OUT direction. Any thoughts on this? Is this something that can be upstreamed with a sysctl knob if there is interest? cheers, Hiren pgpT9snE38H30.pgp Description: PGP signature
Re: ipfw on just inbound and not outbound
23.05.2015, 03:58, "hiren panchasara" : > On 05/21/15 at 02:05P, hiren panchasara wrote: >> On 05/21/15 at 12:42P, hiren panchasara wrote: >>> Getting back to this now to see if I can avoid ipfw on outgoing packets. >>> >>> @@ -500,7 +507,7 @@ ipfw_hook(int onoff, int pf) >>> hook_func = (pf == AF_LINK) ? ipfw_check_frame : ipfw_check_packet; >>> >>> (void) (onoff ? pfil_add_hook : pfil_remove_hook) >>> - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); >>> + (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh); >>> >>> return 0; >>> } >>> >>> Should this do the right thing? I'll report back once I test this patch. >> I am still seeing ipfw_chk() getting called in my iperf test. Now, if I >> also remove PFIL_IN, i.e if I do: >> - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); >> + (hook_func, NULL, PFIL_WAITOK, pfh); >> >> I don't see ipfw_chk() getting triggered. >> >> Somehow incoming traffic is affecting the outgoing traffic? > > It seems I screwed up something in testing and the following does seem to do > the > right thing: > > - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); > + (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh); > > I confirmed this with pmcstat callgraphs that ipfw_chk() is not getting > called in OUT direction. > > Any thoughts on this? Is this something that can be upstreamed with a > sysctl knob if there is interest? Unfortunately, I've missed most of the thread. First of all, just calling ipfw hook should not be so costy - I can believe in 5% in 8/9/10, but the reason should be not ipfw, but rwlock which is used ti protect ruleset. HEAD version should behave better (we observe something like 1% overhead on 10+mpps rate) since it uses rmlock. Being able to attach/detach appropriate L3 hooks is really a good idea, however the better (but not easier way) would be to implement something like `pfilctl' utility which would be able to control/disable/reorder hooks on particular filtering points (pf before ipfw or vice versa). This stuff would also help to convert some of the current L2 processing code to pfil (like BPF,lagg,netgraph input hooks in eher_input) > > cheers, > Hiren ___ 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 on just inbound and not outbound
On Sun, 24 May 2015 11:24:45 +0300, Alexander V. Chernikov wrote: > 23.05.2015, 03:58, "hiren panchasara" : > > On 05/21/15 at 02:05P, hiren panchasara wrote: > >> On 05/21/15 at 12:42P, hiren panchasara wrote: > >>> Getting back to this now to see if I can avoid ipfw on outgoing packets. > >>> > >>> @@ -500,7 +507,7 @@ ipfw_hook(int onoff, int pf) > >>> hook_func = (pf == AF_LINK) ? ipfw_check_frame : > >>> ipfw_check_packet; > >>> > >>> (void) (onoff ? pfil_add_hook : pfil_remove_hook) > >>> - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); > >>> + (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh); > >>> > >>> return 0; > >>> } > >>> > >>> Should this do the right thing? I'll report back once I test this patch. > >> I am still seeing ipfw_chk() getting called in my iperf test. Now, if I > >> also remove PFIL_IN, i.e if I do: > >> - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); > >> + (hook_func, NULL, PFIL_WAITOK, pfh); > >> > >> I don't see ipfw_chk() getting triggered. > >> > >> Somehow incoming traffic is affecting the outgoing traffic? > > > > It seems I screwed up something in testing and the following does seem to > > do the > > right thing: > > > > - (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh); > > + (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh); > > > > I confirmed this with pmcstat callgraphs that ipfw_chk() is not getting > > called in OUT direction. > > > > Any thoughts on this? Is this something that can be upstreamed with a > > sysctl knob if there is interest? > Unfortunately, I've missed most of the thread. > First of all, just calling ipfw hook should not be so costy - I can > believe in 5% in 8/9/10, but the reason should be not ipfw, but > rwlock which is used ti protect ruleset. > HEAD version should behave better (we observe something like 1% > overhead on 10+mpps rate) since it uses rmlock. That's certainly a big improvement. > Being able to attach/detach appropriate L3 hooks is really a good > idea, however the better (but not easier way) would be to implement > something like `pfilctl' utility which would be able to > control/disable/reorder hooks on particular filtering points (pf > before ipfw or vice versa). This stuff would also help to convert > some of the current L2 processing code to pfil (like > BPF,lagg,netgraph input hooks in eher_input) Well ipfw already may be seeing L2 traffic via net.link.ether.ipfw; is that already separate from the L3 pfil hooks? I haven't followed pfil. The more generic way to link and order hooks sounds like a better idea than needing to mess with ipfw (or pf, or anything) to accomplish that. cheers, Ian (FWIW) ___ 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"
