From owner-freebsd-ipfw@FreeBSD.ORG Sun Aug 27 01:30:24 2006 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FCA216A4DA for ; Sun, 27 Aug 2006 01:30:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E213F43D46 for ; Sun, 27 Aug 2006 01:30:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7R1UNn3087699 for ; Sun, 27 Aug 2006 01:30:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7R1UNVv087698; Sun, 27 Aug 2006 01:30:23 GMT (envelope-from gnats) Date: Sun, 27 Aug 2006 01:30:23 GMT Message-Id: <200608270130.k7R1UNVv087698@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Aaron Gifford" Cc: Subject: Re: kern/46159: [ipfw] [patch] ipfw dynamic rules lifetime feature X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Aaron Gifford List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Aug 2006 01:30:24 -0000 The following reply was made to PR kern/46159; it has been noted by GNATS. From: "Aaron Gifford" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/46159: [ipfw] [patch] ipfw dynamic rules lifetime feature Date: Sat, 26 Aug 2006 19:24:28 -0600 ------=_Part_157133_22428623.1156641868079 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Various PRs that have dealt with this issue: kern/46159 (still open) kern/28713 (closed, but should not have been in my opinion) kern/22065 (closed in favor of kern/28713) Hi, Here is the latest up-to-date version of the ipfw dynamic rule lifetime feature patch for 6.1-STABLE (STABLE as of 16 Aug. 2006) taken from my personal web site at http://www.adg.us/computers/ipfwpatch.html (currently down/unreachable due to gvinum issues, but should be back shortly) where patches for versions are available for FreeBSD from the 4.x and 5.x eras as well: I would very much like to see this feature become part of the mainstream distribution. Even with ipfw's built-in keepalive mechanisms, per-rule lifetime controls remain a powerful tool in my opinion, and as Oleg Koreshkov indicated in his PR submission, very likely in his opinion too. It grants firewall administrators much greater control over the flow network traffic. The per-rule lifetime features have been in use on many production machines that I manage for well over six years now. There have been zero stability issues. The patches to add these features are simple and straightforward. There have been no negative problems brought up at any time in the past when I have posted about the patches to public mailing lists, and no negative problems mentioned in any of the PR reports submitted. The only arguments against inclusion were that the features were not useful. I believe that was just the personal opinion of one of the maintainers at the time (and I respect his opinion and his FreeBSD contributions, but in this particular case respectfully disagree), but it doesn't account for the usefulness that I and others have found even after ipfw added built-in keepalive abilities. On various hosts I have used the lifetime features, when ipfw keepalives were added, I rewrote my rulesets to remove the use of per-rule lifetimes in hopes that I could stop maintaining the patchsets. Unfortunately, I discovered there were places in my own rulesets where keepalives could not fully replace the per-rule lifetime features, and so I've had to keep maintaining the patches to add these features to ipfw as I have done for over six years now. So please carefully consider adding per-rule lifetimes to ipfw rules. They're useful. I think a wider audience of ipfw network admins. will find them useful. Thank you. Aaron Gifford --- /usr/src/sys/netinet/ip_fw.h.orig Sat Jul 29 02:24:12 2006 +++ /usr/src/sys/netinet/ip_fw.h Wed Aug 16 14:52:55 2006 @@ -101,7 +101,7 @@ O_VERSRCREACH, /* none */ O_PROBE_STATE, /* none */ - O_KEEP_STATE, /* none */ + O_KEEP_STATE, /* u32 = optional lifetime */ O_LIMIT, /* ipfw_insn_limit */ O_LIMIT_PARENT, /* dyn_type, not an opcode. */ @@ -432,6 +432,7 @@ u_int64_t bcnt; /* byte match counter */ struct ipfw_flow_id id; /* (masked) flow id */ u_int32_t expire; /* expire time */ + u_int32_t lifetime; /* per-rule lifetime */ u_int32_t bucket; /* which bucket in hash table */ u_int32_t state; /* state of this rule (typically a * combination of TCP flags) --- /usr/src/sys/netinet/ip_fw2.c.orig Sat Jul 29 02:24:12 2006 +++ /usr/src/sys/netinet/ip_fw2.c Wed Aug 16 14:54:37 2006 @@ -1261,7 +1261,7 @@ } } } - q->expire = time_second + dyn_ack_lifetime; + q->expire = time_second + q->lifetime; break; case BOTH_SYN | BOTH_FIN: /* both sides closed */ @@ -1284,11 +1284,16 @@ q->expire = time_second + dyn_rst_lifetime; break; } - } else if (pkt->proto == IPPROTO_UDP) { - q->expire = time_second + dyn_udp_lifetime; } else { - /* other protocols */ - q->expire = time_second + dyn_short_lifetime; + /* + * UDP and other protocols: + * NOTE: The value of q->lifetime was set at the time this + * dynamic rule was created. It was either explicitly set + * by the ruleset creator to a specific value, or was pre- + * set to either dyn_udp_lifetime for UDP, or to + * dyn_short_lifetime for non-UDP protocols. + */ + q->expire = time_second + q->lifetime; } done: if (match_direction) @@ -1350,7 +1355,8 @@ * - "parent" rules for the above (O_LIMIT_PARENT). */ static ipfw_dyn_rule * -add_dyn_rule(struct ipfw_flow_id *id, u_int8_t dyn_type, struct ip_fw *rule) +add_dyn_rule(struct ipfw_flow_id *id, u_int8_t dyn_type, struct ip_fw *rule, + u_int32_t lifetime) { ipfw_dyn_rule *r; int i; @@ -1382,7 +1388,20 @@ } r->id = *id; - r->expire = time_second + dyn_syn_lifetime; + r->lifetime = lifetime; + if (r->id.proto == IPPROTO_TCP) { + r->lifetime = r->lifetime ? r->lifetime : dyn_ack_lifetime; + r->expire = time_second + dyn_syn_lifetime; + } else { + if (r->lifetime == 0) { + if (r->id.proto == IPPROTO_UDP) { + r->lifetime = dyn_udp_lifetime; + } else { + r->lifetime = dyn_short_lifetime; + } + } + r->expire = time_second + r->lifetime; + } r->rule = rule; r->dyn_type = dyn_type; r->pcnt = r->bcnt = 0; @@ -1437,7 +1456,7 @@ return q; } } - return add_dyn_rule(pkt, O_LIMIT_PARENT, rule); + return add_dyn_rule(pkt, O_LIMIT_PARENT, rule, 0); } /** @@ -1490,7 +1509,8 @@ switch (cmd->o.opcode) { case O_KEEP_STATE: /* bidir rule */ - add_dyn_rule(&args->f_id, O_KEEP_STATE, rule); + add_dyn_rule(&args->f_id, O_KEEP_STATE, rule, + ((ipfw_insn_u32 *)cmd)->d[0]); break; case O_LIMIT: { /* limit number of sessions */ @@ -1549,7 +1569,7 @@ return (1); } } - add_dyn_rule(&args->f_id, O_LIMIT, (struct ip_fw *)parent); + add_dyn_rule(&args->f_id, O_LIMIT, (struct ip_fw *)parent, 0); break; } default: @@ -3645,7 +3665,6 @@ DEB(printf("ipfw: opcode %d\n", cmd->opcode);) switch (cmd->opcode) { case O_PROBE_STATE: - case O_KEEP_STATE: case O_PROTO: case O_IP_SRC_ME: case O_IP_DST_ME: @@ -3677,6 +3696,7 @@ goto bad_size; break; + case O_KEEP_STATE: case O_UID: case O_GID: case O_JAIL: --- /usr/src/sbin/ipfw/ipfw2.c.orig Mon Aug 7 13:32:57 2006 +++ /usr/src/sbin/ipfw/ipfw2.c Wed Aug 16 14:52:55 2006 @@ -260,6 +260,7 @@ TOK_IN, TOK_LIMIT, TOK_KEEPSTATE, + TOK_LIFETIME, TOK_LAYER2, TOK_OUT, TOK_DIVERTED, @@ -394,6 +395,7 @@ { "in", TOK_IN }, { "limit", TOK_LIMIT }, { "keep-state", TOK_KEEPSTATE }, + { "lifetime", TOK_LIFETIME }, { "bridged", TOK_LAYER2 }, { "layer2", TOK_LAYER2 }, { "out", TOK_OUT }, @@ -1939,6 +1941,8 @@ case O_KEEP_STATE: printf(" keep-state"); + if (cmd32->d[0]) + printf(" lifetime %u", cmd32->d[0]); break; case O_LIMIT: { @@ -3857,6 +3861,9 @@ struct ip_fw *rule; + /* Temporary pointer to the most recent keep-state command: */ + ipfw_insn_u32 *cmd_keepstate = (ipfw_insn_u32 *)0; + /* * various flags used to record that we entered some fields. */ @@ -4558,7 +4565,20 @@ errx(EX_USAGE, "only one of keep-state " "and limit is allowed"); have_state = cmd; - fill_cmd(cmd, O_KEEP_STATE, 0, 0); + cmd->opcode = O_KEEP_STATE; + cmd->len = F_INSN_SIZE(ipfw_insn_u32); + cmd32->d[0] = 0; + cmd_keepstate = cmd32; + break; + + case TOK_LIFETIME: + if (cmd_keepstate == (ipfw_insn_u32 *)0) + errx(EX_USAGE, "lifetime must immediately " + "follow keep-state"); + NEED1("lifetime requires # of seconds"); + cmd_keepstate->d[0] = strtoul(*av, NULL, 0); + cmd_keepstate = (ipfw_insn_u32 *)0; + ac--; av++; break; case TOK_LIMIT: { --- /usr/src/sbin/ipfw/ipfw.8.orig Sat Jul 29 02:24:12 2006 +++ /usr/src/sbin/ipfw/ipfw.8 Wed Aug 16 14:52:55 2006 @@ -1282,14 +1282,35 @@ .It Cm ipversion Ar ver Matches IP packets whose IP version field is .Ar ver . -.It Cm keep-state +.It Xo Cm keep-state +.Op Cm lifetime Ar number +.Xc Upon a match, the firewall will create a dynamic rule, whose default behaviour is to match bidirectional traffic between source and destination IP/port using the same protocol. -The rule has a limited lifetime (controlled by a set of +The rule has a limited lifetime controlled by a set of .Xr sysctl 8 -variables), and the lifetime is refreshed every time a matching +variables, and the lifetime is refreshed every time a matching packet is found. +.Pp +The default limited rule lifetime behavior may be modified +for a specific rule by appending +.Cm lifetime Ar number +immediately after +.Cm keep-state . +Doing so will explicitly set the dynamic rule lifetime to the +specified number of seconds, overriding the default lifetime +behavior for the specified rule. +.Pp +For TCP rules, explicitly setting a rule lifetime overrides the +default setting stored in the +.Xr sysctl 8 +variable +.Em net.inet.ip.fw.dyn_ack_lifetime . +For UDP rules, it overrides +.Em net.inet.ip.fw.dyn_udp_lifetime . +For all other rules, it overrides +.Em net.inet.ip.fw.dyn_short_lifetime . .It Cm layer2 Matches only layer2 packets, i.e., those passed to .Nm ------=_Part_157133_22428623.1156641868079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Various PRs that have dealt with this issue:
  kern/46159 (still open)
  kern/28713 (closed, but should not have been in my opinion)
  kern/22065 (closed in favor of kern/28713)


Hi,

Here is the latest up-to-date version of the ipfw dynamic rule lifetime feature patch for 6.1-STABLE (STABLE as of 16 Aug. 2006) taken from my personal web site at http://www.adg.us/computers/ipfwpatch.html (currently down/unreachable due to gvinum issues, but should be back shortly) where patches for versions are available for FreeBSD from the 4.x and 5.x eras as well:

I would very much like to see this feature become part of the mainstream distribution.  Even with ipfw's built-in keepalive mechanisms, per-rule lifetime controls remain a powerful tool in my opinion, and as Oleg Koreshkov indicated in his PR submission, very likely in his opinion too.  It grants firewall administrators much greater control over the flow network traffic.

The per-rule lifetime features have been in use on many production machines that I manage for well over six years now.  There have been zero stability issues.  The patches to add these features are simple and straightforward.

There have been no negative problems brought up at any time in the past when I have posted about the patches to public mailing lists, and no negative problems mentioned in any of the PR reports submitted.  The only arguments against inclusion were that the features were not useful.  I believe that was just the personal opinion of one of the maintainers at the time (and I respect his opinion and his FreeBSD contributions, but in this particular case respectfully disagree), but it doesn't a ccount for the usefulness that I and others have found even after ipfw added built-in keepalive abilities.

On various hosts I have used the lifetime features, when ipfw keepalives were added, I rewrote my rulesets to remove the use of per-rule lifetimes in hopes that I could stop maintaining the patchsets.  Unfortunately, I discovered there were places in my own rulesets where keepalives could not fully replace the per-rule lifetime features, and so I've had to keep maintaining the patches to add these features to ipfw as I have done for over six years now.

So please carefully consider adding per-rule lifetimes to ipfw rules.  They're useful.  I think a wider audience of ipfw network admins. will find them useful.

Thank you.
Aaron Gifford

--- /usr/src/sys/netinet/ip_fw.h.orig   Sat Jul 29 02:24:12 2006
+++ /usr/src/sys/netinet/ip_fw.h        Wed Aug 16 14:52:55 2006
@@ -101,7 +101,7 @@
        O_VERSRCREACH,          /* none                         */

        O_PROBE_STATE,        &n bsp; /* none                         */
-       O_KEEP_STATE,           /* none                         */
+       O_KEEP_STATE,           /* u32 = optional lifetime      */
        O_LIMIT,   ;              /* ipfw_insn_limit              */
        O_LIMIT_PARENT,         /* dyn_type, not an opcode.     */

@@ -432,6 +432,7 @@
        u_int64_t       bcnt;           /* byte match counter           */
        struct ipfw_flow_id id;         /* (masked) flow id             */
         u_int32_t       expire;         /* expire time                  */
+       u_int32_t       lifetime;       /* per-rule lifetime            */
        u_int32_t       bucket;         /* which bucket in hash table   */
        u_int32_t       st ate;          /* state of this rule (typically a
                                         * combination of TCP flags)
--- /usr/src/sys/netinet/ip_fw2.c.orig  Sat Jul 29 02:24:12 2006
+++ /usr/src/sys/netinet/ip_fw2.c       Wed Aug 16 14:54:37 2006
@@ -1261,7 +1261,7 @@
                                }
                            }
                        }
-&n bsp;                      q->expire = time_second + dyn_ack_lifetime;
+                       q->expire = time_second + q->lifetime;
                        break;

                case BOTH_SYN | BOTH_FIN:       /* both sides closed */
@@ -1284,11 +1284,16 @@
                        q->ex pire = time_second + dyn_rst_lifetime;
                        break;
                }
-       } else if (pkt->proto == IPPROTO_UDP) {
-               q->expire = time_second + dyn_udp_lifetime;
        } else {
-               /* other protocols */
-                q->expire = time_second + dyn_short_lifetime;
+               /*
+                * UDP and other protocols:
+                *   NOTE: The value of q->lifetime was set at the time this
+                *   dynamic rule was cr eated.  It was either explicitly set
+                *   by the ruleset creator to a specific value, or was pre-
+                *   set to either dyn_udp_lifetime for UDP, or to
+                *   dyn_short_lifetime for non-UDP protocols.
+       ;          */
+               q->expire = time_second + q->lifetime;
        }
 done:
        if (match_direction)
@@ -1350,7 +1355,8 @@
  * - "parent" rules for the above (O_LIMIT_PARENT).
  */
 static ipfw_dyn_rule *
-add_dyn_rule(struct ipfw_flow_id *id, u_int8_t dyn_type, struct ip_fw *rule)
+add_dyn_rule(struct ipfw_flow_id *id, u_int8_t dyn_type, struct ip_fw *rule,
+            u_int32_t lifetime)
 {
        ipfw_dyn_rule *r;
        int i;
@@ -1382,7 +1388,20 @@
        }

        r->id = *id;
-       r->expire = time_second + dyn_syn_lifetime;
+       r->lifetime = lifetime;
+       if (r->id.proto == IPPROTO_TCP) {
+               r->lifetime = r->lifetime ? r->lifetime : dyn_ack_lifetime;
+               r->expire = time_second + dyn_syn_lifetime;
+       } else {
+               if (r->lifetime == 0) {
+                       if (r->id.proto == IPPROTO_UDP) {
+                               r->lifetime = dyn_udp_lifetime;
+                        } else {
+                               r->lifetime = dyn_short_lifetime;
+                       }
+               }
+               r->expire = time_second + r->lifetime;
+       }
        r->rule = rule;
       ;  r->dyn_type = dyn_type;
        r->pcnt = r->bcnt = 0;
@@ -1437,7 +1456,7 @@
                                return q;
                        }
        }
-       return add_dyn_rule(pkt, O_LIMIT_PARENT, rule);
+        return add_dyn_rule(pkt, O_LIMIT_PARENT, rule, 0);
 }

 /**
@@ -1490,7 +1509,8 @@

        switch (cmd->o.opcode) {
        case O_KEEP_STATE:      /* bidir rule */
-               add_dyn_rule(&args->f_id, O_KEEP_STATE, rule);
+               add_dyn_rule(&args->f_id, O_ KEEP_STATE, rule,
+                            ((ipfw_insn_u32 *)cmd)->d[0]);
                break;

        case O_LIMIT: {         /* limit number of sessions */
@@ -1549,7 +1569,7 @@
       ;                          return (1);
                        }
                }
-               add_dyn_rule(&args->f_id, O_LIMIT, (struct ip_fw *)parent);
+               add_dyn_rule(&args-&g t;f_id, O_LIMIT, (struct ip_fw *)parent, 0);
                break;
        }
        default:
@@ -3645,7 +3665,6 @@
                DEB(printf("ipfw: opcode %d\n", cmd->opcode);)
                switch (cmd->opcode) {
&nbs p;               case O_PROBE_STATE:
-               case O_KEEP_STATE:
                case O_PROTO:
                case O_IP_SRC_ME:
                case O_IP_DST_ME:
@@ -3677,6 +3696,7 @@
                                 goto bad_size;
                        break;

+               case O_KEEP_STATE:
                case O_UID:
                case O_GID:
      &n bsp;         case O_JAIL:
--- /usr/src/sbin/ipfw/ipfw2.c.orig     Mon Aug  7 13:32:57 2006
+++ /usr/src/sbin/ipfw/ipfw2.c  Wed Aug 16 14:52:55 2006
@@ -260,6 +260,7 @@
        TOK_IN,
        TOK_LIMIT,
        TOK_KEEPSTATE,
+       TOK_LIFETIME,
        TOK_LAYER2,
        TOK_OUT,
        TOK_DIVERTED,
@@ -394,6 +395,7 @@
        { "in",                 TOK_IN },
        { "limit",              TOK_LIMIT },
        { "keep-state",     &n bsp;   TOK_KEEPSTATE },
+       { "lifetime",           TOK_LIFETIME },
        { "bridged",            TOK_LAYER2 },
        { "layer2",             TOK_LAYER2 },
        { "out",                 TOK_OUT },
@@ -1939,6 +1941,8 @@

                        case O_KEEP_STATE:
                                printf(" keep-state");
+               &nb sp;               if (cmd32->d[0])
+                                       printf(" lifetime %u", cmd32->d[0]);
                                break;

                        case O_LIMIT: {
@@ -3857,6 +3861,9 @@

        struct ip_fw *rule;

+       /* Temporar y pointer to the most recent keep-state command: */
+       ipfw_insn_u32 *cmd_keepstate = (ipfw_insn_u32 *)0;
+
        /*
         * various flags used to record that we entered some fields.
         */
@@ -4558,7 +4565,20 @@
                                 errx(EX_USAGE, "only one of keep-state "
                                        "and limit is allowed");
                        have_state = cmd;
-            & nbsp;          fill_cmd(cmd, O_KEEP_STATE, 0, 0);
+                       cmd->opcode = O_KEEP_STATE;
+                       cmd->len = F_INSN_SIZE(ipfw_insn_u32);
+                       cmd32->d[0] = 0;
+                       cmd_keepstate = cmd32;
+ &nbs p;                     break;
+
+               case TOK_LIFETIME:
+                       if (cmd_keepstate == (ipfw_insn_u32 *)0)
+                               errx(EX_USAGE, "lifetime must immediately "
+                ;                        "follow keep-state");
+                       NEED1("lifetime requires # of seconds");
+                       cmd_keepstate->d[0] = strtoul(*av, NULL, 0);
+                       cmd_keepstate = (ipfw_insn_u32 *)0;
+                       ac--; av++;
                        break;

                case TOK_LIMIT: {
--- /usr/src/sbin/ipfw/ipfw.8.orig      Sat Jul 29 02:24:12 2006
+++ /usr/src/sbin/ipfw/ipfw.8   Wed Aug 16 14:52:55 2006
@@ -1282,14 +1282,35 @@
 .It Cm ipversion Ar ver
 Matches IP packets whose IP version field is
 .Ar ver .
-.It Cm keep-state
+.It Xo Cm keep-state
+.Op Cm lifetime Ar number
+.Xc
 Upon a match, the firewall will create a dynamic rule, whose
 default behaviour is to match bidirectional traffic between
 source and destination IP/port using the same protocol.
-The rule has a limited lifetime (controlled by a set of
+The rule has a limited lifetime controlled by a set of
 .Xr sysctl 8
-variables), and the lifetime is refreshed every time a matching
+variables, and the lifetime is refreshed every time a matching
 packet is found.
+.Pp
+The default limited rule lifetime behavior may be modified
+for a specific rule by appending
+.Cm lifetime Ar number
+immediately after
+.Cm keep-state .
+Doing so will explicitly set the dynamic rule lifetime to the
+specified number of seconds, overriding the default lifetime
+behavior for the specified rule.
+.Pp
+For TCP rules, explicitly setting a rule lifetime overrides the
+default setting stored in the
+.Xr sysctl 8
+variable
+.Em net.inet.ip.fw.dyn_ack_lifetime .
+For UDP rules, it overrides
+.Em net.inet.ip.fw.dyn_udp_lifetime .
+For all other rules, it overrides
+.Em net.inet.ip.fw.dyn_short_lifetime .
 .It Cm layer2
 Matches only layer2 packets, i.e., those passed to
 .Nm

------=_Part_157133_22428623.1156641868079-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 28 10:30:30 2006 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5521D16A4DE for ; Mon, 28 Aug 2006 10:30:30 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C21343D46 for ; Mon, 28 Aug 2006 10:30:30 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7SAUTQO066951 for ; Mon, 28 Aug 2006 10:30:29 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7SAUTBY066950; Mon, 28 Aug 2006 10:30:29 GMT (envelope-from gnats) Date: Mon, 28 Aug 2006 10:30:29 GMT Message-Id: <200608281030.k7SAUTBY066950@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Andrey V. Elsukov" Cc: Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Andrey V. Elsukov" List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2006 10:30:30 -0000 The following reply was made to PR bin/102422; it has been noted by GNATS. From: "Andrey V. Elsukov" To: "Stephen E. Halpin" Cc: bug-followup@FreeBSD.org, Oleg Bulyzhin , Gleb Smirnoff , Luigi Rizzo Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly Date: Mon, 28 Aug 2006 14:26:36 +0400 Stephen E. Halpin wrote: > processing, and it worked fine. I still have a question about PR 91245, > as when I went to the following page: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ > > and it looks like the last version of ipfw2.c is 1.96 on the MAIN > branch, and the changes in PR 91245 are not there. It would be awesome > if all three fixes could make it into the 6.2 release! This PR was closed by rev. 1.88 in CURRENT, and rev. 1.76.2.10 in RELENG_6, and will be in 6.2-RELEASE. But i don't know about this PR. Gleb, Oleg - any comments? :) -- WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 28 11:09:37 2006 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A518F16A4F0 for ; Mon, 28 Aug 2006 11:09:36 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6782E43DF1 for ; Mon, 28 Aug 2006 11:08:21 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7SB88To071538 for ; Mon, 28 Aug 2006 11:08:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7SB87DA071534 for freebsd-ipfw@FreeBSD.org; Mon, 28 Aug 2006 11:08:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Aug 2006 11:08:07 GMT Message-Id: <200608281108.k7SB87DA071534@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2006 11:09:37 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent f kern/51341 ipfw [ipfw] [patch] ipfw rule 'deny icmp from any to any ic o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o conf/78762 ipfw [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewal o bin/80913 ipfw [patch] /sbin/ipfw2 silently discards MAC addr arg wit o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o bin/102422 ipfw [patch] ipfw & kernel problems where firewall rules ar o kern/102471 ipfw [ipfw] [patch] add tos and dscp support 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/49086 ipfw [ipfw] [patch] Make ipfw2 log to different syslog prio o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/93422 ipfw ipfw divert rule no longer works in 6.0 (regression) o bin/95146 ipfw [ipfw][patch]ipfw -p option handler is bogus 19 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Aug 28 12:20:35 2006 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2115416A4E0 for ; Mon, 28 Aug 2006 12:20:35 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4500C43D72 for ; Mon, 28 Aug 2006 12:20:32 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7SCKWZm081899 for ; Mon, 28 Aug 2006 12:20:32 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7SCKWuX081898; Mon, 28 Aug 2006 12:20:32 GMT (envelope-from gnats) Date: Mon, 28 Aug 2006 12:20:32 GMT Message-Id: <200608281220.k7SCKWuX081898@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2006 12:20:35 -0000 The following reply was made to PR bin/102422; it has been noted by GNATS. From: Gleb Smirnoff To: "Andrey V. Elsukov" Cc: "Stephen E. Halpin" , bug-followup@FreeBSD.org, Oleg Bulyzhin , Luigi Rizzo Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly Date: Mon, 28 Aug 2006 16:15:30 +0400 On Mon, Aug 28, 2006 at 02:26:36PM +0400, Andrey V. Elsukov wrote: A> Stephen E. Halpin wrote: A> >processing, and it worked fine. I still have a question about PR 91245, A> >as when I went to the following page: A> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ A> > A> >and it looks like the last version of ipfw2.c is 1.96 on the MAIN A> >branch, and the changes in PR 91245 are not there. It would be awesome A> >if all three fixes could make it into the 6.2 release! A> A> This PR was closed by rev. 1.88 in CURRENT, and rev. 1.76.2.10 in A> RELENG_6, and will be in 6.2-RELEASE. But i don't know about this PR. A> Gleb, Oleg - any comments? :) I wonder why Max Laier, who has handled the isn't in cc? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-ipfw@FreeBSD.ORG Tue Aug 29 09:30:39 2006 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0867016A4DD for ; Tue, 29 Aug 2006 09:30:39 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3428A43D66 for ; Tue, 29 Aug 2006 09:30:27 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7T9URtp036468 for ; Tue, 29 Aug 2006 09:30:27 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7T9URDo036467; Tue, 29 Aug 2006 09:30:27 GMT (envelope-from gnats) Date: Tue, 29 Aug 2006 09:30:27 GMT Message-Id: <200608290930.k7T9URDo036467@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Stephen E. Halpin" Cc: Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Stephen E. Halpin" List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2006 09:30:39 -0000 The following reply was made to PR bin/102422; it has been noted by GNATS. From: "Stephen E. Halpin" To: Andrey V. Elsukov Cc: bug-followup@FreeBSD.org, Oleg Bulyzhin , Gleb Smirnoff , Luigi Rizzo Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly Date: Tue, 29 Aug 2006 05:33:34 -0400 On Aug 28, 2006, at 6:26 AM, Andrey V. Elsukov wrote: > Stephen E. Halpin wrote: >> processing, and it worked fine. I still have a question about PR >> 91245, as when I went to the following page: >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ >> and it looks like the last version of ipfw2.c is 1.96 on the MAIN >> branch, and the changes in PR 91245 are not there. It would be >> awesome if all three fixes could make it into the 6.2 release! > > This PR was closed by rev. 1.88 in CURRENT, and rev. 1.76.2.10 in > RELENG_6, and will be in 6.2-RELEASE. But i don't know about this > PR. Gleb, Oleg - any comments? :) Sorry, this was a misunderstanding on my part. The diffs in the PR (which is what I was looking for) are different from what's in the actual fix, which was checked in to the revisions you mention. At least I know where to look next time :-/ -Steve > -- > WBR, Andrey V. Elsukov From owner-freebsd-ipfw@FreeBSD.ORG Wed Aug 30 05:40:22 2006 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF10F16A4DA for ; Wed, 30 Aug 2006 05:40:22 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A8E943D55 for ; Wed, 30 Aug 2006 05:40:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k7U5eMvZ059683 for ; Wed, 30 Aug 2006 05:40:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k7U5eMDJ059682; Wed, 30 Aug 2006 05:40:22 GMT (envelope-from gnats) Date: Wed, 30 Aug 2006 05:40:22 GMT Message-Id: <200608300540.k7U5eMDJ059682@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: "Stephen E. Halpin" Cc: Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Stephen E. Halpin" List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2006 05:40:22 -0000 The following reply was made to PR bin/102422; it has been noted by GNATS. From: Stephen E. Halpin To: Stephen E. Halpin Cc: Andrey V. Elsukov , bug-followup@FreeBSD.org, Oleg Bulyzhin , Gleb Smirnoff , Luigi Rizzo Subject: Re: bin/102422: ipfw & kernel problems where firewall rules aren't interpreted correctly Date: Wed, 30 Aug 2006 01:44:01 -0400 Erf. I've since patched in the actual diffs for PR 91245 into a clean install of 6.1-RELEASE, and it now thinks "me6" is a hostname which it fails to process and dies. An example is: ipfw add 1 deny ip6 from any to me6 ipfw: hostname ``me6'' unknown There was a precedence issue which was addressed in MAIN, where the 'if' should not be taken if 'ret' is not NULL. 1.76.2.10 off RELENG_6 has: if ((ret == NULL) && proto == IPPROTO_IP || strcmp(av, "me") == 0 || !inet_pton(AF_INET6, host, &a)) 1.96 off MAIN has: if (ret == NULL && (proto == IPPROTO_IP || strcmp(av, "me") == 0 || !inet_pton(AF_INET6, host, &a))) Note that these should occur in add_src() and add_dst(). When this is added to the patches in 1.76.2.10, things appear to work. The page: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ipfw2.c doesn't appear to have another RELENG_6 checkin since 1.76.2.10, so if possible this should be fixed there with the other changes you've developed. -Steve On Aug 29, 2006, at 5:33 AM, Stephen E. Halpin wrote: > > On Aug 28, 2006, at 6:26 AM, Andrey V. Elsukov wrote: > >> Stephen E. Halpin wrote: >>> processing, and it worked fine. I still have a question about PR >>> 91245, as when I went to the following page: >>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/ipfw/ >>> and it looks like the last version of ipfw2.c is 1.96 on the MAIN >>> branch, and the changes in PR 91245 are not there. It would be >>> awesome if all three fixes could make it into the 6.2 release! >> >> This PR was closed by rev. 1.88 in CURRENT, and rev. 1.76.2.10 in >> RELENG_6, and will be in 6.2-RELEASE. But i don't know about this >> PR. Gleb, Oleg - any comments? :) > > Sorry, this was a misunderstanding on my part. The diffs in the PR > (which is what I was looking for) are different from what's in the > actual fix, which was checked in to the revisions you mention. At > least I know where to look next time :-/ > > -Steve > >> -- >> WBR, Andrey V. Elsukov > From owner-freebsd-ipfw@FreeBSD.ORG Fri Sep 1 12:19:40 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF49C16A4E0 for ; Fri, 1 Sep 2006 12:19:40 +0000 (UTC) (envelope-from loic.soutenare@prism.uvsq.fr) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDF7743D7D for ; Fri, 1 Sep 2006 12:19:07 +0000 (GMT) (envelope-from loic.soutenare@prism.uvsq.fr) Received: from torquenada.prism.uvsq.fr (torquenada.prism.uvsq.fr [193.51.25.9]) by soleil.uvsq.fr (8.13.5/jtpda-5.4) with ESMTP id k81CJ2Uh044455 for ; Fri, 1 Sep 2006 14:19:02 +0200 (CEST) Received: from dracula (dracula.prism.uvsq.fr [193.51.25.2]) by torquenada.prism.uvsq.fr (8.11.4/jtpda-5.3.2) with SMTP id k81CJ2706542 for ; Fri, 1 Sep 2006 14:19:02 +0200 (MEST) Message-ID: <001701c6cdc1$37064da0$021933c1@dracula> From: "Loic SOUTENARE" To: References: <20060727120042.7E55416A561@hub.freebsd.org> Date: Fri, 1 Sep 2006 14:21:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (soleil.uvsq.fr [193.51.24.1]); Fri, 01 Sep 2006 14:19:03 +0200 (CEST) X-Miltered: at soleil.uvsq.fr with ID 44F82536.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Virus-Scanned: ClamAV 0.88.3/1783/Thu Aug 31 22:56:17 2006 on soleil.uvsq.fr X-Virus-Status: Clean Subject: Re: freebsd-ipfw Digest, Vol 173, Issue 2 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 12:19:40 -0000 Hi every body, If I undertand your linux gateway as all is nics on the same network. It's supposed to do packet filtering and bind services at the same time. and your question were on one hand how? and on the over one's how to make a freebsd twin of the linux one? ok! I'am just a student trying to learn more about network and unix, so I won't pretend to have the best solution I will just say what I think about it. What I have seen so far allow me to the guest that making a freebsd bridge its a good compromise you can bridge your gateway and then alias your internal nic with the same address that the linux on got. Pcs into your network will believe they are connected to a switch providing the internet et bind services. Your LAN / \ / \ bge1 (with no address) bge1.0 (192.168.1.122) \ / \ / -------------------------------------------------- freeBSD Bridge | | bge0(192.168.1.121) | Internet this how it should look schematically and you'll be able to do filtering on interfaces and not addresses. A piece of my kernel conf file for example #------------------------------------------------------------------------------# # PARE-FEU # #------------------------------------------------------------------------------# options IPFIREWALL #| options IPFIREWALL_VERBOSE #|--->IPV4 options IPFIREWALL_VERBOSE_LIMIT=200 #| options IPFIREWALL_FORWARD #| #options IPFIREWALL_FORWARD_EXTENDED #|--->proxy options IPV6FIREWALL #| options IPV6FIREWALL_VERBOSE #|--->IPV6 options IPV6FIREWALL_VERBOSE_LIMIT=200 #| options DUMMYNET #Management de la bande passante. options IPDIVERT #Divert Sockets options IPSTEALTH #Ne touche pas au ttl, pare-feu transparent au traceroute options TCPDEBUG #Active le code qui garde les traces de l'etat TCP de la machine # la commande est trpt. options TCP_DROP_SYNFIN #rejete les paquets TCP avec SYN+FIN. options SOFTUPDATES # ameliore la rapidite du filesysteme et rend les redemarrage brutaux moins risque options QUOTA options SC_DISABLE_REBOOT # BRIGE/PONT RESEAU pare-feu transparent. options BRIDGE #------------------------------------------------------------------------------# # fin PARE-FEU # #------------------------------------------------------------------------------# ----- Original Message ----- From: To: Sent: Thursday, July 27, 2006 2:00 PM Subject: freebsd-ipfw Digest, Vol 173, Issue 2 > Send freebsd-ipfw mailing list submissions to > freebsd-ipfw@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > or, via email, send a message with subject or body 'help' to > freebsd-ipfw-request@freebsd.org > > You can reach the person managing the list at > freebsd-ipfw-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-ipfw digest..." > > > Today's Topics: > > 1. FreeBSD Gateway to replace old Linux gateway > (elaconta.com Webmaster) > 2. Re: FreeBSD Gateway to replace old Linux gateway > (Tony Abou-Assaleh) > 3. Re: FreeBSD Gateway to replace old Linux gateway > (elaconta.com Webmaster) > 4. RE: FreeBSD Gateway to replace old Linux gateway > (DeepBlackMagic@LootHole.Com) > 5. Re: FreeBSD Gateway to replace old Linux gateway > (Tony Abou-Assaleh) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Jul 2006 20:41:18 +0100 > From: "elaconta.com Webmaster" > Subject: FreeBSD Gateway to replace old Linux gateway > To: freebsd-ipfw@freebsd.org > Message-ID: <44C7C55E.3090907@elaconta.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Howdy > > We have here an old (Mandrake Linux 8 - yeah i know...) PC with two NICs > which serves as a firewall for our LAN and runs a Bind caching nameserver. > Although the machine is getting old, it still works well. Thing is, i'm > having a hard time trying to reproduce it, that is, getting another PC > to do exactly the same thing this PC is doing. It was configured by a > guy that left the company, so i can't simply ask him how he configured > it configured. > It's a precautionary measure, if the machine breaks down we need another > one to go in its place. > So while am at it i would love to replace the crusty old thing with a > new one running FreeBSD. > The networking scheme is: > > Router (192.168.1.120) <-> (192.168.1.121) Firewall PC (192.168.1.122) > <-> (192.168.1.0/24) LAN > > Now, thing is, the Linux firewall has two NICs: > > NIC 1: 192.168.1.121 > NIC 2: 192.168.1.122 > > The two NICs on the Linux box are configured with 192.168.1.121 and > 192.168.1.122, both interfaces on the same subnet. 192.168.1.121 acesses > the company router (192.168.1.120) and 192.168.1.122 acesses the company > LAN (192.168.1.0/24) >>From what i've googled, this shouldn't even be possible, everything is > on the same subnet. Regardless, it works great, and if i went and got an > FreeBSD rig to replace the old Linux rig, it would have to retain this > networking scheme, we can't afford to reconfigure the entire network > just for switching our firewall. > > I known we could use a network bridge, but we need the caching > nameserver functionality. > > I'm an all round Unix guy, but i'm a bit green on the routing departament. > > Can an FreeBSD box be configured the same way the Linux box is so it can > be a drop-in replacement for the Linux box? I can of course depict in > further detail the configuration of the Linux box (netstat -r to show > the routes, ifconfig or whatever). > > I've already prepped a FreeBSD 6.1 box which already works if the NICs in > the gateway > are in different subnets (dc0 is 192.168.1.125 and dc1 is 192.168.0.5, for > instance), > i've changed a PC in the network to the 192.168.0.20 IP (instead of > 192.168.1.20) and > if connected without a problem to the Internet, but we have lots of > appliances which > depend on the 192.168.1.0 style network. We would need the two NICs in the > box to be in the same subnet... > > ----------------------------- > Elaconta.com Webmaster > ----------------------------- > > > > ------------------------------ > > Message: 2 > Date: Wed, 26 Jul 2006 19:16:23 -0300 (ADT) > From: Tony Abou-Assaleh > Subject: Re: FreeBSD Gateway to replace old Linux gateway > To: "elaconta.com Webmaster" > Cc: freebsd-ipfw@freebsd.org > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII > > I would like to see a reference that shows that it is not possible to have > two networks with the same subnet IP ranges. In fact, your working linux > PC is a good example that it can be done. > > You need to be careful not to use the same full IP address on both sides > of the network, that's about it. The rest can be handled with a proper > configuration of the routing table. > > take a look at your routing table (using route) and see if you can > reproduce it on FreeBSD. If you run into problems on the freebsd, report > them, and someone might recognize something. > > Cheers, > > TAA > > ----------------------------------------------------- > Tony Abou-Assaleh > Email: taa@acm.org > Web site: http://taa.eits.ca > ----------------------[THE END]---------------------- > > On Wed, 26 Jul 2006, elaconta.com Webmaster wrote: > >> Howdy >> >> We have here an old (Mandrake Linux 8 - yeah i know...) PC with two NICs >> which serves as a firewall for our LAN and runs a Bind caching >> nameserver. >> Although the machine is getting old, it still works well. Thing is, i'm >> having a hard time trying to reproduce it, that is, getting another PC >> to do exactly the same thing this PC is doing. It was configured by a >> guy that left the company, so i can't simply ask him how he configured >> it configured. >> It's a precautionary measure, if the machine breaks down we need another >> one to go in its place. >> So while am at it i would love to replace the crusty old thing with a >> new one running FreeBSD. >> The networking scheme is: >> >> Router (192.168.1.120) <-> (192.168.1.121) Firewall PC (192.168.1.122) >> <-> (192.168.1.0/24) LAN >> >> Now, thing is, the Linux firewall has two NICs: >> >> NIC 1: 192.168.1.121 >> NIC 2: 192.168.1.122 >> >> The two NICs on the Linux box are configured with 192.168.1.121 and >> 192.168.1.122, both interfaces on the same subnet. 192.168.1.121 acesses >> the company router (192.168.1.120) and 192.168.1.122 acesses the company >> LAN (192.168.1.0/24) >> >From what i've googled, this shouldn't even be possible, everything is >> on the same subnet. Regardless, it works great, and if i went and got an >> FreeBSD rig to replace the old Linux rig, it would have to retain this >> networking scheme, we can't afford to reconfigure the entire network >> just for switching our firewall. >> >> I known we could use a network bridge, but we need the caching >> nameserver functionality. >> >> I'm an all round Unix guy, but i'm a bit green on the routing >> departament. >> >> Can an FreeBSD box be configured the same way the Linux box is so it can >> be a drop-in replacement for the Linux box? I can of course depict in >> further detail the configuration of the Linux box (netstat -r to show >> the routes, ifconfig or whatever). >> >> I've already prepped a FreeBSD 6.1 box which already works if the NICs in >> the gateway >> are in different subnets (dc0 is 192.168.1.125 and dc1 is 192.168.0.5, >> for instance), >> i've changed a PC in the network to the 192.168.0.20 IP (instead of >> 192.168.1.20) and >> if connected without a problem to the Internet, but we have lots of >> appliances which >> depend on the 192.168.1.0 style network. We would need the two NICs in >> the box to be in the same subnet... >> >> ----------------------------- >> Elaconta.com Webmaster >> ----------------------------- >> >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> > > > ------------------------------ > > Message: 3 > Date: Thu, 27 Jul 2006 00:03:26 +0100 > From: "elaconta.com Webmaster" > Subject: Re: FreeBSD Gateway to replace old Linux gateway > To: Tony Abou-Assaleh > Cc: freebsd-ipfw@freebsd.org > Message-ID: <44C7F4BE.2080805@elaconta.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Tony Abou-Assaleh wrote: >> I would like to see a reference that shows that it is not possible to >> have >> two networks with the same subnet IP ranges. In fact, your working linux >> PC is a good example that it can be done. >> >> You need to be careful not to use the same full IP address on both sides >> of the network, that's about it. The rest can be handled with a proper >> configuration of the routing table. >> >> take a look at your routing table (using route) and see if you can >> reproduce it on FreeBSD. If you run into problems on the freebsd, report >> them, and someone might recognize something. >> >> Cheers, >> >> TAA >> >> ----------------------------------------------------- >> Tony Abou-Assaleh >> Email: taa@acm.org >> Web site: http://taa.eits.ca >> ----------------------[THE END]---------------------- >> >> On Wed, 26 Jul 2006, elaconta.com Webmaster wrote: >> >> >>> Howdy >>> >>> We have here an old (Mandrake Linux 8 - yeah i know...) PC with two NICs >>> which serves as a firewall for our LAN and runs a Bind caching >>> nameserver. >>> Although the machine is getting old, it still works well. Thing is, i'm >>> having a hard time trying to reproduce it, that is, getting another PC >>> to do exactly the same thing this PC is doing. It was configured by a >>> guy that left the company, so i can't simply ask him how he configured >>> it configured. >>> It's a precautionary measure, if the machine breaks down we need another >>> one to go in its place. >>> So while am at it i would love to replace the crusty old thing with a >>> new one running FreeBSD. >>> The networking scheme is: >>> >>> Router (192.168.1.120) <-> (192.168.1.121) Firewall PC (192.168.1.122) >>> <-> (192.168.1.0/24) LAN >>> >>> Now, thing is, the Linux firewall has two NICs: >>> >>> NIC 1: 192.168.1.121 >>> NIC 2: 192.168.1.122 >>> >>> The two NICs on the Linux box are configured with 192.168.1.121 and >>> 192.168.1.122, both interfaces on the same subnet. 192.168.1.121 acesses >>> the company router (192.168.1.120) and 192.168.1.122 acesses the company >>> LAN (192.168.1.0/24) >>> >From what i've googled, this shouldn't even be possible, everything is >>> on the same subnet. Regardless, it works great, and if i went and got an >>> FreeBSD rig to replace the old Linux rig, it would have to retain this >>> networking scheme, we can't afford to reconfigure the entire network >>> just for switching our firewall. >>> >>> I known we could use a network bridge, but we need the caching >>> nameserver functionality. >>> >>> I'm an all round Unix guy, but i'm a bit green on the routing >>> departament. >>> >>> Can an FreeBSD box be configured the same way the Linux box is so it can >>> be a drop-in replacement for the Linux box? I can of course depict in >>> further detail the configuration of the Linux box (netstat -r to show >>> the routes, ifconfig or whatever). >>> >>> I've already prepped a FreeBSD 6.1 box which already works if the NICs >>> in the gateway >>> are in different subnets (dc0 is 192.168.1.125 and dc1 is 192.168.0.5, >>> for instance), >>> i've changed a PC in the network to the 192.168.0.20 IP (instead of >>> 192.168.1.20) and >>> if connected without a problem to the Internet, but we have lots of >>> appliances which >>> depend on the 192.168.1.0 style network. We would need the two NICs in >>> the box to be in the same subnet... >>> >>> ----------------------------- >>> Elaconta.com Webmaster >>> ----------------------------- >>> >>> _______________________________________________ >>> freebsd-ipfw@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >>> >>> >> >> >> > The routing table on the Linux box, as shown per the "route" command: > > [root@visao root]# route > Tabela de Roteamento IP do Kernel > Destino Roteador MáscaraGen. Opções Métrica > Ref Uso Iface > 192.168.1.0 * 255.255.255.0 U 0 > 0 0 eth1 > 192.168.1.0 * 255.255.255.0 U 0 > 0 0 eth1 > 127.0.0.0 * 255.0.0.0 U 0 > 0 0 lo > default 192.168.1.120 0.0.0.0 UG 0 > 0 0 eth0 > > Hum, some things in this table are in portuguese... Basically "Tabela de > Roteamento IP do Kernel" means Kernel IP Routing Table, "Destino" means > Destiny, "Roteador" means Router, "Máscara" means Mask. > Now the thing that strikes me in this Linux routing table are the > asterisks (*).Are they normal, or some kind of Linux black magic? > Is there a way to reproduce this routing table on FreeBSD? What do the > asteriks mean? > > ----------------------------- > Elaconta.com Webmaster > ----------------------------- > > > > > ------------------------------ > > Message: 4 > Date: Wed, 26 Jul 2006 18:11:09 -0500 > From: > Subject: RE: FreeBSD Gateway to replace old Linux gateway > To: > Message-ID: <02dc01c6b108$cb620050$0a010a0a@blackice> > Content-Type: text/plain; charset="US-ASCII" > > I was thinking that the interfaces could simply be bridged, and could you > do > a traceroute from a workstation to say google.com and see if the firewall > appears as a hop. If it's a hop, its routing, vs if its invisible, its > bridging. That should help guide you in the creation of a replacement. > > DBM > > > -----Original Message----- > From: owner-freebsd-ipfw@freebsd.org > [mailto:owner-freebsd-ipfw@freebsd.org] > On Behalf Of elaconta.com Webmaster > Sent: Wednesday, July 26, 2006 2:41 PM > To: freebsd-ipfw@freebsd.org > Subject: FreeBSD Gateway to replace old Linux gateway > > Howdy > > We have here an old (Mandrake Linux 8 - yeah i know...) PC with two NICs > which serves as a firewall for our LAN and runs a Bind caching nameserver. > Although the machine is getting old, it still works well. Thing is, i'm > having a hard time trying to reproduce it, that is, getting another PC to > do > exactly the same thing this PC is doing. It was configured by a guy that > left the company, so i can't simply ask him how he configured it > configured. > It's a precautionary measure, if the machine breaks down we need another > one > to go in its place. > So while am at it i would love to replace the crusty old thing with a new > one running FreeBSD. > The networking scheme is: > > Router (192.168.1.120) <-> (192.168.1.121) Firewall PC (192.168.1.122) <-> > (192.168.1.0/24) LAN > > Now, thing is, the Linux firewall has two NICs: > > NIC 1: 192.168.1.121 > NIC 2: 192.168.1.122 > > The two NICs on the Linux box are configured with 192.168.1.121 and > 192.168.1.122, both interfaces on the same subnet. 192.168.1.121 acesses > the > company router (192.168.1.120) and 192.168.1.122 acesses the company LAN > (192.168.1.0/24) >>From what i've googled, this shouldn't even be possible, everything is > on the same subnet. Regardless, it works great, and if i went and got an > FreeBSD rig to replace the old Linux rig, it would have to retain this > networking scheme, we can't afford to reconfigure the entire network just > for switching our firewall. > > I known we could use a network bridge, but we need the caching nameserver > functionality. > > I'm an all round Unix guy, but i'm a bit green on the routing departament. > > Can an FreeBSD box be configured the same way the Linux box is so it can > be > a drop-in replacement for the Linux box? I can of course depict in further > detail the configuration of the Linux box (netstat -r to show the routes, > ifconfig or whatever). > > I've already prepped a FreeBSD 6.1 box which already works if the NICs in > the gateway are in different subnets (dc0 is 192.168.1.125 and dc1 is > 192.168.0.5, for instance), i've changed a PC in the network to the > 192.168.0.20 IP (instead of 192.168.1.20) and if connected without a > problem > to the Internet, but we have lots of appliances which depend on the > 192.168.1.0 style network. We would need the two NICs in the box to be in > the same subnet... > > ----------------------------- > Elaconta.com Webmaster > ----------------------------- > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > > ------------------------------ > > Message: 5 > Date: Thu, 27 Jul 2006 00:15:44 -0300 (ADT) > From: Tony Abou-Assaleh > Subject: Re: FreeBSD Gateway to replace old Linux gateway > To: "elaconta.com Webmaster" > Cc: freebsd-ipfw@freebsd.org > Message-ID: > Content-Type: TEXT/PLAIN; charset=X-UNKNOWN > > On Thu, 27 Jul 2006, elaconta.com Webmaster wrote: >> The routing table on the Linux box, as shown per the "route" command: >> >> [root@visao root]# route >> Tabela de Roteamento IP do Kernel >> Destino Roteador MáscaraGen. Opções Métrica >> Ref Uso Iface >> 192.168.1.0 * 255.255.255.0 U 0 >> 0 0 eth1 >> 192.168.1.0 * 255.255.255.0 U 0 >> 0 0 eth1 >> 127.0.0.0 * 255.0.0.0 U 0 >> 0 0 lo >> default 192.168.1.120 0.0.0.0 UG 0 >> 0 0 eth0 >> >> Hum, some things in this table are in portuguese... Basically "Tabela de >> Roteamento IP do Kernel" means Kernel IP Routing Table, "Destino" means >> Destiny, "Roteador" means Router, "Máscara" means Mask. >> Now the thing that strikes me in this Linux routing table are the >> asterisks (*).Are they normal, or some kind of Linux black magic? >> Is there a way to reproduce this routing table on FreeBSD? What do the >> asteriks mean? > > In English, the headings are: > > Destination Gateway Genmask Flags Metric Ref Use > Iface > > Gateway is more appropriately described as 'next hop'. In your case, that > would be the IP of your router for all outgoing external traffic. Since > the internal traffic is connected directly (likely through an Ethernet > hub), packets going to the LAN should be destined directly to their > destination IP. > > According to your routing table, I believe there is no way to access the > web interface of your router (if any) from your LAN, because all > 192.168.1.* traffic will be sent on eth1, which is your LAN. > > You can use the route command manipulate the routing table directly and > reproduce the above. I think it can also be done using the firewall, but > it's a little trickier there. Check your firewall rules to see if it is > set explicitly there. (if it is, then you should see rules that are > similar > to the entries in the routing table in terms of content). > > Cheers, > > TAA > > ----------------------------------------------------- > Tony Abou-Assaleh > Email: taa@acm.org > Web site: http://taa.eits.ca > ----------------------[THE END]---------------------- > > > ------------------------------ > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > End of freebsd-ipfw Digest, Vol 173, Issue 2 > ******************************************** >