Re: packet order, ipf or ipfw

From: Dinesh Nair (dinesh_at_alphaque.com)
Date: 07/30/04

  • Next message: Charlie Schluting: "Re: packet order, ipf or ipfw" 
    Date: Fri, 30 Jul 2004 19:14:12 +0800 (MYT)
To: Jeremie Le Hen <jeremie.le-hen@epita.fr>

    On Thu, 29 Jul 2004, Jeremie Le Hen wrote:

    > Hello Charlie,
    >
    > > I'm running ipf because I like it ...but now I need to use ipfw's pipe
    > > feature. I was thinking that I could just run both, and keep all my
    > > rules in ipf, then in ipfw: limit bandwidth for a few vlans, then allow all.
    > >
    > > It didn't work (no rate-limiting happened).. and I'm thinking that ipf
    > > is passing the packets and bypassing ipfw? Or something..
    > >
    > > So, what is the order, if I'm running ipf AND ipfw at the same time?
    > > Will it work at all in this manner?
    >
    > But you should be warned that using ipnat(8) in conjunction to ipfw
    > pipes may lead to an incorrect behaviour :
    > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/61685

    in addition, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46564
    reverses the order in which ipfw/ipfilter/ipnat processes packets in
    ip_output.c to make it consistent if both are used.

    by default the flow is:

    wire -> ipnat -> ipfilter -> ipfw -> kernel -> ipfilter -> ipnat ->ipfw

    the patch in the above PR changes it to:

    wire -> ipnat -> ipfilter -> ipfw -> kernel -> ipfw -> ipfilter -> ipnat

    personally, i prefer the patch to ip_output as it makes it cleaner when
    you're separating between using ipfw/dummynet for shaping and
    ipfilter/ipnat for firewalling.

    Regards, /\_/\ "All dogs go to heaven."
    dinesh@alphaque.com (0 0) http://www.alphaque.com/
    +==========================----oOO--(_)--OOo----==========================+
    | for a in past present future; do |
    | for b in clients employers associates relatives neighbours pets; do |
    | echo "The opinions here in no way reflect the opinions of my $a $b." |
    | done; done |
    +=========================================================================+

    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Charlie Schluting: "Re: packet order, ipf or ipfw"

    Relevant Pages

    • Re: Traffic quota features in IPFW
      ... but I don't see the point in this feature nor do I think ... All it does is adding overhead to every packet that is ... I have seen much ipfw code lately ... If you apply this patch in a month or so, ...
      (freebsd-net)
    • Traffic quota features in IPFW
      ... I review Andrey's Elsukov patch for adding "bound" support in ipfw, and i decide to push a little forward this feature. ... You can see the whole picture in there: ...
      (freebsd-net)
    • =?iso-8859-15?Q?Re:_[RFC]_BadRAM_still_not_ready_for_inclusion_=3F_(wa?= =?iso-8859-
      ... maybe this patch is just something very special, having many pro's but also con's - so this also could be one reason why it exists for so long outside mainline. ... BadRAM let's you tell the kernel to skip certain regions of ram, ... forever, once it becomes a supported feature, for the benefit of the few ... people who can't or won't replace bad memory. ...
      (Linux-Kernel)
    • [KVM PATCH v10 0/2] ioeventfd (formerly iosignalfd)
      ... unit test has been updated to accomodate new feature-set) ... *) unified data-match name to be consistent throughout ... *) Removed iodev-limit patch since we no longer create ... The limit feature itself may be useful ...
      (Linux-Kernel)
    • Re: IPFW and IPv6 TCP timeout problem
      ... TCP connections after a short timeout. ... Luigi Rizzo about it but he cannot help with the IPv6 part of the ipfw. ... The PR includes a patch, it just needs somebody to commit it. ...
      (freebsd-net)