From bugmaster at FreeBSD.org Mon Nov 3 03:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 3 03:08:07 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200811031106.mA3B6sCb010932@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 48 problems total. From thavinci at thavinci.za.net Tue Nov 4 04:47:40 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Tue Nov 4 04:47:46 2008 Subject: Dual ADSL Load Balancing Message-ID: <013a01c93e78$c1ff2010$45fd6030$@za.net> Ok I have managed to get this working by running two instances of natd, the works. Then by using ipfw fwd "to appropriate gateway" for "appropriate protocol" type of approach. However here is the question. The machine obviously has one of the gateways set as it's main route and only protocols explicitily sent to other gateway using fwd gows through other line. But incoming connections is my problem, I need to be able to say in lamence terms If connection comes in on adsl2 send it to gateway2 I think whats happening now is it comes in on adsl2 gows out adsl1 Input!? From dev+lists at humph.com Tue Nov 4 09:47:23 2008 From: dev+lists at humph.com (Giuliano Gavazzi) Date: Tue Nov 4 09:47:29 2008 Subject: Dual ADSL Load Balancing In-Reply-To: <013a01c93e78$c1ff2010$45fd6030$@za.net> References: <013a01c93e78$c1ff2010$45fd6030$@za.net> Message-ID: <7F815F03-3B0E-41E3-B349-4A957A8C1F08@humph.com> On T 4 Nov, 2008, at 13:27 , Marcel Grandemange wrote: > The machine obviously has one of the gateways set as it's main route > and > only protocols explicitily sent to other gateway using fwd gows > through > other line. > > But incoming connections is my problem, I need to be able to say in > lamence > terms If I understood your problem correctly the solution to the incoming connections is simple. You must use two distinct aliases on your machine, one for each ADSL. If you also do NATing, as you seem to, I would also use a different alias to alias to, although not necessary it separates conveniently natted and not natted traffic. The two different ADSL do not have to be on the same physical or logical network. Suppose you have two logical (and optionally also physically separated) networks: 192.168.1.1/24 for ADSL1 and 192.168.2.1/24 for ADSL2: on your machine you'll use, for instance: 192.168.1.10 for incoming connections to the machine itself 192.168.1.11 natted connections from internal machines 192.168.2.10 for incoming connections to the machine itself 192.168.2.11 natted connections from internal machines of course outgoing connections from either will have to be forwarded to the appropriate gateway (presumably 192.168.1.1 and 192.168.1.2). Giuliano From dev+lists at humph.com Tue Nov 4 12:05:52 2008 From: dev+lists at humph.com (Giuliano Gavazzi) Date: Tue Nov 4 12:06:00 2008 Subject: Dual ADSL Load Balancing In-Reply-To: <7F815F03-3B0E-41E3-B349-4A957A8C1F08@humph.com> References: <013a01c93e78$c1ff2010$45fd6030$@za.net> <7F815F03-3B0E-41E3-B349-4A957A8C1F08@humph.com> Message-ID: <84782858-B994-462A-8F92-4881842C2A64@humph.com> On T 4 Nov, 2008, at 18:23 , Giuliano Gavazzi wrote: > 192.168.1.10 for incoming connections to the machine itself > 192.168.1.11 natted connections from internal machines > > > 192.168.2.10 for incoming connections to the machine itself > 192.168.2.11 natted connections from internal machines > > of course outgoing connections from either will have to be forwarded > to the appropriate gateway (presumably 192.168.1.1 and 192.168.1.2). clearly this should have been 192.168.1.1 and 192.168.2.1! g From fabio982 at yahoo.it Wed Nov 5 02:14:14 2008 From: fabio982 at yahoo.it (ruzzetto) Date: Wed Nov 5 02:14:21 2008 Subject: Squid not working with IPFW and NATD Message-ID: <20339037.post@talk.nabble.com> Hi, i've a server with FreeBSd 7.0 installed on. I also installed squid and ipfw to build a little proxy. If i try to surfe on web without ifpw that's ok. When i start ipfw i can't surfe and i can't found the problem. Is there any particular configuratio for ipfw or squid??? Thanks. Fabio -- View this message in context: http://www.nabble.com/Squid-not-working-with-IPFW-and-NATD-tp20339037p20339037.html Sent from the freebsd-ipfw mailing list archive at Nabble.com. From fabio982 at yahoo.it Wed Nov 5 03:16:54 2008 From: fabio982 at yahoo.it (Fabio) Date: Wed Nov 5 04:24:08 2008 Subject: Squid problem with IPFW enabled Message-ID: <973475.78335.qm@web26005.mail.ukl.yahoo.com> Hi, i've a server with FreeBSd 7.0 installed on. I also installed squid and ipfw to build a little proxy. If i try to surfe on web without ifpw that's ok. When i start ipfw i can't surfe and i can't found the problem. Is there any particular configuratio for ipfw or squid??? Thanks. Fabio Unisciti alla community di Io fotografo e video, il nuovo corso di fotografia di Gazzetta dello sport: http://www.flickr.com/groups/iofotografoevideo From rik at inse.ru Wed Nov 5 11:50:18 2008 From: rik at inse.ru (Roman Kurakin) Date: Wed Nov 5 11:50:25 2008 Subject: Squid not working with IPFW and NATD In-Reply-To: <20339037.post@talk.nabble.com> References: <20339037.post@talk.nabble.com> Message-ID: <4911F833.4090009@localhost.inse.ru> Could you provide your configuration settings. rik ruzzetto wrote: > Hi, > i've a server with FreeBSd 7.0 installed on. I also installed squid and ipfw > to build a little proxy. > If i try to surfe on web without ifpw that's ok. When i start ipfw i can't > surfe and i can't found the problem. > > Is there any particular configuratio for ipfw or squid??? > > Thanks. > > Fabio > From thavinci at thavinci.za.net Thu Nov 6 02:25:07 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Thu Nov 6 02:25:16 2008 Subject: TOS/DSCP Message-ID: <03a101c93ff9$db7e64b0$927b2e10$@za.net> Good day, It would be great if someone could show me an example of how to make ipfw rules based on TOS. I have a external box that marks all p2p packets and gives them the TOS of 8. What Id like to do is build rules on the bsd machine that can match those packets with TOS 8.. Examples anyone? From araujobsdport at gmail.com Thu Nov 6 03:18:13 2008 From: araujobsdport at gmail.com (Marcelo Araujo) Date: Thu Nov 6 03:18:19 2008 Subject: TOS/DSCP In-Reply-To: <03a101c93ff9$db7e64b0$927b2e10$@za.net> References: <03a101c93ff9$db7e64b0$927b2e10$@za.net> Message-ID: <20081106184758.GA1514@ponderosa.intelbras.com.br> On Thu, Nov 06, 2008 at 12:24:31PM +0200, Marcel Grandemange wrote: > Good day, > > It would be great if someone could show me an example of how to make ipfw > rules based on TOS. > I have a external box that marks all p2p packets and gives them the TOS of > 8. > What Id like to do is build rules on the bsd machine that can match those > packets with TOS 8.. > > Examples anyone? > Hello dear Marcel, Some time ago I did a research about FreeBSD and QoS. With this research I started to developing and organize some patchs for IPFW, but these aren't finished, however you can use that. About ToS and IPFW: http://code.google.com/p/exports/wiki/ToSWorkAround About DSCP and IPFW: http://code.google.com/p/exports/wiki/DSCPWorkAround It was started also a new user function called *modip* that indeed just together some tools to provide a QoS implementation. Patch of MODIP: http://people.freebsd.org/~araujo/logs/ipfw-modip20080324.diff How you can use that: ipfw add 10 modip tos:lowdelay ip from any to any ipfw add 11 modip dscp:af14 ip from any to any ipfw add 12 modip ippre:flash ip from any to any Bye for now, Best Regards, -- Marcelo Araujo araujo@FreeBSD.org http://www.FreeBSD.org The first myth of management is that it exists the second myth of management is that success equals skill. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20081106/25c032b1/attachment.pgp From bugmaster at FreeBSD.org Mon Nov 10 03:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 10 03:08:15 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200811101106.mAAB6qPH049747@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 48 problems total. From ienfant at gmail.com Thu Nov 13 15:19:47 2008 From: ienfant at gmail.com (Son, Yeongsik) Date: Thu Nov 13 15:20:09 2008 Subject: change specific linux iptables rule set to ipfw rule set Message-ID: <8db0c7c40811131452v70d2c2fds672384a42da5c5@mail.gmail.com> 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? Let me share your knowledge. From julian at elischer.org Thu Nov 13 16:50:15 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Nov 13 16:50:22 2008 Subject: change specific linux iptables rule set to ipfw rule set In-Reply-To: <8db0c7c40811131452v70d2c2fds672384a42da5c5@mail.gmail.com> References: <8db0c7c40811131452v70d2c2fds672384a42da5c5@mail.gmail.com> Message-ID: <491CC89C.2040702@elischer.org> 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 "freebsd-ipfw-unsubscribe@freebsd.org" From julian at elischer.org Thu Nov 13 18:18:34 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Nov 13 18:18:46 2008 Subject: rc.firewall quick change Message-ID: <491CD94F.3020207@elischer.org> 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 From smithi at nimnet.asn.au Thu Nov 13 19:11:13 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Nov 13 19:11:26 2008 Subject: Speaking of rc.firewall .. (fwd) Message-ID: <20081114134925.E70117@sola.nimnet.asn.au> ---------- Forwarded message ---------- Date: Fri, 17 Oct 2008 05:24:43 +1100 (EST) From: Ian Smith To: freebsd-ipfw@freebsd.org Subject: Re: Speaking of rc.firewall .. On Thu, 16 Oct 2008, Ian Smith wrote: > I see that both HEAD and RELENG_7 rc.firewall have been updated for in- > kernel NAT functionality, but only for the 'open' and 'client' rulesets. > > Is there any (functional) reason that the ${firewall_nat_enable} case is > not also included in the 'simple' rules, where its different placement > is determined by being preceded and anteceded by anti-spoofing rules? > > I'm also slightly bemused by the lack (still) of any rules to allow any > ICMP (especially necessary icmptypes for MTU discovery) in 'simple'? To put my patch where my mouth is, assuming that the answer to my first question is likely 'no', this is against the present RELENG_7 version. It addresses the second (ICMP) issue for 'client' and 'simple', and I see no harm in enabling outbound pings for such out-of-the-box setups? Hope this format's useful (just diff -u), and also that inline is ok. cheers, Ian --- rc.firewall.1.52.2.3 Fri Oct 17 01:34:56 2008 +++ rc.firewall Fri Oct 17 04:27:36 2008 @@ -116,15 +116,14 @@ # will then be run again on each packet after translation by natd # starting at the rule number following the divert rule. # -# For ``simple'' firewall type the divert rule should be put to a +# For ``simple'' firewall type the divert rule is included in a # different place to not interfere with address-checking rules. # -case ${firewall_type} in -[Oo][Pp][Ee][Nn]|[Cc][Ll][Ii][Ee][Nn][Tt]) +setup_nat () { case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then - ${fwcmd} add 50 divert natd ip4 from any to any via ${natd_interface} + ${fwcmd} add $1 divert natd ip4 from any to any via ${natd_interface} fi ;; esac @@ -138,11 +137,11 @@ firewall_nat_flags="if ${firewall_nat_interface} ${firewall_nat_flags}" fi ${fwcmd} nat 123 config log ${firewall_nat_flags} - ${fwcmd} add 50 nat 123 ip4 from any to any via ${firewall_nat_interface} + ${fwcmd} add $1 nat 123 ip4 from any to any via ${firewall_nat_interface} fi ;; esac -esac +} ############ # If you just configured ipfw in the kernel as a tool to solve network @@ -157,6 +156,7 @@ # case ${firewall_type} in [Oo][Pp][Ee][Nn]) + setup_nat 50 ${fwcmd} add 65000 pass all from any to any ;; @@ -172,6 +172,8 @@ # set this to your local network net="$firewall_client_net" + setup_nat 50 + # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me @@ -197,6 +199,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + # Allow outbound pings + ${fwcmd} add pass icmp from me to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 + # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. @@ -248,13 +256,7 @@ # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. - case ${natd_enable} in - [Yy][Ee][Ss]) - if [ -n "${natd_interface}" ]; then - ${fwcmd} add divert natd all from any to any via ${natd_interface} - fi - ;; - esac + setup_nat # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} @@ -298,6 +300,12 @@ # Allow NTP queries out in the world ${fwcmd} add pass udp from me to any 123 keep-state + + # Allow outbound pings from our net + ${fwcmd} add pass icmp from any to any out icmptypes 8 keep-state + + # Allow essential ICMP: unreachable, source quench, TTL exceeded + ${fwcmd} add pass icmp from any to any icmptypes 3,4,11 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel From smithi at nimnet.asn.au Thu Nov 13 19:11:14 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Nov 13 19:11:37 2008 Subject: rc.firewall quick change In-Reply-To: <491CD94F.3020207@elischer.org> References: <491CD94F.3020207@elischer.org> Message-ID: <20081114133913.K70117@sola.nimnet.asn.au> 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? 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 "freebsd-ipfw-unsubscribe@freebsd.org" > From julian at elischer.org Fri Nov 14 00:31:26 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 14 00:31:39 2008 Subject: rc.firewall quick change In-Reply-To: <20081114133913.K70117@sola.nimnet.asn.au> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> Message-ID: <491D375D.1070809@elischer.org> 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 "freebsd-ipfw-unsubscribe@freebsd.org" > > > _______________________________________________ > 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" From julian at elischer.org Fri Nov 14 01:10:09 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 14 01:10:15 2008 Subject: rc.firewall quick change In-Reply-To: <491D375D.1070809@elischer.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> Message-ID: <491D406F.5030806@elischer.org> 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: -------------- next part -------------- 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 From brde at optusnet.com.au Fri Nov 14 02:38:30 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Nov 14 02:38:42 2008 Subject: rc.firewall quick change In-Reply-To: <491D375D.1070809@elischer.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> Message-ID: <20081114211043.W54700@delplex.bde.org> 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. > 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. Bruce From julian at elischer.org Fri Nov 14 10:16:28 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 14 10:16:43 2008 Subject: rc.firewall quick change In-Reply-To: <20081114211043.W54700@delplex.bde.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> Message-ID: <491DC07B.6070304@elischer.org> 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 From dougb at FreeBSD.org Fri Nov 14 12:34:10 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Nov 14 12:34:21 2008 Subject: rc.firewall quick change In-Reply-To: <491DC07B.6070304@elischer.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> <491DC07B.6070304@elischer.org> Message-ID: <491DDA7F.1040004@FreeBSD.org> 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. 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 -- This .signature sanitized for your protection From julian at elischer.org Fri Nov 14 12:49:50 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Nov 14 12:50:02 2008 Subject: rc.firewall quick change In-Reply-To: <491DDA7F.1040004@FreeBSD.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <20081114211043.W54700@delplex.bde.org> <491DC07B.6070304@elischer.org> <491DDA7F.1040004@FreeBSD.org> Message-ID: <491DE46D.8070205@elischer.org> 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 > From smithi at nimnet.asn.au Fri Nov 14 21:51:58 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Nov 14 21:52:10 2008 Subject: rc.firewall quick change In-Reply-To: <491D406F.5030806@elischer.org> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <491D406F.5030806@elischer.org> Message-ID: <20081115024024.O70117@sola.nimnet.asn.au> On Fri, 14 Nov 2008, Julian Elischer wrote: > 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). I prefer binary, but whatever :) > > Remember though that a user wouldn't be using 'simple' if he's using his > > own tables etc. This is an important point. Please allow me a little pent-up critique: Originally, eg for me over 10 years ago, till recently, the only way to use the 'client' or 'simple' rulesets was to hack rc.firewall, which I did relentlessly, like many people I'm sure .. that is, we treated it more as a starter example, not something that could be used as is. More recent updates have introduced rc vars that concievably make these rulesets usable out of the box, in as much as you could tell a newbie to FreeBSD firewalls and ipfw in particular, "setup these vars for your network, select the 'client' or 'simple' ruleset as appropriate, and you have a fair chance of having a fairly functional and reasonably secure firewall to get yourself online and going until you learn a bit more". Combined with the deprecatory and in many instances just plain erroneous info in the only section of the Handbook that I've felt to try rewriting more or less from scratch - ie the ipfw part of the firewall chapter 31, which suggests some quite (to me) bizarre example rulesets after having dissed using the rc.firewall rulesets out of hand - we're not doing much good at advocating new users trying ipfw, which I think does it some injustice. Not intending here to deprecate pf or ipf in any way. Anyhow, this leaves us with two good reasons that 'client' and 'simple' sections ought to work effectively: secondly as an example illustrating good techniques - and I think your use of a table that the user can add entries to out of band for such as blackholing hosts/nets without having to reconfigure or restart the firewall IS good technique - but firstly as a basically functional and secure minimal firewall in and of itself. It's for both those reasons (and fixing an apparent oversight) that I've offered my unreviewed patch (which I'll do properly by PR if anyone says it's worth pursuing), after years of not being able to fathom supposedly usable firewall configuration for a client or small net, with or without NAT, that has never passed =ANY= ICMP traffic, not even to or from the hosts in one's own net! Am I missing something, thinking that matters, and that functioning path MTU discovery matters? > so here's a slightly improved diff: This may be a bit nitpicky, but how about keeping the firewall_simple_* varset naming consistent, maybe firewall_simple_blocktable or something? The 'workstation' vars have kinda busted that idea anyway, but still .. Also maybe rephrase mentioning the draft-manning-blah after the divert? HTH, Ian From jguojun at gmail.com Sat Nov 15 14:04:44 2008 From: jguojun at gmail.com (Jin Guojun[VFF]) Date: Sat Nov 15 14:04:50 2008 Subject: some ipfw filter does not function under Release 6.3 Message-ID: <491F413A.4020108@gmail.com> Below is set of ipfw rules, but it seems that not all rules are functioning properly. From rule 361 to first two of rule 567 are not blocking any traffic and not measuring any traffic. Is this bacuse tcp rule )330) can overwrite the ip rule? or this is a known issue in R-6.3? The second and third rules in rule set 567 seem working well. -Jin ---------------- ipfw rule sets --------- 00330 3108378 2700826874 allow tcp from any to any established 00361 0 0 deny ip from 203.83.248.93 to any 00361 0 0 deny ip from 72.30.142.215 to any 00567 0 0 deny ip from 193.200.241.171 to any 00567 0 0 deny ip from 221.192.199.36 to any 00567 3 180 deny ip from 118.153.18.186 to any 00567 3 180 deny ip from 203.78.214.180 to any 00567 0 0 deny ip from 118.219.232.123 to any 65500 220 20043 allow udp from any to any 65535 2 120 deny ip from any to any ------ traffic captured by tcpdump behind ipfw machine ----- 04:12:20.940095 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200229998:200229998(0) win 8192 04:12:21.204430 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200229999:200229999(0) win 0 04:31:16.262402 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200233658:200233658(0) win 8192 04:31:16.541868 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200233659:200233659(0) win 0 05:27:04.031434 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200244634:200244634(0) win 8192 05:27:04.303262 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200244635:200244635(0) win 0 05:28:18.099443 IP 221.192.199.36.3362 > 192.168.2.14.80: S 2422872529:2422872529(0) win 65535 05:28:18.352083 IP 221.192.199.36.3362 > 192.168.2.14.80: . ack 3968474717 win 65535 05:28:18.367745 IP 221.192.199.36.3362 > 192.168.2.14.80: P 0:205(205) ack 1 win 65535 05:28:18.621538 IP 221.192.199.36.3362 > 192.168.2.14.80: R 205:205(0) ack 473 win 0 From ertr1013 at student.uu.se Sat Nov 15 14:51:09 2008 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Sat Nov 15 14:51:29 2008 Subject: some ipfw filter does not function under Release 6.3 In-Reply-To: <491F413A.4020108@gmail.com> References: <491F413A.4020108@gmail.com> Message-ID: <20081115223556.GA45503@owl.midgard.homeip.net> On Sat, Nov 15, 2008 at 01:38:02PM -0800, Jin Guojun[VFF] wrote: > Below is set of ipfw rules, but it seems that not all rules are > functioning properly. > From rule 361 to first two of rule 567 are not blocking any traffic and > not measuring any traffic. > Is this bacuse tcp rule )330) can overwrite the ip rule? or this is a > known issue in R-6.3? In general the first matching rule is the one that is applied. In your case this means that if a packet matches your rule 330 then it will be allowed through, and the rules further down the list will not be considered. > > The second and third rules in rule set 567 seem working well. > > -Jin > > ---------------- ipfw rule sets --------- > 00330 3108378 2700826874 allow tcp from any to any established > 00361 0 0 deny ip from 203.83.248.93 to any > 00361 0 0 deny ip from 72.30.142.215 to any > 00567 0 0 deny ip from 193.200.241.171 to any > 00567 0 0 deny ip from 221.192.199.36 to any > 00567 3 180 deny ip from 118.153.18.186 to any > 00567 3 180 deny ip from 203.78.214.180 to any > 00567 0 0 deny ip from 118.219.232.123 to any > 65500 220 20043 allow udp from any to any > 65535 2 120 deny ip from any to any > > ------ traffic captured by tcpdump behind ipfw machine ----- > > 04:12:20.940095 IP 221.192.199.36.12200 > 192.168.2.14.80: S > 200229998:200229998(0) win 8192 > 04:12:21.204430 IP 221.192.199.36.12200 > 192.168.2.14.80: R > 200229999:200229999(0) win 0 > 04:31:16.262402 IP 221.192.199.36.12200 > 192.168.2.14.80: S > 200233658:200233658(0) win 8192 > 04:31:16.541868 IP 221.192.199.36.12200 > 192.168.2.14.80: R > 200233659:200233659(0) win 0 > 05:27:04.031434 IP 221.192.199.36.12200 > 192.168.2.14.80: S > 200244634:200244634(0) win 8192 > 05:27:04.303262 IP 221.192.199.36.12200 > 192.168.2.14.80: R > 200244635:200244635(0) win 0 > 05:28:18.099443 IP 221.192.199.36.3362 > 192.168.2.14.80: S > 2422872529:2422872529(0) win 65535 > 05:28:18.352083 IP 221.192.199.36.3362 > 192.168.2.14.80: . ack > 3968474717 win 65535 > 05:28:18.367745 IP 221.192.199.36.3362 > 192.168.2.14.80: P 0:205(205) > ack 1 win 65535 > 05:28:18.621538 IP 221.192.199.36.3362 > 192.168.2.14.80: R 205:205(0) > ack 473 win 0 > -- Erik Trulsson ertr1013@student.uu.se From jguojun at gmail.com Sat Nov 15 15:00:55 2008 From: jguojun at gmail.com (Jin Guojun[VFF]) Date: Sat Nov 15 15:01:01 2008 Subject: some ipfw filter does not function under Release 6.3 In-Reply-To: <20081115223556.GA45503@owl.midgard.homeip.net> References: <491F413A.4020108@gmail.com> <20081115223556.GA45503@owl.midgard.homeip.net> Message-ID: <491F54A0.9090702@gmail.com> But the rule 330 should only allow established TCP pass through. In other words, Sync should NOT allowed by rule 330, or I missed something for this rule? Erik Trulsson wrote: On Sat, Nov 15, 2008 at 01:38:02PM -0800, Jin Guojun[VFF] wrote: Below is set of ipfw rules, but it seems that not all rules are functioning properly. From rule 361 to first two of rule 567 are not blocking any traffic and not measuring any traffic. Is this bacuse tcp rule )330) can overwrite the ip rule? or this is a known issue in R-6.3? In general the first matching rule is the one that is applied. In your case this means that if a packet matches your rule 330 then it will be allowed through, and the rules further down the list will not be considered. The second and third rules in rule set 567 seem working well. -Jin ---------------- ipfw rule sets --------- 00330 3108378 2700826874 allow tcp from any to any established 00361 0 0 deny ip from 203.83.248.93 to any 00361 0 0 deny ip from 72.30.142.215 to any 00567 0 0 deny ip from 193.200.241.171 to any 00567 0 0 deny ip from 221.192.199.36 to any 00567 3 180 deny ip from 118.153.18.186 to any 00567 3 180 deny ip from 203.78.214.180 to any 00567 0 0 deny ip from 118.219.232.123 to any 65500 220 20043 allow udp from any to any 65535 2 120 deny ip from any to any ------ traffic captured by tcpdump behind ipfw machine ----- 04:12:20.940095 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200229998:200229998(0) win 8192 04:12:21.204430 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200229999:200229999(0) win 0 04:31:16.262402 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200233658:200233658(0) win 8192 04:31:16.541868 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200233659:200233659(0) win 0 05:27:04.031434 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200244634:200244634(0) win 8192 05:27:04.303262 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200244635:200244635(0) win 0 05:28:18.099443 IP 221.192.199.36.3362 > 192.168.2.14.80: S 2422872529:2422872529(0) win 65535 05:28:18.352083 IP 221.192.199.36.3362 > 192.168.2.14.80: . ack 3968474717 win 65535 05:28:18.367745 IP 221.192.199.36.3362 > 192.168.2.14.80: P 0:205(205) ack 1 win 65535 05:28:18.621538 IP 221.192.199.36.3362 > 192.168.2.14.80: R 205:205(0) ack 473 win 0 From jguojun at gmail.com Sat Nov 15 16:08:13 2008 From: jguojun at gmail.com (Jin Guojun[VFF]) Date: Sat Nov 15 16:08:25 2008 Subject: some ipfw filter does not function under Release 6.3 In-Reply-To: <491F54A0.9090702@gmail.com> References: <491F413A.4020108@gmail.com> <20081115223556.GA45503@owl.midgard.homeip.net> <491F54A0.9090702@gmail.com> Message-ID: <491F6466.40309@gmail.com> I think this is a bug in ipfw because after change the rule order, the problem persists: 00566 26 3090 deny ip from 221.192.199.36 to any 65330 2018 983473 allow tcp from any to any established 65535 0 0 deny ip from any to any 15:47:21.238720 IP 221.192.199.36.4469 > 192.168.2.14.80: S 3191960249:3191960249(0) win 65535 15:47:21.238768 IP 192.168.2.14.80 > 221.192.199.36.4469: S 2102254306:2102254306(0) ack 3191960250 win 65535 15:47:21.483754 IP 221.192.199.36.4469 > 192.168.2.14.80: . ack 1 win 65535 15:47:21.499489 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) ack 1 win 65535 15:47:24.238570 IP 192.168.2.14.80 > 221.192.199.36.4469: S 2102254306:2102254306(0) ack 3191960250 win 65535 15:47:24.482113 IP 221.192.199.36.4469 > 192.168.2.14.80: . ack 1 win 65535 15:47:24.498613 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) ack 1 win 65535 15:47:30.238574 IP 192.168.2.14.80 > 221.192.199.36.4469: S 2102254306:2102254306(0) ack 3191960250 win 65535 15:47:30.482746 IP 221.192.199.36.4469 > 192.168.2.14.80: . ack 1 win 65535 15:47:30.513193 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) ack 1 win 65535 15:47:42.238577 IP 192.168.2.14.80 > 221.192.199.36.4469: S 2102254306:2102254306(0) ack 3191960250 win 65535 15:47:42.435040 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) ack 1 win 65535 15:47:42.466055 IP 221.192.199.36.4469 > 192.168.2.14.80: . ack 1 win 65535 15:47:54.466599 IP 221.192.199.36.4469 > 192.168.2.14.80: P 1:206(205) ack 1 win 65535 15:47:59.703272 IP 221.192.199.36.4469 > 192.168.2.14.80: R 206:206(0) ack 1 win 0 Jin Guojun[VFF] wrote: But the rule 330 should only allow established TCP pass through. In other words, Sync should NOT allowed by rule 330, or I missed something for this rule? Erik Trulsson wrote: On Sat, Nov 15, 2008 at 01:38:02PM -0800, Jin Guojun[VFF] wrote: Below is set of ipfw rules, but it seems that not all rules are functioning properly. From rule 361 to first two of rule 567 are not blocking any traffic and not measuring any traffic. Is this bacuse tcp rule )330) can overwrite the ip rule? or this is a known issue in R-6.3? In general the first matching rule is the one that is applied. In your case this means that if a packet matches your rule 330 then it will be allowed through, and the rules further down the list will not be considered. The second and third rules in rule set 567 seem working well. -Jin ---------------- ipfw rule sets --------- 00330 3108378 2700826874 allow tcp from any to any established 00361 0 0 deny ip from 203.83.248.93 to any 00361 0 0 deny ip from 72.30.142.215 to any 00567 0 0 deny ip from 193.200.241.171 to any 00567 0 0 deny ip from 221.192.199.36 to any 00567 3 180 deny ip from 118.153.18.186 to any 00567 3 180 deny ip from 203.78.214.180 to any 00567 0 0 deny ip from 118.219.232.123 to any 65500 220 20043 allow udp from any to any 65535 2 120 deny ip from any to any ------ traffic captured by tcpdump behind ipfw machine ----- 04:12:20.940095 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200229998:200229998(0) win 8192 04:12:21.204430 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200229999:200229999(0) win 0 04:31:16.262402 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200233658:200233658(0) win 8192 04:31:16.541868 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200233659:200233659(0) win 0 05:27:04.031434 IP 221.192.199.36.12200 > 192.168.2.14.80: S 200244634:200244634(0) win 8192 05:27:04.303262 IP 221.192.199.36.12200 > 192.168.2.14.80: R 200244635:200244635(0) win 0 05:28:18.099443 IP 221.192.199.36.3362 > 192.168.2.14.80: S 2422872529:2422872529(0) win 65535 05:28:18.352083 IP 221.192.199.36.3362 > 192.168.2.14.80: . ack 3968474717 win 65535 05:28:18.367745 IP 221.192.199.36.3362 > 192.168.2.14.80: P 0:205(205) ack 1 win 65535 05:28:18.621538 IP 221.192.199.36.3362 > 192.168.2.14.80: R 205:205(0) ack 473 win 0 From linimon at FreeBSD.org Sun Nov 16 00:02:46 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Nov 16 00:02:53 2008 Subject: kern/128902: [ipfw] ipfw allow tcp from any to any established allow Sync pass through Message-ID: <200811160802.mAG82kXE026629@freefall.freebsd.org> Old Synopsis: ipfw allow tcp from any to any established allow Sync pass through New Synopsis: [ipfw] ipfw allow tcp from any to any established allow Sync pass through Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 16 08:02:19 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=128902 From jguojun at gmail.com Sun Nov 16 13:21:22 2008 From: jguojun at gmail.com (Jin Guojun[VFF]) Date: Sun Nov 16 13:21:33 2008 Subject: some ipfw filter does not function under Release 6.3 In-Reply-To: <20081116224655.J70117@sola.nimnet.asn.au> References: <491F413A.4020108@gmail.com> <20081115223556.GA45503@owl.midgard.homeip.net> <491F54A0.9090702@gmail.com> <491F6466.40309@gmail.com> <20081116224655.J70117@sola.nimnet.asn.au> Message-ID: <49208ECC.5020008@gmail.com> Ian Smith wrote: >On Sat, 15 Nov 2008, Jin Guojun[VFF] wrote: > > > I think this is a bug in ipfw because after change the rule order, the > > problem persists: > > 00566 26 3090 deny ip from 221.192.199.36 to any > > 65330 2018 983473 allow tcp from any to any established > > 65535 0 0 deny ip from any to any > >Are you saying that the packets shown below from 221.192.199.36 arrived >=after= you added rule 566, which denys all traffic from that address? > >Are you showing us your entire ruleset; it is just those three rules? > >Is the tcpdump shown running on the same box as ipfw, or another box? > >If another box, how is it connected through the firewall, to the net? > >Which machine performs NAT for your network? None of this is obvious. > >Please show output of 'ifconfig' and 'netstat -rn' on the ipfw box? > > Let's clear this little bit. Above rule order actually worked after machine is rebooted. I do not know whay it was not working when changed rule 65330 from 00330. This may be another bug. But again, after rebooting the machine, this rule order works. This demonstrates that rule order 00330 did not block the Sync packet as it supposed to do. You also mentioned and confirmed it should do in this way below, ---------- working order --------- 00566 26 3090 deny ip from 221.192.199.36 to any 65330 2018 983473 allow tcp from any to any established 65535 0 0 deny ip from any to any ---------- Non working order --------- 00330 2018 983473 allow tcp from any to any established 00566 0 0 deny ip from 221.192.199.36 to any 65535 0 0 deny ip from any to any -------------------------------------------------- > > In general the first matching rule is the one that is applied. > > In your case this means that if a packet matches your rule 330 then > > it will be allowed through, and the rules further down the list will > > not be considered. > >Erik is right; you'll have to deny unwanted traffic before allowing the >established traffic. 'established' here really means 'not setup', ie >not SYN-only packets; ipfw doesn't track TCP sessions, the stack does. > > We see this (Sync only packet) passed through, so this is the problem. Because once Sync packet is passed through, the receiver will respond Sync/ACK, then attacker knows the machine is in service. >People can send bogus established packets, and though they won't have a >socket to connect to, they're still inbound traffic you have to receive >to even block, which can consume bandwidth and perhaps money. > > We saw this too, from 221.192.199.36, but I did not complain for this. Becasue we do not bother since receiving machine will not respond it. Attacker also sends bogus Reset packets, and the FreeBSD ignores it too. So, this is not the problem. >Sometimes these are a result of someone sending TCP setup packets to >some other host, with the source address forged as yours .. you get the >SYN+ACK packets, which do pass as established through ipfw. It's >possible that the host you see as attacking you may itself be victim .. > >Yes, did I read your PR .. no sign of that host here so far, so it might >just be scanning networks a bit closer to home: > >http://www.iptools.com/dnstools.php?tool=ipwhois&user_data=221.192.199.36&submit=Go > > It does not matter if this is a fake machine or victim machine, ipfw should always block it as instructed to do so. We cannot give it mercy and let it pass through becasue it is a victim. Otherwise, we will be the victim :-) That is why I filed PR for problem for rule order 00330-00566-65535. I did not say rule order 00566-65330-65535 is the problem in the PR. Hopefully, this makes clear. BTW, the ipfw machine is the gateway (between WAN-LAN). Rest machines are behind it on LAN. From jguojun at gmail.com Sun Nov 16 17:19:03 2008 From: jguojun at gmail.com (Jin Guojun[VFF]) Date: Sun Nov 16 17:19:09 2008 Subject: some ipfw filter does not function under Release 6.3 In-Reply-To: <20081116224655.J70117@sola.nimnet.asn.au> References: <491F413A.4020108@gmail.com> <20081115223556.GA45503@owl.midgard.homeip.net> <491F54A0.9090702@gmail.com> <491F6466.40309@gmail.com> <20081116224655.J70117@sola.nimnet.asn.au> Message-ID: <4920C685.1050004@gmail.com> Ian Smith wrote: >On Sat, 15 Nov 2008, Jin Guojun[VFF] wrote: > > > I think this is a bug in ipfw because after change the rule order, the > > problem persists: > > 00566 26 3090 deny ip from 221.192.199.36 to any > > 65330 2018 983473 allow tcp from any to any established > > 65535 0 0 deny ip from any to any > >Are you saying that the packets shown below from 221.192.199.36 arrived >=after= you added rule 566, which denys all traffic from that address? > >Are you showing us your entire ruleset; it is just those three rules? > >Is the tcpdump shown running on the same box as ipfw, or another box? > >If another box, how is it connected through the firewall, to the net? > >Which machine performs NAT for your network? None of this is obvious. > >Please show output of 'ifconfig' and 'netstat -rn' on the ipfw box? > > > I have found the problem due to the NIC naming change after motherboard upgrading. The em0 was LAN port, but now it is WAN port. So, the following rule caused Sync coming in: 00123 12 528 allow tcp from any to 192.168.0.0/16 via em0 setup This is my configuration fault, and we can close PR kern/128902. Thanks, -Jin From linimon at FreeBSD.org Sun Nov 16 18:46:23 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Nov 16 18:46:30 2008 Subject: kern/128902: [ipfw] ipfw allow tcp from any to any established allow Sync pass through Message-ID: <200811170246.mAH2kNq4070006@freefall.freebsd.org> Synopsis: [ipfw] ipfw allow tcp from any to any established allow Sync pass through State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Mon Nov 17 02:46:08 UTC 2008 State-Changed-Why: Closed at submitter's request. http://www.freebsd.org/cgi/query-pr.cgi?pr=128902 From smithi at nimnet.asn.au Sun Nov 16 19:06:33 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Nov 16 19:06:40 2008 Subject: some ipfw filter does not function under Release 6.3 In-Reply-To: <4920C685.1050004@gmail.com> References: <491F413A.4020108@gmail.com> <20081115223556.GA45503@owl.midgard.homeip.net> <491F54A0.9090702@gmail.com> <491F6466.40309@gmail.com> <20081116224655.J70117@sola.nimnet.asn.au> <4920C685.1050004@gmail.com> Message-ID: <20081117134532.S70117@sola.nimnet.asn.au> On Sun, 16 Nov 2008, Jin Guojun[VFF] wrote: > Ian Smith wrote: > > > On Sat, 15 Nov 2008, Jin Guojun[VFF] wrote: > > > > > I think this is a bug in ipfw because after change the rule order, the > > > problem persists: > > > 00566 26 3090 deny ip from 221.192.199.36 to any > > > 65330 2018 983473 allow tcp from any to any established > > > 65535 0 0 deny ip from any to any > > > > Are you saying that the packets shown below from 221.192.199.36 arrived > > =after= you added rule 566, which denys all traffic from that address? > > > > Are you showing us your entire ruleset; it is just those three rules? > > > > Is the tcpdump shown running on the same box as ipfw, or another box? > > If another box, how is it connected through the firewall, to the net? > > > > Which machine performs NAT for your network? None of this is obvious. > > > > Please show output of 'ifconfig' and 'netstat -rn' on the ipfw box? > I have found the problem due to the NIC naming change after motherboard > upgrading. > The em0 was LAN port, but now it is WAN port. So, the following rule caused > Sync coming in: > > 00123 12 528 allow tcp from any to 192.168.0.0/16 via em0 setup Ahah! > This is my configuration fault, and we can close PR kern/128902. > > Thanks, > -Jin Glad you found it so soon, Jin; that was one very short-lived PR :) cheers, Ian From jguojun at gmail.com Sun Nov 16 20:36:34 2008 From: jguojun at gmail.com (Jin Guojun[VFF]) Date: Sun Nov 16 20:36:46 2008 Subject: some ipfw filter does not function under Release 6.3 In-Reply-To: <20081117134532.S70117@sola.nimnet.asn.au> References: <491F413A.4020108@gmail.com> <20081115223556.GA45503@owl.midgard.homeip.net> <491F54A0.9090702@gmail.com> <491F6466.40309@gmail.com> <20081116224655.J70117@sola.nimnet.asn.au> <4920C685.1050004@gmail.com> <20081117134532.S70117@sola.nimnet.asn.au> Message-ID: <4920F4CC.2020501@gmail.com> Ian Smith wrote: >On Sun, 16 Nov 2008, Jin Guojun[VFF] wrote: > > Ian Smith wrote: > > > > > On Sat, 15 Nov 2008, Jin Guojun[VFF] wrote: > > > > > > > I think this is a bug in ipfw because after change the rule order, the > > > > problem persists: > > > > 00566 26 3090 deny ip from 221.192.199.36 to any > > > > 65330 2018 983473 allow tcp from any to any established > > > > 65535 0 0 deny ip from any to any > > > >.... snapped > > > I have found the problem due to the NIC naming change after motherboard > > upgrading. > > The em0 was LAN port, but now it is WAN port. So, the following rule caused > > Sync coming in: > > > > 00123 12 528 allow tcp from any to 192.168.0.0/16 via em0 setup > >Ahah! > > > This is my configuration fault, and we can close PR kern/128902. > > > > Thanks, > > -Jin > >Glad you found it so soon, Jin; that was one very short-lived PR :) > > This is kind hard one to catch since this machine was tested and working before. Traced many machines with R-6.1 and R-6.2 around country and found no problem. The recent change to this machine is a AMD to a P4 motherboard swapping for better memory bandwidth, but overlooked the NIC names changed. Now we had historical information for what could cause such failure. -Jin From bugmaster at FreeBSD.org Mon Nov 17 03:06:52 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 17 03:08:18 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200811171106.mAHB6pmi082553@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 48 problems total. From security at jim-liesl.org Thu Nov 20 20:24:59 2008 From: security at jim-liesl.org (security) Date: Thu Nov 20 20:25:05 2008 Subject: ipfw/dummynet question Message-ID: <492631D7.30909@jim-liesl.org> context is 7.1-beta2 I'm using a FreeBSD box as a router and IPFW/dummynet to simulate 3 WAN connections. The three networks are actually on the same lan, but have aliased ip's on the router's NIC (router on a stick). I've set up bi-directional pipes for each "net" that enforce various impairments. What I'm trying to do is have all traffic to or from "net-a" simulate a 30Mbit link, "net-b" a 20Mbit, and "net-c" a 10Mbit one. Traffic coming from elsewhere would not be touched until it was outbound for one of the 3 nets, and like wise, traffic coming from the 3 nets and going elsewhere would only be touched coming in. Traffic who's src and dst don't match at all would fall through. An example would be traffic from "net-a" going to "net-c" gets passed into the router like it's on a 30Mbit link, but heads out (after routing) like it's on a 10 Mbit link Question: Am I on the right path or have I made some stupid assumption(s)? I realize I have a few extra rules that could be optimized out, but this is probably good for the sake of readability. Another question, is each ip flow treated like it has it's own dedicated bw, or do all flows that match a pipe share the b/w ? thx jim (assume one_pass is set) ${fwcmd} add 10 skipto 100 ip from any to any in ${fwcmd} add 20 skipto 500 ip from any to any out ${fwcmd} add 100 pipe 1 ip from net-a to any ${fwcmd} add 200 pipe 2 ip from net-b to any ${fwcmd} add 300 pipe 3 ip from net-c to any ${fwcmd} add 400 skipto 65535 ip from any to any ${fwcmd} pipe 1 config bw 30Mbit/s ${fwcmd} pipe 2 config bw 20Mbit/s ${fwcmd} pipe 3 config bw 10Mbit/s ${fwcmd} add 500 pipe 4 ip from any to net-a ${fwcmd} add 600 pipe 5 ip from any to net-b ${fwcmd} add 700 pipe 6 ip from any to net-c ${fwcmd} pipe 4 config bw 30Mbit/s ${fwcmd} pipe 5 config bw 20Mbit/s ${fwcmd} pipe 6 config bw 10Mbit/s ${fwcmd} add 1000 skipto 65535 ip from any to any From linimon at FreeBSD.org Thu Nov 20 23:42:01 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Nov 20 23:42:07 2008 Subject: kern/129036: [ipfw] 'ipfw fwd' does not change outgoing interface name Message-ID: <200811210742.mAL7g0GC006064@freefall.freebsd.org> Synopsis: [ipfw] 'ipfw fwd' does not change outgoing interface name Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Fri Nov 21 07:41:39 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129036 From dcharan at atcorp.com Fri Nov 21 06:53:38 2008 From: dcharan at atcorp.com (Deborah Charan) Date: Fri Nov 21 06:53:45 2008 Subject: ipfw fwd with a bridge freebsd box Message-ID: <4926C4A0.1090006@atcorp.com> I have seen many posts from Kelly and Luigi about a patch to make fwd packets work on bridged freebsd boxes. But, nothing since 2003/2004 and 4.x. Is there any patch for 5.3? Thanks. From rik at inse.ru Fri Nov 21 08:51:30 2008 From: rik at inse.ru (Roman Kurakin) Date: Fri Nov 21 08:51:37 2008 Subject: ipfw fwd with a bridge freebsd box In-Reply-To: <4926C4A0.1090006@atcorp.com> References: <4926C4A0.1090006@atcorp.com> Message-ID: <4926E708.5050709@inse.ru> Deborah Charan: > I have seen many posts from Kelly and Luigi about a patch to make fwd > packets work on bridged freebsd boxes. But, nothing since 2003/2004 > and 4.x. Is there any patch for 5.3? I can't answer your question, but why do you need patch for such old version, 6.x and 7.x a stable enough and much better, except you are using some really old hardware. rik > > Thanks. > _______________________________________________ > 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" From linimon at FreeBSD.org Sun Nov 23 10:03:00 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Nov 23 10:03:06 2008 Subject: kern/129093: [ipfw] ipfw nat must not drop packets Message-ID: <200811231802.mANI2xsD011351@freefall.freebsd.org> Old Synopsis: ipfw nat must not drop packets New Synopsis: [ipfw] ipfw nat must not drop packets Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 23 18:02:44 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129093 From linimon at FreeBSD.org Sun Nov 23 15:42:24 2008 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Nov 23 15:42:35 2008 Subject: kern/129103: [ipfw] IPFW check state does not work =( Message-ID: <200811232342.mANNgOnr069400@freefall.freebsd.org> Old Synopsis: IPFW check state does not work =( New Synopsis: [ipfw] IPFW check state does not work =( Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 23 23:42:11 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129103 From bugmaster at FreeBSD.org Mon Nov 24 03:07:15 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Nov 24 03:08:17 2008 Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org Message-ID: <200811241107.mAOB7EeC019931@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet]: 6.3-RELEASE-p1 page fault in dummynet (cor o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 51 problems total. From smithi at nimnet.asn.au Mon Nov 24 05:21:26 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Nov 24 05:23:50 2008 Subject: kern/129103: [ipfw] IPFW check state does not work =( In-Reply-To: <200811232342.mANNgOnr069400@freefall.freebsd.org> References: <200811232342.mANNgOnr069400@freefall.freebsd.org> Message-ID: <20081124203046.I43853@sola.nimnet.asn.au> On Sun, 23 Nov 2008, linimon@freebsd.org wrote: > Old Synopsis: IPFW check state does not work =( > New Synopsis: [ipfw] IPFW check state does not work =( > > Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw > Responsible-Changed-By: linimon > Responsible-Changed-When: Sun Nov 23 23:42:11 UTC 2008 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=129103 Eugen, I'll have a go; worst that can happen is I get it all wrong :) Last things first: a check-state rule NEVER counts any packets; the packet/byte counts are attributed to the triggering keep-state rule, which I think explains the counts you show. The prob 0.5 split makes it a bit harder to see what's happening here, but I'll quote the relevant: > 00001 0 0 check-state As expected. It would be helpful to put another like rule 2 *before* this check-state, showing the total number of icmp packets via ng0, or perhaps even two, one for 'in recv ngo' and one for 'out xmit ng0'. > 00002 6 360 count log icmp from any to any via ng0 This only counts icmp that has not yet been attributed to one of the check-state rules below, ie original, trigger packets for a flow; the response packets in a flow are counted by the keep-state rule (and are shown below in your expired dynamic rule counts) > 00003 5 300 prob 0.500000 skipto 6 log icmp from any to any via ng0 So 5 packets did the skipto 6. Unclear how many failed the prob test, but perhaps 5 or 6 fell through; we don't have the total count .. > 00004 8 480 skipto 5 log icmp from any to any via ng0 keep-state .. however, this 8 count includes some responses to the already established state - that you apparently expected to see in the check-state count. > 00005 3 180 skipto 10 log icmp from any to any via ng0 I'm not sure why this shows only 3 packets though, perhaps because some of the keep-state response packets by now are going out via ng1? > 00006 3 180 skipto 7 log icmp from any to any via ng0 keep-state > 00007 3 180 count log icmp from any to any via ng0 > 00010 6 360 count log icmp from any to any via ng0 That seems to tally, though dynamic rule 6 shows 2 (plus 1 trigger pkt?) > 00099 47 2924 nat 1 ip from any to any via ng0 [..] > ## Dynamic rules (2): > 00004 7 420 (0s) STATE icmp 192.168.9.4 0 <-> 213.180.204.8 0 > 00006 2 120 (0s) STATE icmp 213.180.204.8 0 <-> 91.124.239.145 0 This seems to indicate a total of 9 packets passed due to kept state, so perhaps there were 11 icmp packets in total, 6 out and 5 responses (^C)? > Why 5 packets for rule 3 and 8 packets for rule 4? I'm not sure, but there may be another issue here. I'll tail-quote the first of your security logs below, which seem, on a quick check, to add up to the packet counts for each rule, however it's worth noting the packets logged as being via ng1 (presumably your inside, NAT interface?) Use of 'via' can be a bit misleading. On inbound packets (ie from ip_input) only the receive interface can be tested before routing has occurred, so 'via ng0' shows just those packets. However on outbound packets, 'via iface' applies to packets either received on *or* being transmitted on that interface, which I think is what's happening with those that are logged showing ng1 .. remembering these are shown before NAT translation. Happy to accept any correction on any of this .. Regarding the other (kern/129093: [ipfw] ipfw nat must not drop packets) I can't say anything about what I haven't used, but what's your value of net.inet.ip.fw.one_pass ? cheers, Ian ===== quote from PR, not indented: cat security Nov 23 23:18:39 home kernel: ipfw: 2 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:39 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:39 home kernel: ipfw: 5 SkipTo 10 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:39 home kernel: ipfw: 10 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:39 home kernel: ipfw: 2 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 3 SkipTo 6 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 7 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 10 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:39 home kernel: ipfw: 4 SkipTo 5 ICMP:0.0 213.180.204.8 192.168.9.4 out via ng1 Nov 23 23:18:40 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 in via ng1 Nov 23 23:18:40 home kernel: ipfw: 2 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 3 SkipTo 6 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 5 SkipTo 10 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 10 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:40 home kernel: ipfw: 2 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 3 SkipTo 6 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 7 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 10 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:40 home kernel: ipfw: 4 SkipTo 5 ICMP:0.0 213.180.204.8 192.168.9.4 out via ng1 Nov 23 23:18:41 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 in via ng1 Nov 23 23:18:41 home kernel: ipfw: 2 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:41 home kernel: ipfw: 3 SkipTo 6 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:41 home kernel: ipfw: 4 SkipTo 5 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:41 home kernel: ipfw: 5 SkipTo 10 ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:41 home kernel: ipfw: 10 Count ICMP:8.0 192.168.9.4 213.180.204.8 out via ng0 Nov 23 23:18:42 home kernel: ipfw: 2 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 3 SkipTo 6 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 7 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 10 Count ICMP:0.0 213.180.204.8 91.124.239.145 in via ng0 Nov 23 23:18:42 home kernel: ipfw: 4 SkipTo 5 ICMP:0.0 213.180.204.8 192.168.9.4 out via ng1 Why in log do I see trafic for ng1 interface while rule 1 does not invoked? From kes-kes at yandex.ru Mon Nov 24 13:11:37 2008 From: kes-kes at yandex.ru (KES) Date: Mon Nov 24 13:11:46 2008 Subject: kern/129103: [ipfw] IPFW check state does not work =( In-Reply-To: <20081124203046.I43853@sola.nimnet.asn.au> References: <200811232342.mANNgOnr069400@freefall.freebsd.org> <20081124203046.I43853@sola.nimnet.asn.au> Message-ID: <1517824.20081124225602@yandex.ru> sorry, I miss some explanation Before beginngin tests I ipfw zero : > /var/log/security then for user on ng1 I do: ping -n 3 I.N.E.T > 00002 6 360 count log icmp from any to any via ng0 here I count all packets going through ng0 3 in + 3 out, all is ok here > 00003 5 300 prob 0.500000 skipto 6 log icmp from any to any via ng0 I want to split traffic. Now here I just study how it is done. Actually I want to fwd packets through differeng ISP but send packet to same ISP if connection is established. So traffic will flow over 4,5 or 6,7, 00004 8 480 skipto 5 log icmp from any to any via ng0 keep-state 00005 3 180 skipto 10 log icmp from any to any via ng0 00006 3 180 skipto 7 log icmp from any to any via ng0 keep-state 00007 3 180 count log icmp from any to any via ng0 expected results for rule 4 is 3 packets. Why it is 8 I do not know > 00010 6 360 count log icmp from any to any via ng0 here I count all packets going through ng0 again. As you see it is 6. All is ok > 00099 47 2924 nat 1 ip from any to any via ng0 just natting, nat all traffic, so counter is so big > 00004 7 420 (0s) STATE icmp 192.168.9.4 0 <-> 213.180.204.8 0 > 00006 2 120 (0s) STATE icmp 213.180.204.8 0 <-> 91.124.239.145 0 This is very strange. Here I expect 3 for first and second rule but why here 7 and 2 packets?? that is mistery (( From eugen at kuzbass.ru Tue Nov 25 06:22:20 2008 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Nov 25 06:26:22 2008 Subject: m_tag_find() overhead Message-ID: <20081125134239.GA17138@svzserv.kemerovo.su> Hi! I wonder if one more call to m_tag_find() for every outgoing packet would be expensive. For many years conventional way to implement PBR was: use 'ipfw fwd'. Currently 'ipfw add fwd ... in' marks a packet with PACKET_TAG_IPFORWARD. Such forwarding changes packet's outgoing interface generally but none in the kernel reflect this in packet's metadata and packets are passed by ip_output() to PFIL hooks with wrong outgoing interface name ( details and How-To-Repeat may be found here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/129036 ) I've patched src/sys/netinet/ip_output.c to fix this problem by extra check for PACKET_TAG_IPFORWARD and update of route if necessary. This adds a call to m_tag_find() for every outgoing packet if packet filtering is enabled and kernel has options IPFIREWALL_FORWARD. Please review. It works for my test lab but I'm not sure if that's correct: should a call to rtalloc_ign() be accomplished with some resource freeing call? And what's the meaning of RTF_CLONING second argument of rtalloc_ign? --- ip_output.c.orig 2008-11-25 14:21:26.000000000 +0700 +++ ip_output.c 2008-11-25 18:29:32.000000000 +0700 @@ -195,6 +195,20 @@ ro->ro_rt = (struct rtentry *)0; } #ifdef IPFIREWALL_FORWARD + /* + * Check if packet has changed next-hop in ip_input() + * If so, update route so pfil hooks get it right + */ + if ((inet_pfil_hook.ph_busy_count != -1) && + (fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL))) { + bzero(&iproute, sizeof(iproute)); + ro = &iproute; + bcopy((fwd_tag+1), &ro->ro_dst, sizeof(struct sockaddr_in)); + m_tag_delete(m, fwd_tag); + rtalloc_ign(ro, RTF_CLONING); + dst = (struct sockaddr_in *)&ro->ro_dst; + } + if (ro->ro_rt == NULL && fwd_tag == NULL) { #else if (ro->ro_rt == NULL) { Eugene Grosbein From bogdan_inedit at yahoo.com Wed Nov 26 01:14:24 2008 From: bogdan_inedit at yahoo.com (bogdan oprea) Date: Wed Nov 26 01:14:30 2008 Subject: dummynet + ack http Message-ID: <623098.39499.qm@web50306.mail.re2.yahoo.com> i was wondering if the following scenario is possible: i am running a small isp with upto 20Mbps download speed and 10Mbps upload speed i want to prioritize http traffic (and dns, ping, possibly voip and some games) over other traffic (p2p etc) i know that this is done with queues but i don't know the right weights for the queues 3 queues i think should be enough: queue1-ack http, queue2-ack-other, queue3-rest of the traffic so if anyone knows what are the weights of the queues or a ipfw.rules example please help me From smithi at nimnet.asn.au Thu Nov 27 22:58:06 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Nov 27 22:58:14 2008 Subject: kern/129103: [ipfw] IPFW check state does not work =( In-Reply-To: <1638065040.20081125011317@yandex.ru> References: <200811232342.mANNgOnr069400@freefall.freebsd.org> <20081124203046.I43853@sola.nimnet.asn.au> <1638065040.20081125011317@yandex.ru> Message-ID: <20081128161236.P92549@sola.nimnet.asn.au> Kes, your message didn't make it to the list. Probably because of the 650KB attached diagram :) Big stuff is better put up as an URL to a web site. On Tue, 25 Nov 2008, KES wrote: > #ipfw -ed show > 00001 0 0 check-state log > 00002 2 120 count log icmp from any to any via ng0 > 00003 2 120 prob 0.500000 skipto 6 log icmp from any to any via ng0 > 00004 0 0 skipto 5 log icmp from any to any via ng0 keep-state > 00005 0 0 skipto 10 log icmp from any to any via ng0 > 00006 11 660 skipto 7 log icmp from any to any via ng0 keep-state > 00007 6 360 count log icmp from any to any via ng0 > 00010 6 360 count log icmp from any to any via ng0 > 00049 726 132682 nat 1 ip from any to any via ng0 > 00050 9088 2196349 allow ip from any to any > 00050 0 0 nat 1 ip from any to any via ng0 > 00100 0 0 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 65535 0 0 deny ip from any to any > ## Dynamic rules (2): > 00006 7 420 (1s) STATE icmp 192.168.9.4 0 <-> 213.180.193.123 0 > 00006 2 120 (1s) STATE icmp 213.180.193.123 0 <-> 92.113.76.40 0 Ok, this one is easier because no packets took the 4/5 prob split. Note 2 separate state entries because of the different address pairs. > Nov 24 23:54:25 home kernel: ipfw: 2 Count ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 > Nov 24 23:54:25 home kernel: ipfw: 3 SkipTo 6 ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 > Nov 24 23:54:25 home kernel: ipfw: 6 SkipTo 7 ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 > Nov 24 23:54:25 home kernel: ipfw: 7 Count ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 > Nov 24 23:54:25 home kernel: ipfw: 10 Count ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 1st packet. At 6 it creates state 192.168.9.4 <--> 213.180.193.123 > Nov 24 23:54:25 home kernel: ipfw: 2 Count ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 > Nov 24 23:54:25 home kernel: ipfw: 3 SkipTo 6 ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 > Nov 24 23:54:25 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 > Nov 24 23:54:25 home kernel: ipfw: 7 Count ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 > Nov 24 23:54:25 home kernel: ipfw: 10 Count ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 1st response packet .. doesn't match the above state as it's a different address, so it creates state between 213.180.193.123 <--> 92.113.76.40 .. because you've put your nat rule in the wrong place, it should go before any of this, then all state would be between 213... and 92... Note both of the above count at rule 2, because neither match existing state. These two are also the last packets that do match rule 2. > Nov 24 23:54:25 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.193.123 192.168.9.4 out via ng1 So now, after NAT, this matches the first state above. It still matches rules 'via ng0' because that was its source interface on keep-state. It doesn't show in rule 2 because it jumps to rule 6 at the check-state. > Nov 24 23:54:26 home kernel: ipfw: 6 SkipTo 7 ICMP:8.0 192.168.9.4 213.180.193.123 in via ng1 Second ping. Despite coming in via ng1, it also matches the first state flow above, but doesn't match 7 or 10 (wrong interface) > Nov 24 23:54:26 home kernel: ipfw: 6 SkipTo 7 ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 Another packet out, matches established state for first rule 6 .. > Nov 24 23:54:26 home kernel: ipfw: 7 Count ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 > Nov 24 23:54:26 home kernel: ipfw: 10 Count ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 .. and also matches 7 and 10, being via ng0. > Nov 24 23:54:26 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 > Nov 24 23:54:26 home kernel: ipfw: 7 Count ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 > Nov 24 23:54:26 home kernel: ipfw: 10 Count ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 Return packet matches second state entry on rule 6, from check-state. > Nov 24 23:54:26 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.193.123 192.168.9.4 out via ng1 Same packet matching first state entry on rule 6, despite interface ng1, after NAT. > Nov 24 23:54:27 home kernel: ipfw: 6 SkipTo 7 ICMP:8.0 192.168.9.4 213.180.193.123 in via ng1 Third ping packet from ng1, also matches the first of rule 6 states, but not counted by 7 or 10 because of via different interface. > Nov 24 23:54:27 home kernel: ipfw: 6 SkipTo 7 ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 Same packet going out, matches second of the rule 6 states .. > Nov 24 23:54:27 home kernel: ipfw: 7 Count ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 > Nov 24 23:54:27 home kernel: ipfw: 10 Count ICMP:8.0 192.168.9.4 213.180.193.123 out via ng0 .. which also gets counted by 7 and 10, being out via ng0. > Nov 24 23:54:27 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 Return packet, matches second rule 6 state .. > Nov 24 23:54:27 home kernel: ipfw: 7 Count ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 > Nov 24 23:54:27 home kernel: ipfw: 10 Count ICMP:0.0 213.180.193.123 92.113.76.40 in via ng0 .. and 7 and 10. > Nov 24 23:54:27 home kernel: ipfw: 6 SkipTo 7 ICMP:0.0 213.180.193.123 192.168.9.4 out via ng1 Third reply being delivered, after NAT, to ng1 because it matches state. That's it. If you'd had separate rules to count icmp via ng1 you'd have seen them all (or if you'd specifed ng* rather than ng0) ======= > Seems all is ok, except > 00001 0 0 check-state log > Once dynamic rule is matched, check-state counter must be increased. No use saying 'must', when that's simply not how it works; check-state never shows any counts. You've filed a PR on the basis of how you wish it might work, and I believe I've shown above that it's working as advertised. I suggest you should now close this PR. ======= > Also it seems when keep-state create new dynamic rule, it must > increment it. Because of when rule body is matched, keep-state create > dynamic rule and then packet flow through this dynamic rule, counter > for dynamic rule is incremented, packet for parent rule is > incremented. and you do not loose counters. Again, that's just not how it works. Dynamic rule counts show traffic due to established state; they don't include the original packet that created the state. Sometimes you'll see dynamic rule counts of 0, where a packet went out (say) and setup state, but no response came back. In short, there's no use trying to use statistics from keep-state rules for accounting. Use separate stateless rules, BEFORE any check-state. > But now NOTICE: 11 packets for rule 6 and 9 (7+2) packets for dinamic rule > with rule 6 as parent. 11 != 9, so here couter lost 2 packets =( Plus the original 2 trigger packets, shown above at rule 2, making 11 packets shown at rule 6. I'm not entirely sure why the total of 12 packets isn't shown (6 packets, each both in and out as you've not specified direction on your rules), but suspect it's to do with the position of your NAT rule, and/or the fact that you're not showing counts for 'via ng1'. > Another usefull feature is that that check-state must have body. > You must allow user to check same conditions as for other rules. For > example: > check-state icmp via ng0 > It will prevent user from having unexpected maching for flows on other > interfaces (ng1 interface as in my example). > Also I think it will be handy to have many tables for dynamic rules. > It is like to have many routing tables. For example: > ipfw add xxx check-state 1 via ng0 > ipfw add xxx check-state 2 via ng1 > ipfw add xxx skipto yyy icmp via ng0 keep-state 1 > ipfw add xxx skipto yyy icmp via ng1 keep-state 2 I suggest you'll need to study the code of /usr/src/sbin/ipfw/ipfw2.c and /sys/netinet/ip_fw*.[ch] to find out just how it works now, before writing code to implement the above. I can't see anyone else taking an interest in implementing such a thing (but I've been wrong before :) > ipfw is flexible firewall so it must remain its flexibility > But now ipfw has not its flexibility for check-state/keep-state because of > it does not allow to control what I want to check-state/keep-state You just need to understand how ipfw stateful rules really work, and code your rules to match that; then I expect you will enjoy success. cheers, Ian (professing no more than a VERY minimal grasp of this code ..) From kes-kes at yandex.ru Fri Nov 28 15:45:43 2008 From: kes-kes at yandex.ru (KES) Date: Fri Nov 28 15:45:50 2008 Subject: kern/129103: [ipfw] IPFW check state does not work =( In-Reply-To: <20081128161236.P92549@sola.nimnet.asn.au> References: <200811232342.mANNgOnr069400@freefall.freebsd.org> <20081124203046.I43853@sola.nimnet.asn.au> <1638065040.20081125011317@yandex.ru> <20081128161236.P92549@sola.nimnet.asn.au> Message-ID: <747868075.20081129014517@yandex.ru> ????????????, Ian. >> But now NOTICE: 11 packets for rule 6 and 9 (7+2) packets for dinamic rule >> with rule 6 as parent. 11 != 9, so here couter lost 2 packets =( IS> Plus the original 2 trigger packets, shown above at rule 2, making 11 IS> packets shown at rule 6. I'm not entirely sure why the total of 12 IS> packets isn't shown (6 packets, each both in and out as you've not IS> specified direction on your rules), but suspect it's to do with the IS> position of your NAT rule, and/or the fact that you're not showing IS> counts for 'via ng1'. IS> There are 11 packets because of first packet received from ng1 do not counted. This ok here. But dynamic rules must count packets when they are created (see plus sign on attached picture). Actually packets are pass them but not counted ( PS. Attachment that do not pass size control in last message =( >>I suggest you'll need to study the code of /usr/src/sbin/ipfw/ipfw2.c >>and /sys/netinet/ip_fw*.[ch] to find out just how it works now, before >>writing code to implement the above. I can't see anyone else taking an >>interest in implementing such a thing (but I've been wrong before :) Any way check-state must have body, to control whick trafic we want to check for dynamic rules. If you afraid of mistakes in firewall for dynamic rules are created but never check, for this check-state log can be added, so for expired dynamic rules, but no one packet had pass through them log message will be added to /var/log/security WARNING: dynamic rule has expired and no traffic pass through it >> Another usefull feature is that that check-state must have body. >> You must allow user to check same conditions as for other rules. For >> example: >> check-state icmp via ng0 >> It will prevent user from having unexpected maching for flows on other >> interfaces (ng1 interface as in my example). >> Also I think it will be handy to have many tables for dynamic rules. >> It is like to have many routing tables. For example: >> ipfw add xxx check-state 1 via ng0 >> ipfw add xxx check-state 2 via ng1 >> ipfw add xxx skipto yyy icmp via ng0 keep-state 1 >> ipfw add xxx skipto yyy icmp via ng1 keep-state 2 For last two days I have testing dynamic rules I notice next for this scheme of load balancing with two connection to different ISP 03510 check-state 03511 prob 0.500000 skipto 3531 ip from any to any via ng* 03521 skipto 3522 ip from any to any keep-state 03523 setfib 0 ip from any to any 03525 skipto 3550 ip from any to any 03531 skipto 3532 ip from any to any keep-state 03533 setfib 1 ip from any to any 03535 skipto 3550 ip from any to any 03990 allow ip from any to any via ng* Such services as ICQ does not work properly. Because of some idle time other dynamic rule is created and so ICQ client has lost its connection because it is actually change its IP So here it will be use full to point how long dynamic rule will exist 03521 skipto 3522 ip from any to any 5190 keep-state 0 << stands to keep dynamic rule until TCP->FIN is received \ or some sysctl ....MAX_TIME variable 03521 skipto 3522 ip from any to any keep-state 60 << here we want to extend/prolong dynamic rule will exists 03521 skipto 3522 ip from any to any keep-state <