From owner-freebsd-ipfw@FreeBSD.ORG Sun Jul 18 15:51:31 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF169106566B; Sun, 18 Jul 2010 15:51:31 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B7B238FC21; Sun, 18 Jul 2010 15:51:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6IFpVDt010395; Sun, 18 Jul 2010 15:51:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6IFpVVm010391; Sun, 18 Jul 2010 15:51:31 GMT (envelope-from linimon) Date: Sun, 18 Jul 2010 15:51:31 GMT Message-Id: <201007181551.o6IFpVVm010391@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148091: [ipfw] ipfw ipv6 handling broken. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 15:51:32 -0000 Old Synopsis: ipfw ipv6 handling broken. New Synopsis: [ipfw] ipfw ipv6 handling broken. Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jul 18 15:51:09 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148091 From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 19 05:27:06 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8F4F1065675 for ; Mon, 19 Jul 2010 05:27:06 +0000 (UTC) (envelope-from mr.xanto@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 385A88FC08 for ; Mon, 19 Jul 2010 05:27:05 +0000 (UTC) Received: by ewy26 with SMTP id 26so1369634ewy.13 for ; Sun, 18 Jul 2010 22:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-mailer:x-priority :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=Xdy2IxZ0Eh6jYvtMjwtwhvfdKgvW/850o2sLP5HbPzI=; b=O2G3CFjlvSAgRJbiTUgKm+M/YHSvkALX7vFh+VqcDoKQ5/BCN9PRo7lLZyBbP1Xrr2 s7yctleKKo3XVMKTCr7lgxVB+dUrfuOlOtPEhRvD0yUPokVwTMgBLYwrby7MqFv+5QfL 1kLuuzPcOvuujMtFBZqZgmWT1q6ZWve/L7/JI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-mailer:x-priority:message-id:to:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=wKCRFS8eTyBQXg15g4kJ3h31rsY0UssbI4P04tNmwgEstAExv/IKbheZta9JpXe12F alqbpPdQE0nzxaV9X2syNtHkHLbALfEec8+qoBZJpl6jLOKbwu6UJN0tNbWRErOVkpKS 6IX9nS0klEI5UB5VuSFg+ixvmqSfeg1KNPnXo= Received: by 10.213.108.73 with SMTP id e9mr2432895ebp.36.1279517224964; Sun, 18 Jul 2010 22:27:04 -0700 (PDT) Received: from RMAMONTOV ([91.202.20.14]) by mx.google.com with ESMTPS id x54sm44225303eeh.17.2010.07.18.22.27.03 (version=SSLv3 cipher=OTHER); Sun, 18 Jul 2010 22:27:04 -0700 (PDT) Date: Mon, 19 Jul 2010 09:26:44 +0400 From: Mamontov Roman X-Mailer: Voyager (v3.99.8) Professional X-Priority: 3 (Normal) Message-ID: <893037983.20100719092644@gmail.com> To: freebsd-ipfw@freebsd.org In-Reply-To: <20100715183743.S86988@sola.nimnet.asn.au> References: <1931583025.20100715114512@gmail.com> <20100715183743.S86988@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Problem with ipfw nat and packet to local services X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 05:27:06 -0000 Hello, Ian. > UDP port 33564 on this box (xxx.xxx.xxx.xxx) is not redirected to any > other address:port, and you have specified deny_in (-deny_incoming in > natd-speak) so, well, you got what you asked for .. > See the description under -deny_incoming and the explanation of what > happens to incoming packets under -alias_address in natd(8) .. the nat > description in ipfw(8) is still a bit thin, so natd(8) is still useful. > Without deny_in, new inbound packets should be passed to the local > machine - so you will then need firewall rules to restrict which local > ports are to be accessible for connections from the outside. > cheers, Ian I remove option deny_in from nat configuration. But inbound packets not passed to the local services. #ipfw nat show config ipfw nat 1 config ip xxx.xxx.xxx.xxx #ipfw show 00035 59 4703 nat 1 log ip from any to any via ext_if1 65000 510 44734 allow ip from any to any 65535 58083 11212917 deny ip from any to any -- Best regards, Mamontov Roman mailto:mr.xanto@gmail.com From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 19 08:47:16 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52675106566C for ; Mon, 19 Jul 2010 08:47:16 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 9EC9D8FC19 for ; Mon, 19 Jul 2010 08:47:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o6J8lBRU005975; Mon, 19 Jul 2010 18:47:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 19 Jul 2010 18:47:11 +1000 (EST) From: Ian Smith To: Mamontov Roman In-Reply-To: <893037983.20100719092644@gmail.com> Message-ID: <20100719181208.A86988@sola.nimnet.asn.au> References: <1931583025.20100715114512@gmail.com> <20100715183743.S86988@sola.nimnet.asn.au> <893037983.20100719092644@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org Subject: Re: Problem with ipfw nat and packet to local services X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 08:47:16 -0000 On Mon, 19 Jul 2010, Mamontov Roman wrote: > Hello, Ian. > > > UDP port 33564 on this box (xxx.xxx.xxx.xxx) is not redirected to any > > other address:port, and you have specified deny_in (-deny_incoming in > > natd-speak) so, well, you got what you asked for .. > > > See the description under -deny_incoming and the explanation of what > > happens to incoming packets under -alias_address in natd(8) .. the nat > > description in ipfw(8) is still a bit thin, so natd(8) is still useful. > > > Without deny_in, new inbound packets should be passed to the local > > machine - so you will then need firewall rules to restrict which local > > ports are to be accessible for connections from the outside. > > > cheers, Ian > > I remove option deny_in from nat configuration. But inbound packets not passed to the > local services. > > #ipfw nat show config > ipfw nat 1 config ip xxx.xxx.xxx.xxx > > #ipfw show > 00035 59 4703 nat 1 log ip from any to any via ext_if1 > 65000 510 44734 allow ip from any to any > 65535 58083 11212917 deny ip from any to any Hi Mamontov, What's the value of sysctl net.inet.ip.fw.one_pass ? It needs to be 0 so that packets will re-enter the firewall after NAT processing. Otherwise, it might help to a) run 'ipfw zero' before any tests .. I'm wondering about all those packets hitting rule 65535; were they from before adding rule 65000? b) add some count rules before and after nat, to show all packets that may be eligible for NAT translation, maybe something like: 00020 count log ip from any to any in recv ${ext_if} 00022 count log ip from any to any out xmit ${ext_if} 00024 count log ip from any to any out recv ${int_if} xmit ${ext_if} 00035 nat ... 00040 count log ip from any to any in recv ${ext_if} 00042 count log ip from any to any out xmit ${ext_if} 00044 count log ip from any to any out recv ${int_if} xmit ${ext_if} So you actually get to see the flow of packets before and after nat, both to/from the local box and packets mapped to/rom inside addresses. Again, an 'ipfw zero' before tests will make packet counts clearer. Of course something like '# tcpdump -pn -i ext_if' will also show all packets via ext_if in some detail. Be more specific if just looking for some particular flows, like maybe appending 'udp port NNNNN' to that. That is, try to follow packets you'd expect to be coming in for services on the local box so if they are disappearing, you'll know where or why. 'netstat -finet -an' will show all those services that are listening. If that doesn't help, we'll need more information. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 19 10:31:13 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 304AF1065675 for ; Mon, 19 Jul 2010 10:31:13 +0000 (UTC) (envelope-from mr.xanto@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B573F8FC14 for ; Mon, 19 Jul 2010 10:31:12 +0000 (UTC) Received: by wyf22 with SMTP id 22so5118053wyf.13 for ; Mon, 19 Jul 2010 03:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-mailer:x-priority :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=z3+XTf4Mesxp/gXaVUkZTiKP+aRrLJq0A36oHPE5Qx8=; b=FDIAhNL0G/ETduO4lb1DS4GD31kqXZz8eQqPvg4xHbfrjiw4gPu3BOy8INLbNgoe9F SvHbv0HD2qBzlnMLClnohme0kAUlkkEmQzcEVYhgmX8FMsCt8rFPVtYK+/Fzdj3TMpeJ h2nWjej6t3g30ASuwdJ8X0DwB6nn2QAG51y8c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-mailer:x-priority:message-id:to:subject:in-reply-to :references:mime-version:content-type:content-transfer-encoding; b=wZGZur7TVl78dz0I4T0s81WseLJhcK3eq9kWbn1NOW/+Bl5NPnI48PTCGuvW8zAL8p Weto1jSwo2mnIU8hr6IZYVmGd2l+HvUqVOV/hPCi29V/6PMbnXHbJ2rF2+G0CqEjFVWG rcQiiIikJYXImn62raW++2p4Xl2lq//YfMbzE= Received: by 10.227.132.129 with SMTP id b1mr3868357wbt.5.1279535471636; Mon, 19 Jul 2010 03:31:11 -0700 (PDT) Received: from RMAMONTOV ([91.202.20.14]) by mx.google.com with ESMTPS id e31sm39846746wbe.17.2010.07.19.03.31.09 (version=SSLv3 cipher=OTHER); Mon, 19 Jul 2010 03:31:10 -0700 (PDT) Date: Mon, 19 Jul 2010 14:31:04 +0400 From: Mamontov Roman X-Mailer: Voyager (v3.99.8) Professional X-Priority: 3 (Normal) Message-ID: <1207784719.20100719143104@gmail.com> To: freebsd-ipfw@freebsd.org In-Reply-To: <20100719181208.A86988@sola.nimnet.asn.au> References: <1931583025.20100715114512@gmail.com> <20100715183743.S86988@sola.nimnet.asn.au> <893037983.20100719092644@gmail.com> <20100719181208.A86988@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Problem with ipfw nat and packet to local services X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 10:31:13 -0000 Hello, Ian. > Hi Mamontov, > What's the value of sysctl net.inet.ip.fw.one_pass ? It needs to be 0 > so that packets will re-enter the firewall after NAT processing. > Otherwise, it might help to > a) run 'ipfw zero' before any tests .. I'm wondering about all those > packets hitting rule 65535; were they from before adding rule 65000? > b) add some count rules before and after nat, to show all packets > that may be eligible for NAT translation, maybe something like: > 00020 count log ip from any to any in recv ${ext_if} > 00022 count log ip from any to any out xmit ${ext_if} > 00024 count log ip from any to any out recv ${int_if} xmit ${ext_if} > 00035 nat ... > 00040 count log ip from any to any in recv ${ext_if} > 00042 count log ip from any to any out xmit ${ext_if} > 00044 count log ip from any to any out recv ${int_if} xmit ${ext_if} > So you actually get to see the flow of packets before and after nat, > both to/from the local box and packets mapped to/rom inside addresses. > Again, an 'ipfw zero' before tests will make packet counts clearer. > Of course something like '# tcpdump -pn -i ext_if' will also show all > packets via ext_if in some detail. Be more specific if just looking for > some particular flows, like maybe appending 'udp port NNNNN' to that. > That is, try to follow packets you'd expect to be coming in for services > on the local box so if they are disappearing, you'll know where or why. > 'netstat -finet -an' will show all those services that are listening. > If that doesn't help, we'll need more information. > cheers, Ian # sysctl net.inet.ip.fw.one_pass net.inet.ip.fw.one_pass: 0 # ipfw show 20-49 00020 40 2016 count log ip from any to me dst-port 22 in recv ext_if1 00021 0 0 count log ip from me 22 to any out xmit ext_if1 00035 13192 9028716 nat 1 ip from any to any via ext_if1 00040 0 0 count log ip from any to me dst-port 22 in recv ext_if1 00041 0 0 count log ip from me 22 to any out xmit ext_if1 # ipfw nat show config ipfw nat 1 config ip xxx.xxx.xxx.xxx # tcpdump -pn -i ext_if1 'host yyy.yyy.yyy.yyy' 14:12:48.885011 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]> 14:12:51.888823 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]> 14:12:54.884966 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]> 14:12:57.884090 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460], length 0 14:13:00.885131 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460], length 0 14:13:03.887094 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460], length 0 Output # netstat -finet -an | grep yyy.yyy.yyy.yyy is blank. Without rule 35 nat 1 ip from any to any via ext_if1 inbound packet to ssh (for example) pass correctly. # ipfw delete 35 tcpdump -pn -i ext_if 'host yyy.yyy.yyy.yyy' 14:21:45.467233 IP yyy.yyy.yyy.yyy.2790 > xxx.xxx.xxx.xxx.22: Flags [S], seq 376101413, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]> 14:21:45.467670 IP xxx.xxx.xxx.xxx.22 > xxx.xxx.xxx.xxx.2790: Flags [S.], seq 3270699616, ack 376101414, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS[|tcp]> 14:21:45.468960 IP yyy.yyy.yyy.yyy.2790 > xxx.xxx.xxx.xxx.22: Flags [.], ack 1, win 33304, options [nop,nop,TS val 40088404 ecr 1166915706], length 0 14:21:45.527438 IP xxx.xxx.xxx.xxx.22 > yyy.yyy.yyy.yyy.2790: Flags [P.], ack 1, win 8326, options [nop,nop,TS val 1166915766 ecr 40088404], length 40 # netstat -finet -an | grep yyy.yyy.yyy.yyy tcp4 0 0 xxx.xxx.xxx.xxx.22 yyy.yyy.yyy.yyy.2790 FIN_WAIT_2 00020 8 1403 count log ip from any to me dst-port 22 in recv ext_if1 00021 6 2280 count log ip from me 22 to any out xmit ext_if1 00040 8 1403 count log ip from any to me dst-port 22 in recv ext_if1 00041 6 2280 count log ip from me 22 to any out xmit ext_if1 Any ideas? -- Best regards, Mamontov Roman mailto:mr.xanto@gmail.com From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 19 11:06:59 2010 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C76106566C for ; Mon, 19 Jul 2010 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 32DDF8FC13 for ; Mon, 19 Jul 2010 11:06:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6JB6xBA065737 for ; Mon, 19 Jul 2010 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6JB6wUV065735 for freebsd-ipfw@FreeBSD.org; Mon, 19 Jul 2010 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Jul 2010 11:06:58 GMT Message-Id: <201007191106.o6JB6wUV065735@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 11:06:59 -0000 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/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148429 ipfw net.inet.ip.dummynet.io_fast broken or documentation i o kern/148157 ipfw [ipfw] IPFW in kernel nat BUG found in FreeBSD 8.1-PRE o conf/148144 ipfw [patch] add ipfw_nat support for rc.firewall simple ty o conf/148137 ipfw [ipfw] call order of natd and ipfw startup scripts o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/147720 ipfw [ipfw] ipfw dynamic rules and fwd o kern/145733 ipfw [ipfw] [patch] ipfw flaws with ipv6 fragments o kern/145305 ipfw [ipfw] ipfw problems, panics, data corruption, ipv6 so o kern/145167 ipfw [ipfw] ipfw nat does not follow its documentation o kern/144869 ipfw [ipfw] [panic] Instant kernel panic when adding NAT ru o kern/144269 ipfw [ipfw] problem with ipfw tables o kern/144187 ipfw [ipfw] deadlock using multiple ipfw nat and multiple l o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143653 ipfw [ipfw] [patch] ipfw nat redirect_port "buf is too smal o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/143474 ipfw [ipfw] ipfw table contains the same address f kern/142951 ipfw [dummynet] using pipes&queues gives OUCH! pipe should o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/132553 ipfw [ipfw] ipfw doesn't understand ftp-data port o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho 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 bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 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 spec o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets 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 bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s 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 79 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 19 12:08:57 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C08C106566B for ; Mon, 19 Jul 2010 12:08:57 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id BE3C28FC0C for ; Mon, 19 Jul 2010 12:08:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o6JC8sG4015425; Mon, 19 Jul 2010 22:08:54 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 19 Jul 2010 22:08:53 +1000 (EST) From: Ian Smith To: Mamontov Roman In-Reply-To: <1207784719.20100719143104@gmail.com> Message-ID: <20100719203632.G86988@sola.nimnet.asn.au> References: <1931583025.20100715114512@gmail.com> <20100715183743.S86988@sola.nimnet.asn.au> <893037983.20100719092644@gmail.com> <20100719181208.A86988@sola.nimnet.asn.au> <1207784719.20100719143104@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org Subject: Re: Problem with ipfw nat and packet to local services X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 12:08:57 -0000 On Mon, 19 Jul 2010, Mamontov Roman wrote: > > What's the value of sysctl net.inet.ip.fw.one_pass ? It needs to be 0 > > so that packets will re-enter the firewall after NAT processing. > > > Otherwise, it might help to > > > a) run 'ipfw zero' before any tests .. I'm wondering about all those > > packets hitting rule 65535; were they from before adding rule 65000? > > > b) add some count rules before and after nat, to show all packets > > that may be eligible for NAT translation, maybe something like: > > > 00020 count log ip from any to any in recv ${ext_if} > > 00022 count log ip from any to any out xmit ${ext_if} > > 00024 count log ip from any to any out recv ${int_if} xmit ${ext_if} > > > 00035 nat ... > > > 00040 count log ip from any to any in recv ${ext_if} > > 00042 count log ip from any to any out xmit ${ext_if} > > 00044 count log ip from any to any out recv ${int_if} xmit ${ext_if} > > > So you actually get to see the flow of packets before and after nat, > > both to/from the local box and packets mapped to/rom inside addresses. > > Again, an 'ipfw zero' before tests will make packet counts clearer. > > > Of course something like '# tcpdump -pn -i ext_if' will also show all > > packets via ext_if in some detail. Be more specific if just looking for > > some particular flows, like maybe appending 'udp port NNNNN' to that. > > > That is, try to follow packets you'd expect to be coming in for services > > on the local box so if they are disappearing, you'll know where or why. > > 'netstat -finet -an' will show all those services that are listening. > > > If that doesn't help, we'll need more information. > > > cheers, Ian > > # sysctl net.inet.ip.fw.one_pass > net.inet.ip.fw.one_pass: 0 > > # ipfw show 20-49 > 00020 40 2016 count log ip from any to me dst-port 22 in recv ext_if1 > 00021 0 0 count log ip from me 22 to any out xmit ext_if1 > 00035 13192 9028716 nat 1 ip from any to any via ext_if1 > 00040 0 0 count log ip from any to me dst-port 22 in recv ext_if1 > 00041 0 0 count log ip from me 22 to any out xmit ext_if1 Ouch. It does look like nat is just swallowing the ssh packets on the inbound pass .. these surely should appear again after NAT (unchanged). > # ipfw nat show config > ipfw nat 1 config ip xxx.xxx.xxx.xxx > > # tcpdump -pn -i ext_if1 'host yyy.yyy.yyy.yyy' > 14:12:48.885011 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]> > 14:12:51.888823 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]> > 14:12:54.884966 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]> > 14:12:57.884090 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460], length 0 > 14:13:00.885131 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460], length 0 > 14:13:03.887094 IP yyy.yyy.yyy.yyy.2777 > xxx.xxx.xxx.xxx.22: Flags [S], seq 2880611174, win 65535, options [mss 1460], length 0 Ah, if that 'TS' means TSO - tcpdump(1) doesn't mention either - then from the last section of ipfw(8): Due to the architecture of libalias(3), ipfw nat is not compatible with the TCP segmentation offloading (TSO). Thus, to reliably nat your net- work traffic, please disable TSO on your NICs using ifconfig(8). ifconfig ext_if1 ? > Output > # netstat -finet -an | grep yyy.yyy.yyy.yyy > is blank. > > Without rule 35 nat 1 ip from any to any via ext_if1 inbound packet to ssh (for example) > pass correctly. > > # ipfw delete 35 > tcpdump -pn -i ext_if 'host yyy.yyy.yyy.yyy' > 14:21:45.467233 IP yyy.yyy.yyy.yyy.2790 > xxx.xxx.xxx.xxx.22: Flags [S], seq 376101413, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS[|tcp]> > 14:21:45.467670 IP xxx.xxx.xxx.xxx.22 > xxx.xxx.xxx.xxx.2790: Flags [S.], seq 3270699616, ack 376101414, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS[|tcp]> I guess that dest is just mis-obscured, ie yyy.yyy.yyy.yyy:2790 > 14:21:45.468960 IP yyy.yyy.yyy.yyy.2790 > xxx.xxx.xxx.xxx.22: Flags [.], ack 1, win 33304, options [nop,nop,TS val 40088404 ecr 1166915706], length 0 > 14:21:45.527438 IP xxx.xxx.xxx.xxx.22 > yyy.yyy.yyy.yyy.2790: Flags [P.], ack 1, win 8326, options [nop,nop,TS val 1166915766 ecr 40088404], length 40 > > # netstat -finet -an | grep yyy.yyy.yyy.yyy > tcp4 0 0 xxx.xxx.xxx.xxx.22 yyy.yyy.yyy.yyy.2790 FIN_WAIT_2 > > 00020 8 1403 count log ip from any to me dst-port 22 in recv ext_if1 > 00021 6 2280 count log ip from me 22 to any out xmit ext_if1 > 00040 8 1403 count log ip from any to me dst-port 22 in recv ext_if1 > 00041 6 2280 count log ip from me 22 to any out xmit ext_if1 > > Any ideas? [later: if you had TSO enabled on the interface, ignore the below ..] I see you're not logging nat packets now, and wonder if there'd be any more clues in the log, but then, does nat log packets it doesn't touch? Unless I'm completely missing something (wouldn't be the first time :) this looks like a bug, and unless someone else has a better clue, you should file a PR with what you've demonstrated to date. cheers, Ian (only vaguely useful with usage, and not at all with code) From owner-freebsd-ipfw@FreeBSD.ORG Tue Jul 20 13:01:11 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA6C51065677; Tue, 20 Jul 2010 13:01:11 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9271D8FC19; Tue, 20 Jul 2010 13:01:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6KD1BWh070190; Tue, 20 Jul 2010 13:01:11 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6KD1BOv070186; Tue, 20 Jul 2010 13:01:11 GMT (envelope-from gavin) Date: Tue, 20 Jul 2010 13:01:11 GMT Message-Id: <201007201301.o6KD1BOv070186@freefall.freebsd.org> To: bu7cher@yandex.ru, gavin@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/113388: [ipfw] [patch] Addition actions with rules within specified set's X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 13:01:11 -0000 Synopsis: [ipfw] [patch] Addition actions with rules within specified set's State-Changed-From-To: patched->closed State-Changed-By: gavin State-Changed-When: Tue Jul 20 13:00:21 UTC 2010 State-Changed-Why: This is in 7.0 and up, and is unlikely to ever be merged back to 6.x now. Close. http://www.freebsd.org/cgi/query-pr.cgi?pr=113388 From owner-freebsd-ipfw@FreeBSD.ORG Tue Jul 20 16:08:38 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 255BB106566C for ; Tue, 20 Jul 2010 16:08:38 +0000 (UTC) (envelope-from mlmichael70@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A2EAB8FC0A for ; Tue, 20 Jul 2010 16:08:37 +0000 (UTC) Received: by bwz12 with SMTP id 12so3484393bwz.13 for ; Tue, 20 Jul 2010 09:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=935dZdHVAIIrQqkWdMUm9yNeFu2hPFOu9oKyf3QkItU=; b=wc0EURN3xFa/DqeTFRboTDqWg4PaKvYwECZqQeH8+GLAMA5Gmx9rtGM3QmX3L2z7TW hepGg1O/Ep3gEdle7f3OU4CynXK0Pi1407vNK6kygbR9pCjqjGk9PzjuaUkuvUI4K8Yo 8lhAF3C3v9+Q8ex+IMdHa0FiE+apikAw3120g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=iMW8C0QiSZRdcHxRti3Vkm+j420rQpnjNDLOrY/6czzZsVLPldU05Mi4PjbLOKsvsr A1pkb+7cgrUsZl6Wzslsw/zHoCeQ7HOxCtp6PcLNfQtlg61AooMbsh1qdSdSLdeXS9dJ TOcFEOU0og27Y6bszz175vnIL12YYzDVHRkyc= Received: by 10.204.56.14 with SMTP id w14mr5313965bkg.187.1279642116305; Tue, 20 Jul 2010 09:08:36 -0700 (PDT) Received: from prime.local (94-193-57-116.zone7.bethere.co.uk [94.193.57.116]) by mx.google.com with ESMTPS id y27sm28180901bkw.14.2010.07.20.09.08.35 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 09:08:35 -0700 (PDT) Message-ID: <4C45CA06.3070408@gmail.com> Date: Tue, 20 Jul 2010 17:08:38 +0100 From: Michael User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100628 Thunderbird/3.0.5 MIME-Version: 1.0 To: Steve Bertrand References: <4C3AEA4E.50005@gmail.com> <4C3B0ED7.9010807@ipv6canada.com> In-Reply-To: <4C3B0ED7.9010807@ipv6canada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: please help with NATing my jails X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 16:08:38 -0000 On 12/07/2010 13:47, Steve Bertrand wrote: > > ...do you need a second nat rule for the inbound traffic, or does nat > handle that by itself? If you run tcpdump on the wlan interface, do you > see the inbound traffic that relates to your request? > I don't know if I need that second rule but after adding rule 00035 nat 100 ip from not me to 127.127.127.1 via wlan0 keep-state nothing changes, still the same problem. While I'm trying to get "host freebsd.org" from the jailed system, tcpdump on wlan0 says: ARP, Request who-has 192.168.1.254 tell 192.168.1.254, length 28 ARP, Request who-has 192.168.1.111 tell 192.168.1.254, length 28 ARP, Reply 192.168.1.111 is-at 00:26:5e:e7:e8:78, length 28 ARP, Request who-has 192.168.1.94 tell 192.168.1.254, length 28 ARP, Request who-has 192.168.1.95 tell 192.168.1.254, length 28 ARP, Request who-has 192.168.1.96 tell 192.168.1.254, length 28 ARP, Request who-has 192.168.1.82 tell 192.168.1.254, length 28 IP 192.168.1.111.37766 > 208.67.222.222.53: 55415+ A? freebsd.org. (29) IP 208.67.222.222.53 > 192.168.1.111.37766: 55415 1/0/0 A 69.147.83.40 (45) IP 192.168.1.111 > 208.67.222.222: ICMP 192.168.1.111 udp port 37766 unreachable, length 36 IP 192.168.1.111.45007 > 208.67.220.220.53: 55415+ A? freebsd.org. (29) IP 208.67.220.220.53 > 192.168.1.111.45007: 55415 1/0/0 A 69.147.83.40 (45) IP 192.168.1.111 > 208.67.220.220: ICMP 192.168.1.111 udp port 45007 unreachable, length 36 IP 192.168.1.111.37766 > 208.67.222.222.53: 55415+ A? freebsd.org. (29) IP 208.67.222.222.53 > 192.168.1.111.37766: 55415 1/0/0 A 69.147.83.40 (45) IP 192.168.1.111 > 208.67.222.222: ICMP 192.168.1.111 udp port 37766 unreachable, length 36 IP 192.168.1.111.45007 > 208.67.220.220.53: 55415+ A? freebsd.org. (29) IP 208.67.220.220.53 > 192.168.1.111.45007: 55415 1/0/0 A 69.147.83.40 (45) IP 192.168.1.111 > 208.67.220.220: ICMP 192.168.1.111 udp port 45007 unreachable, length 36 So once again my rules are: ipfw -q -f flush ipfw add 00010 allow all from 127.0.0.1 to 127.0.0.1 via lo0 ipfw add 00020 check-state ipfw add 00030 nat 100 ip from 127.127.127.1 to any via wlan0 keep-state ipfw nat 100 config ip 192.168.1.111 log ipfw add 00040 allow all from any to any Any ideas please? Michael From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 21 10:03:30 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 880051065673 for ; Wed, 21 Jul 2010 10:03:30 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 22B668FC1E for ; Wed, 21 Jul 2010 10:03:29 +0000 (UTC) Received: by wwe15 with SMTP id 15so1672148wwe.31 for ; Wed, 21 Jul 2010 03:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=Z5lVmtyA96nepvHyB7xBHxFq7wVMVUnQxmKcOtxavPU=; b=cLBksue4L4XXxggxzWNFYwccnxZ48O0r07JmbIRYY0tCwHMi1adkijQMmLMZ0+Cvl+ yhFpcV1FnyUeIDd07+kSCmuajT++zVkxojn0UILvFGe1fsPNXz3hEsb+XuTS2LESzH4S Khm6IY8GDUhcBp5eiXeeFf8wP7UZ7IdiGbImA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=pm7UgCBoe1DR2EwIykgyFRd9M1OfZ98NEm6M0kCizD1wq2EKO0CmEmo442MeccIMmT Dt3i29MBOUyYrdj7vzd8nadbXNE6TkEndeJG1ilZTaS5faNtz75YgXOsSrIKvsPnDYeK xmS6vAtEY/4hWI1Ow6qvV5Ej76U9jGn5/LAvg= MIME-Version: 1.0 Received: by 10.216.178.135 with SMTP id f7mr6402586wem.63.1279705229518; Wed, 21 Jul 2010 02:40:29 -0700 (PDT) Received: by 10.216.138.66 with HTTP; Wed, 21 Jul 2010 02:40:29 -0700 (PDT) Date: Wed, 21 Jul 2010 11:40:29 +0200 Message-ID: From: Spil Oss To: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Changes to ipfw in 8.1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 10:03:30 -0000 Hi, Testing FreeBSD 8.1 I noticed that I seem to have routing or nat or firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC last night?) - 8.1 booted fine - connections from the system itself were fine - connections from my jails to the internet were not working - connections from my LAN/WLAN to the internet were not working Reverting back to 8.0-p2 with the same configuration works fine. In UPDATING I see that rc.firewall and rc.firewall6 were unified. Setup is - xl0 connected to internet/public IP via dhcp - bge0/wlan0(ath0) connected to LAN - jails have ip's on bge0 in the same subnet as the LAN - allow all from any to any via bge0|wlan0|lo0 - NAT using natd My guess is that something's changed to ipfw that is affecting my network settings. Any clues where I went wrong? Help appreciated/ Kind regards, Spil. rc.conf: firewall_enable="YES" firewall_script="/etc/ipfw.rules" natd.conf interface xl0 dynamic yes same_ports yes # http/https to http jail redirect_port tcp 192.168.2.3:80 80 redirect_port tcp 192.168.2.3:443 443 Part of /etc/ipfw.rules #!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=xl0 pif6=gif0 ext6="2001:dead:beef:1::1" ks="keep-state" ipfw -q -f flush # Allow internal traffic $cmd 002 allow all from any to any via bge0 # exclude LAN traffic $cmd 003 allow all from any to any via lo0 # exclude loopback traffic $cmd 004 allow all from any to any via wlan0 # exclude WLAN traffic $cmd 005 allow all from any to any via bridge0 # exclude WLAN traffic $cmd 006 allow all from any to any via tun0 # exclude WLAN traffic # Allow all encapulated IPv6 to/from tunnel PoP $cmd 010 allow ip4 from to me via $pif $cmd 010 allow ip4 from me to via $pif # Black-hole some stuff using tables $cmd 050 drop ip from "table(17)" to any in via $pif $cmd 050 drop ip from any to "table(17)" out via $pif # Separate IPv6 rules (no NAT!) $cmd 060 skipto 1000 ip6 from any to any $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound packets from external $cmd 101 check-state # Authorized outbound packets $cmd 130 $skip icmp from any to any out via $pif $ks $cmd 150 $skip tcp from any to any out via $pif $ks $cmd 151 $skip udp from any to any out via $pif $ks $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks # Deny all inbound traffic from non-routable reserved address spaces $cmd 300 unreach host all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 301 unreach host all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP $cmd 302 unreach host all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP $cmd 303 unreach host all from 127.0.0.0/8 to any in via $pif #loopback $cmd 304 unreach host all from 0.0.0.0/8 to any in via $pif #loopback $cmd 305 unreach host all from 169.254.0.0/16 to any in via $pif #DHCP auto-config $cmd 306 unreach host all from 192.0.2.0/24 to any in via $pif #reserved for docs $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif #Sun cluster $cmd 308 unreach host all from 224.0.0.0/3 to any in via $pif #Class D & E multicast # Deny packets that did not match the dynamic rule table #$cmd 330 deny all from any to any frag in via $pif # All late fragments #$cmd 332 deny tcp from any to any established in via $pif # Deny ACK # Authorized inbound packets $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply and TTL-exceeded $cmd 420 allow tcp from any to me ssh in via $pif setup $ks $cmd 421 allow tcp from any to me smtp in via $pif $cmd 422 allow tcp from any to me http in via $pif $cmd 423 allow tcp from any to me https in via $pif $cmd 424 allow tcp from any to me imaps in via $pif #$cmd 449 unreach host ip from any to any in via $pif $cmd 448 reject log all from any to any in via $pif $cmd 449 reject log all from any to any out via $pif $cmd 450 reject log ip from any to any # This is skipto location for outbound stateful rules $cmd 500 divert natd ip from any to any out via $pif $cmd 510 allow ip from any to any From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 21 16:03:44 2010 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D93D1065777 for ; Wed, 21 Jul 2010 16:03:44 +0000 (UTC) (envelope-from lordcow@lordcow.org) Received: from lordcow.org (lordcow.org [41.203.5.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5D47C8FC25 for ; Wed, 21 Jul 2010 16:03:42 +0000 (UTC) Received: from lordcow.org (localhost [127.0.0.1]) by lordcow.org (8.14.3/8.14.3) with ESMTP id o6K7ooKw098026 for ; Tue, 20 Jul 2010 09:50:50 +0200 (SAST) (envelope-from lordcow@lordcow.org) Received: (from lordcow@localhost) by lordcow.org (8.14.3/8.14.3/Submit) id o6K7ojLm098025 for ipfw@freebsd.org; Tue, 20 Jul 2010 09:50:45 +0200 (SAST) (envelope-from lordcow) Date: Tue, 20 Jul 2010 09:50:45 +0200 From: Gareth de Vaux To: ipfw@freebsd.org Message-ID: <20100720075045.GA97866@lordcow.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lordcow.org Cc: Subject: ICMP filtering X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 16:03:44 -0000 Hi all, is there any way you can filter on ICMP code as well as type in ipfw? From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 21 19:08:44 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47BE81065676; Wed, 21 Jul 2010 19:08:44 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id A04738FC0A; Wed, 21 Jul 2010 19:08:43 +0000 (UTC) Received: by eyh6 with SMTP id 6so2050582eyh.13 for ; Wed, 21 Jul 2010 12:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nsEObvxuyDiNPInc+L6umZ4Eg+SAo8i5qFskCZeq9HQ=; b=L2J5uPB6AnMWG5HOUm+Jb3NC7+U5ylzmNwfJqoCyyQiz7MoOW8eGqh9sYwZ6jaS+MH 5xLXMybB3CaBGl5llQHG3ox6JzgVcwtMpzoo3IuwhQIaN2uXup1id3Vd25zTOHJaG4in 0WORlL04Iz7mIOirs7QA+WozayOvcQQypaMZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=Kr0ZSvjfHQcAoZjodR0gKOPFJNJS6Kcp4amvC5+Zj0e4R8uC7N7i4WIFYKccGWlIfG qpNSkcd7UEf/beXXG6IAmKlrvxfh8Lt/urEX2aXDG8JZGUgiCv1gwp4/tIC7nhoIOR8z KIZT5HwUmccLHthdiKOalliha+wgsqovkT6zo= MIME-Version: 1.0 Received: by 10.216.47.140 with SMTP id t12mr568432web.102.1279739322307; Wed, 21 Jul 2010 12:08:42 -0700 (PDT) Received: by 10.216.138.66 with HTTP; Wed, 21 Jul 2010 12:08:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 21:08:42 +0200 Message-ID: From: Spil Oss To: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Changes to ipfw in 8.1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 19:08:44 -0000 Hi Sergey, Has the change from ip to ip4 solved the problem for you? The documentation states that proto 'ip' is the same as 'all' "Matches any packet." Rule # 60 $cmd 060 skipto 1000 ip6 from any to any will have already skipped to the ipv6 rules block thus proto 'ip' should always match remaining packets. Meanwhile I found bug 148137 [ipfw] call order of natd and ipfw startup scr= ipts http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148137&cat=3Dconf Don't know if that's directly related, but it may be worth a try to revert back to the RELENG_8_0 script. Will let you now my findings. Kind regards, Spil. On Wed, Jul 21, 2010 at 2:57 PM, Sergey G Nasonov wrote: > Hello Spill, > > I have get the same trouble after updating my 8.0 Stable. I thing you nee= d > modify some firewall rules. > > Please change > > $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > > to > > $cmd 100 divert natd ip4 from any to any in via $pif # Mangle inbound > > and > > $cmd 500 divert natd ip from any to any out via $pif > > to > > $cmd 500 divert natd ip4 from any to any out via $pif > > accordingly. > > -- > > Best Regards, > > Nasonov Sergey On Wed, Jul 21, 2010 at 11:40 AM, Spil Oss wrote: > Hi, > > Testing FreeBSD 8.1 I noticed that I seem to have routing or nat or > firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC last > night?) > - 8.1 booted fine > - connections from the system itself were fine > - connections from my jails to the internet were not working > - connections from my LAN/WLAN to the internet were not working > Reverting back to 8.0-p2 with the same configuration works fine. > > In UPDATING I see that rc.firewall and rc.firewall6 were unified. > > Setup is > - xl0 connected to internet/public IP via dhcp > - bge0/wlan0(ath0) connected to LAN > - jails have ip's on bge0 in the same subnet as the LAN > - allow all from any to any via bge0|wlan0|lo0 > - NAT using natd > > My guess is that something's changed to ipfw that is affecting my > network settings. Any clues where I went wrong? > > Help appreciated/ Kind regards, > > Spil. > > rc.conf: > firewall_enable=3D"YES" > firewall_script=3D"/etc/ipfw.rules" > > natd.conf > interface xl0 > dynamic yes > same_ports yes > # http/https to http jail > redirect_port tcp 192.168.2.3:80 80 > redirect_port tcp 192.168.2.3:443 443 > > Part of /etc/ipfw.rules > #!/bin/sh > cmd=3D"ipfw -q add" > skip=3D"skipto 500" > pif=3Dxl0 > pif6=3Dgif0 > ext6=3D"2001:dead:beef:1::1" > ks=3D"keep-state" > > ipfw -q -f flush > > # Allow internal traffic > $cmd 002 allow all from any to any via bge0 # exclude LAN traffic > $cmd 003 allow all from any to any via lo0 =A0# exclude loopback traffic > $cmd 004 allow all from any to any via wlan0 # exclude WLAN traffic > $cmd 005 allow all from any to any via bridge0 # exclude WLAN traffic > $cmd 006 allow all from any to any via tun0 # exclude WLAN traffic > > # Allow all encapulated IPv6 to/from tunnel PoP > $cmd 010 allow ip4 from to me via $pif > $cmd 010 allow ip4 from me to via $pif > > # Black-hole some stuff using tables > $cmd 050 drop ip from "table(17)" to any in via $pif > $cmd 050 drop ip from any to "table(17)" out via $pif > > # Separate IPv6 rules (no NAT!) > $cmd 060 skipto 1000 ip6 from any to any > > $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > packets from external > $cmd 101 check-state > > # Authorized outbound packets > $cmd 130 $skip icmp from any to any out via $pif $ks > $cmd 150 $skip tcp from any to any out via $pif $ks > $cmd 151 $skip udp from any to any out via $pif $ks > > $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks > > # Deny all inbound traffic from non-routable reserved address spaces > $cmd 300 unreach host all from 192.168.0.0/16 =A0to any in via $pif > #RFC 1918 private IP > $cmd 301 unreach host all from 172.16.0.0/12 =A0 to any in via $pif > #RFC 1918 private IP > $cmd 302 unreach host all from 10.0.0.0/8 =A0 =A0 =A0to any in via $pif > #RFC 1918 private IP > $cmd 303 unreach host all from 127.0.0.0/8 =A0 =A0 to any in via $pif =A0= #loopback > $cmd 304 unreach host all from 0.0.0.0/8 =A0 =A0 =A0 to any in via $pif = =A0#loopback > $cmd 305 unreach host all from 169.254.0.0/16 =A0to any in via $pif > #DHCP auto-config > $cmd 306 unreach host all from 192.0.2.0/24 =A0 =A0to any in via $pif > #reserved for docs > $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif =A0#Sun= cluster > $cmd 308 unreach host all from 224.0.0.0/3 =A0 =A0 to any in via $pif > #Class D & E multicast > > # Deny packets that did not match the dynamic rule table > #$cmd 330 deny all from any to any frag in via $pif # All late fragments > #$cmd 332 deny tcp from any to any established in via $pif # Deny ACK > > # Authorized inbound packets > $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply and TTL-e= xceeded > $cmd 420 allow tcp from any to me ssh in via $pif setup $ks > $cmd 421 allow tcp from any to me smtp in via $pif > $cmd 422 allow tcp from any to me http in via $pif > $cmd 423 allow tcp from any to me https in via $pif > $cmd 424 allow tcp from any to me imaps in via $pif > > #$cmd 449 unreach host ip from any to any in via $pif > $cmd 448 reject log all from any to any in via $pif > $cmd 449 reject log all from any to any out via $pif > $cmd 450 reject log ip from any to any > > # This is skipto location for outbound stateful rules > $cmd 500 divert natd ip from any to any out via $pif > $cmd 510 allow ip from any to any > From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 21 19:52:33 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCCA61065675; Wed, 21 Jul 2010 19:52:33 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 308E18FC08; Wed, 21 Jul 2010 19:52:32 +0000 (UTC) Received: by ewy26 with SMTP id 26so2962277ewy.13 for ; Wed, 21 Jul 2010 12:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=WNpS9LKmQfwaFON59H9hHsiDRKZda/Xfh7mwvk1eWDQ=; b=JSYYdRkVliQ65f2BGQ2l7jGbbtoVqD6TMUbtWxzYkrc2z0rMQ208MnpBSQYtbeGRQx t3s2X6R9KZY6uikttBID3/lE+II+DTt2Q3d2gHWehKH+N5Efl6NdZyHd2/dY2uZuxNa+ oemAZQQp08FFtKoFFCn0lsw8icivebS/n0yrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=GyLDBOJPCEqXvwa0rNIyKN/HvkayD/nuC4RgM7XPNW3W9kq6yBBBgz0Fi9PyYc0fEU gZC/VEe2E/WPufMCjB9ee4e3MI8GzbfdIwde2WETBeIhEfDUHX0BXz2SVCc6+jis6WkZ AQO7xt5TAXs6Lc6b72GY7MaVnFpUTk31V6qbE= MIME-Version: 1.0 Received: by 10.227.156.202 with SMTP id y10mr705840wbw.48.1279741951683; Wed, 21 Jul 2010 12:52:31 -0700 (PDT) Received: by 10.216.138.66 with HTTP; Wed, 21 Jul 2010 12:52:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Jul 2010 21:52:31 +0200 Message-ID: From: Spil Oss To: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org, snasonov@bcc.ru Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Changes to ipfw in 8.1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 19:52:33 -0000 Hi Sergey, I'm dumbstruck! Switching 'ip' to 'ip4' in both the divert rules fixed my problem. Personally I think that should go into the UPDATING file as well. I wouldn't have found it if you hadn't told me! Many thanks, Spil. On Wed, Jul 21, 2010 at 9:08 PM, Spil Oss wrote: > Hi Sergey, > > Has the change from ip to ip4 solved the problem for you? The > documentation states that proto 'ip' is the same as 'all' "Matches any > packet." > > Rule # 60 > =A0 =A0 $cmd 060 skipto 1000 ip6 from any to any > will have already skipped to the ipv6 rules block thus proto 'ip' > should always match remaining packets. > > Meanwhile I found bug 148137 [ipfw] call order of natd and ipfw startup s= cripts > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148137&cat=3Dconf > Don't know if that's directly related, but it may be worth a try to > revert back to the RELENG_8_0 script. > > Will let you now my findings. > > Kind regards, > > Spil. > > > On Wed, Jul 21, 2010 at 2:57 PM, Sergey G Nasonov wrote= : >> Hello Spill, >> >> I have get the same trouble after updating my 8.0 Stable. I thing you ne= ed >> modify some firewall rules. >> >> Please change >> >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound >> >> to >> >> $cmd 100 divert natd ip4 from any to any in via $pif # Mangle inbound >> >> and >> >> $cmd 500 divert natd ip from any to any out via $pif >> >> to >> >> $cmd 500 divert natd ip4 from any to any out via $pif >> >> accordingly. >> >> -- >> >> Best Regards, >> >> Nasonov Sergey > > > On Wed, Jul 21, 2010 at 11:40 AM, Spil Oss wrote: >> Hi, >> >> Testing FreeBSD 8.1 I noticed that I seem to have routing or nat or >> firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC last >> night?) >> - 8.1 booted fine >> - connections from the system itself were fine >> - connections from my jails to the internet were not working >> - connections from my LAN/WLAN to the internet were not working >> Reverting back to 8.0-p2 with the same configuration works fine. >> >> In UPDATING I see that rc.firewall and rc.firewall6 were unified. >> >> Setup is >> - xl0 connected to internet/public IP via dhcp >> - bge0/wlan0(ath0) connected to LAN >> - jails have ip's on bge0 in the same subnet as the LAN >> - allow all from any to any via bge0|wlan0|lo0 >> - NAT using natd >> >> My guess is that something's changed to ipfw that is affecting my >> network settings. Any clues where I went wrong? >> >> Help appreciated/ Kind regards, >> >> Spil. >> >> rc.conf: >> firewall_enable=3D"YES" >> firewall_script=3D"/etc/ipfw.rules" >> >> natd.conf >> interface xl0 >> dynamic yes >> same_ports yes >> # http/https to http jail >> redirect_port tcp 192.168.2.3:80 80 >> redirect_port tcp 192.168.2.3:443 443 >> >> Part of /etc/ipfw.rules >> #!/bin/sh >> cmd=3D"ipfw -q add" >> skip=3D"skipto 500" >> pif=3Dxl0 >> pif6=3Dgif0 >> ext6=3D"2001:dead:beef:1::1" >> ks=3D"keep-state" >> >> ipfw -q -f flush >> >> # Allow internal traffic >> $cmd 002 allow all from any to any via bge0 # exclude LAN traffic >> $cmd 003 allow all from any to any via lo0 =A0# exclude loopback traffic >> $cmd 004 allow all from any to any via wlan0 # exclude WLAN traffic >> $cmd 005 allow all from any to any via bridge0 # exclude WLAN traffic >> $cmd 006 allow all from any to any via tun0 # exclude WLAN traffic >> >> # Allow all encapulated IPv6 to/from tunnel PoP >> $cmd 010 allow ip4 from to me via $pif >> $cmd 010 allow ip4 from me to via $pif >> >> # Black-hole some stuff using tables >> $cmd 050 drop ip from "table(17)" to any in via $pif >> $cmd 050 drop ip from any to "table(17)" out via $pif >> >> # Separate IPv6 rules (no NAT!) >> $cmd 060 skipto 1000 ip6 from any to any >> >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound >> packets from external >> $cmd 101 check-state >> >> # Authorized outbound packets >> $cmd 130 $skip icmp from any to any out via $pif $ks >> $cmd 150 $skip tcp from any to any out via $pif $ks >> $cmd 151 $skip udp from any to any out via $pif $ks >> >> $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks >> >> # Deny all inbound traffic from non-routable reserved address spaces >> $cmd 300 unreach host all from 192.168.0.0/16 =A0to any in via $pif >> #RFC 1918 private IP >> $cmd 301 unreach host all from 172.16.0.0/12 =A0 to any in via $pif >> #RFC 1918 private IP >> $cmd 302 unreach host all from 10.0.0.0/8 =A0 =A0 =A0to any in via $pif >> #RFC 1918 private IP >> $cmd 303 unreach host all from 127.0.0.0/8 =A0 =A0 to any in via $pif = =A0#loopback >> $cmd 304 unreach host all from 0.0.0.0/8 =A0 =A0 =A0 to any in via $pif = =A0#loopback >> $cmd 305 unreach host all from 169.254.0.0/16 =A0to any in via $pif >> #DHCP auto-config >> $cmd 306 unreach host all from 192.0.2.0/24 =A0 =A0to any in via $pif >> #reserved for docs >> $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif =A0#Su= n cluster >> $cmd 308 unreach host all from 224.0.0.0/3 =A0 =A0 to any in via $pif >> #Class D & E multicast >> >> # Deny packets that did not match the dynamic rule table >> #$cmd 330 deny all from any to any frag in via $pif # All late fragments >> #$cmd 332 deny tcp from any to any established in via $pif # Deny ACK >> >> # Authorized inbound packets >> $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply and TTL-= exceeded >> $cmd 420 allow tcp from any to me ssh in via $pif setup $ks >> $cmd 421 allow tcp from any to me smtp in via $pif >> $cmd 422 allow tcp from any to me http in via $pif >> $cmd 423 allow tcp from any to me https in via $pif >> $cmd 424 allow tcp from any to me imaps in via $pif >> >> #$cmd 449 unreach host ip from any to any in via $pif >> $cmd 448 reject log all from any to any in via $pif >> $cmd 449 reject log all from any to any out via $pif >> $cmd 450 reject log ip from any to any >> >> # This is skipto location for outbound stateful rules >> $cmd 500 divert natd ip from any to any out via $pif >> $cmd 510 allow ip from any to any >> > From owner-freebsd-ipfw@FreeBSD.ORG Wed Jul 21 22:12:03 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC7F1106567A; Wed, 21 Jul 2010 22:12:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 842218FC20; Wed, 21 Jul 2010 22:12:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6LMC3Tu053578; Wed, 21 Jul 2010 22:12:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6LMC3hN053574; Wed, 21 Jul 2010 22:12:03 GMT (envelope-from linimon) Date: Wed, 21 Jul 2010 22:12:03 GMT Message-Id: <201007212212.o6LMC3hN053574@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148827: [ipfw] divert broken with in-kernel ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 22:12:03 -0000 Synopsis: [ipfw] divert broken with in-kernel ipfw Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 21 22:11:51 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148827 From owner-freebsd-ipfw@FreeBSD.ORG Thu Jul 22 10:16:14 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92DAC1065672; Thu, 22 Jul 2010 10:16:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 82E448FC16; Thu, 22 Jul 2010 10:16:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o6MAG1Fj014668; Thu, 22 Jul 2010 20:16:02 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 22 Jul 2010 20:16:01 +1000 (EST) From: Ian Smith To: Spil Oss In-Reply-To: Message-ID: <20100722153846.S62748@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1630664149-1279790660=:62748" Content-ID: <20100722194247.N62748@sola.nimnet.asn.au> Cc: freebsd-ipfw@freebsd.org, freebsd-stable@freebsd.org, snasonov@bcc.ru Subject: Re: Changes to ipfw in 8.1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 10:16:14 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1630664149-1279790660=:62748 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20100722194247.L62748@sola.nimnet.asn.au> On Wed, 21 Jul 2010, Spil Oss wrote: > Hi Sergey, > > I'm dumbstruck! > > Switching 'ip' to 'ip4' in both the divert rules fixed my problem. > Personally I think that should go into the UPDATING file as well. I > wouldn't have found it if you hadn't told me! > > Many thanks, > > Spil. This points to a number of issues, not least the effect of people being led to using the currently dreadful IPFW section of the handbook, which contains so many conceptual and factual errors that I really don't know where to begin on a solution .. so I won't discuss that further except as it relates to the actual ruleset you're using. In your just-filed PR http://www.freebsd.org/cgi/query-pr.cgi?pr=148827 you say your ruleset is based on '30.6.5.7 An Example NAT and Stateful Ruleset', so I'm assuming it's broadly based on example #2 there. > On Wed, Jul 21, 2010 at 9:08 PM, Spil Oss wrote: > > Hi Sergey, > > > > Has the change from ip to ip4 solved the problem for you? The > > documentation states that proto 'ip' is the same as 'all' "Matches any > > packet." > > > > Rule # 60 > >     $cmd 060 skipto 1000 ip6 from any to any > > will have already skipped to the ipv6 rules block thus proto 'ip' > > should always match remaining packets. You don't show any rules beyond number 510, so we must take it on faith that you're handling your ip6 traffic appropriately. I don't know much about it, and will be guided by the IPv6 rules lately in rc.firewall. However if natd is barfing on being passed ip6 packets, that should be fixed in natd, which should do nothing with packets it doesn't care about - as it does with ip4 packets not eligible for NAT translation - except to re-enter the firewall at the next higher-numbered rule, which of course relies on sysctl net.inet.ip.fw.one_pass being set to 0. Either that or ipfw should explicitly decline to divert non-ip4 traffic. I don't know whether or how this would also affect ipfw in-kernel nat. If in fact no ip6 packets are being passed to natd as rule 60 indicates, at least for traffic inbound to ipfw, then that is indeed strange, but I suspect that on the outbound pass, using this rather confusing 'skipto 500 .. keep-state' logic, perhaps some outbound ip6 packets may have been being passed to natd .. Could you check to see if it works only changing the _outbound_ divert rule from ip to ip4, leaving the inbound one at 'ip'? If so, this would validate your original theory re rule 60, on the inbound pass. If not, it may be a useful data point for resolving the problem. > > Meanwhile I found bug 148137 [ipfw] call order of natd and ipfw startup scripts > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148137&cat=conf > > Don't know if that's directly related, but it may be worth a try to > > revert back to the RELENG_8_0 script. > > > > Will let you now my findings. Did you try that, to see whether it was an issue? More below .. > > Kind regards, > > > > Spil. > > > > > > On Wed, Jul 21, 2010 at 2:57 PM, Sergey G Nasonov wrote: > >> Hello Spill, > >> > >> I have get the same trouble after updating my 8.0 Stable. I thing you need > >> modify some firewall rules. > >> > >> Please change > >> > >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > >> > >> to > >> > >> $cmd 100 divert natd ip4 from any to any in via $pif # Mangle inbound > >> > >> and > >> > >> $cmd 500 divert natd ip from any to any out via $pif > >> > >> to > >> > >> $cmd 500 divert natd ip4 from any to any out via $pif > >> > >> accordingly. > >> > >> -- > >> > >> Best Regards, > >> > >> Nasonov Sergey > > > > > > On Wed, Jul 21, 2010 at 11:40 AM, Spil Oss wrote: > >> Hi, > >> > >> Testing FreeBSD 8.1 I noticed that I seem to have routing or nat or > >> firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC last > >> night?) > >> - 8.1 booted fine > >> - connections from the system itself were fine > >> - connections from my jails to the internet were not working > >> - connections from my LAN/WLAN to the internet were not working > >> Reverting back to 8.0-p2 with the same configuration works fine. > >> > >> In UPDATING I see that rc.firewall and rc.firewall6 were unified. > >> > >> Setup is > >> - xl0 connected to internet/public IP via dhcp > >> - bge0/wlan0(ath0) connected to LAN > >> - jails have ip's on bge0 in the same subnet as the LAN > >> - allow all from any to any via bge0|wlan0|lo0 The latter point looks problematic, see below. > >> - NAT using natd > >> > >> My guess is that something's changed to ipfw that is affecting my > >> network settings. Any clues where I went wrong? > >> > >> Help appreciated/ Kind regards, > >> > >> Spil. > >> > >> rc.conf: > >> firewall_enable="YES" > >> firewall_script="/etc/ipfw.rules" > >> > >> natd.conf > >> interface xl0 > >> dynamic yes > >> same_ports yes > >> # http/https to http jail > >> redirect_port tcp 192.168.2.3:80 80 > >> redirect_port tcp 192.168.2.3:443 443 > >> > >> Part of /etc/ipfw.rules > >> #!/bin/sh > >> cmd="ipfw -q add" > >> skip="skipto 500" > >> pif=xl0 > >> pif6=gif0 > >> ext6="2001:dead:beef:1::1" > >> ks="keep-state" > >> > >> ipfw -q -f flush > >> > >> # Allow internal traffic > >> $cmd 002 allow all from any to any via bge0 # exclude LAN traffic > >> $cmd 003 allow all from any to any via lo0  # exclude loopback traffic > >> $cmd 004 allow all from any to any via wlan0 # exclude WLAN traffic > >> $cmd 005 allow all from any to any via bridge0 # exclude WLAN traffic > >> $cmd 006 allow all from any to any via tun0 # exclude WLAN traffic There are problems wih this, based on the apparent misunderstanding (by the present IPFW section's author) of how 'via' works when direction (in or out) and/or a specific interface (recv or xmit) is not specified. I'm assuming that apart from lo0, traffic coming in on some or all of bge0, wlan0, bridge0 and tun0 is to be translated by NAT if destined to be going out on the public interface xl0, right? Certainly you've indicated that your jails are on bge0 with 192.168.x.x addresses, but these are local aliases which wouldn't show bge0 as the recv interface: "A packet may not have a receive or transmit interface: packets originating from the local host have no receive interface, while packets destined for the local host have no transmit interface." Let's consider just one initial packet coming in from bge0 from some private LAN address, other than your local jail IPs, that's destined for an outside address and so needs to be NAT'd before transmission. On the inbound pass, the packet comes in on bge0 and so satisfies 'via bge0' so is immediately allowed in, and that's it. That may be ok, as NAT is here only to be performed on the outbound pass, but it could be anything, and there's no protection here against it being spoofed, as opposed to placement of NAT rules in the rc.firewall 'simple' ruleset. So having been allowed in, after kernel routing (but before NAT, as we haven't reached any check-state rule yet) it reenters the firewall for the outbound pass with its xmit interface set to xl0, but with its recv interface still set to bge0. Thus the unqualified 'via bge0' is still true, so this packet is passed immediately, with source address still set to the private LAN address, without having been translated by NAT. As are similarly any packets bound for the outside initially coming in on wlan0, bridge0 or tun0 that originate from other than the local host. This could be obviated by replacing 'via $if' by 'in recv $if' in the rules above, so such packets going out pass through the firewall rules, including setting state for reply packets received on the outside iface. So as is, the rules below are only applied to outbound packets that are NOT received on those interfaces, which doesn't sound like what you'd intend, except packets generated by or destined for the local box. > >> # Allow all encapulated IPv6 to/from tunnel PoP > >> $cmd 010 allow ip4 from to me via $pif > >> $cmd 010 allow ip4 from me to via $pif Taken on faith. > >> # Black-hole some stuff using tables > >> $cmd 050 drop ip from "table(17)" to any in via $pif > >> $cmd 050 drop ip from any to "table(17)" out via $pif > >> > >> # Separate IPv6 rules (no NAT!) > >> $cmd 060 skipto 1000 ip6 from any to any > >> > >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > >> packets from external > >> $cmd 101 check-state > >> > >> # Authorized outbound packets > >> $cmd 130 $skip icmp from any to any out via $pif $ks > >> $cmd 150 $skip tcp from any to any out via $pif $ks > >> $cmd 151 $skip udp from any to any out via $pif $ks > >> > >> $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks > >> > >> # Deny all inbound traffic from non-routable reserved address spaces > >> $cmd 300 unreach host all from 192.168.0.0/16  to any in via $pif > >> #RFC 1918 private IP > >> $cmd 301 unreach host all from 172.16.0.0/12   to any in via $pif > >> #RFC 1918 private IP > >> $cmd 302 unreach host all from 10.0.0.0/8      to any in via $pif > >> #RFC 1918 private IP > >> $cmd 303 unreach host all from 127.0.0.0/8     to any in via $pif  #loopback > >> $cmd 304 unreach host all from 0.0.0.0/8       to any in via $pif  #loopback > >> $cmd 305 unreach host all from 169.254.0.0/16  to any in via $pif > >> #DHCP auto-config > >> $cmd 306 unreach host all from 192.0.2.0/24    to any in via $pif > >> #reserved for docs > >> $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif  #Sun cluster > >> $cmd 308 unreach host all from 224.0.0.0/3     to any in via $pif > >> #Class D & E multicast > >> > >> # Deny packets that did not match the dynamic rule table > >> #$cmd 330 deny all from any to any frag in via $pif # All late fragments The author (here and in other writings) expounds that fragmented packets are necessarily bad, and indicate an attack of some sort. Not in fact so; eg if you were using say zen.spamhaus.org as an RBL you'll be seeing valid fragmented UDP port 53 packets of around 2000 bytes total all day. I gather DNSSEC will also require acceptance of fragmented datagrams. The default rc.firewall rules pass IP frags, and I suggest you do too. > >> #$cmd 332 deny tcp from any to any established in via $pif # Deny ACK > >> > >> # Authorized inbound packets > >> $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply and TTL-exceeded Add icmptype 3 here to pass unreachables including path MTU discovery. > >> $cmd 420 allow tcp from any to me ssh in via $pif setup $ks > >> $cmd 421 allow tcp from any to me smtp in via $pif > >> $cmd 422 allow tcp from any to me http in via $pif > >> $cmd 423 allow tcp from any to me https in via $pif > >> $cmd 424 allow tcp from any to me imaps in via $pif > >> > >> #$cmd 449 unreach host ip from any to any in via $pif > >> $cmd 448 reject log all from any to any in via $pif > >> $cmd 449 reject log all from any to any out via $pif > >> $cmd 450 reject log ip from any to any Security-wise you'd be better off just dropping these using deny than reject (deprecated, equivalent to unreach host), here and above. However I don't wish to let such details obscure the more major issue. > >> > >> # This is skipto location for outbound stateful rules > >> $cmd 500 divert natd ip from any to any out via $pif > >> $cmd 510 allow ip from any to any cheers, Ian --0-1630664149-1279790660=:62748-- From owner-freebsd-ipfw@FreeBSD.ORG Thu Jul 22 18:24:59 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A43D91065677 for ; Thu, 22 Jul 2010 18:24:59 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 748358FC17 for ; Thu, 22 Jul 2010 18:24:59 +0000 (UTC) Received: by pvh1 with SMTP id 1so3669619pvh.13 for ; Thu, 22 Jul 2010 11:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bTiPqU9hxyiD5/4pk8OSN2CJr9o4HCHBbz/RsSRLlMI=; b=rxuuddQjlK7Gw49/YyN9c93fJTc8zrvOi29vcEieOVcIXFgoRQOD7I0298IPSrz3lZ /teVDOxr97km/vNG9LDMHKx8U/XuP/ZcC7NZ92T4uvihOM4MLoTXuhciwXqBsf/lNhKd ChzKRB5fTCNrsBmmiQuqakQU4zxgUlIqegX64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=fKbxBs4kNsgL3HFXUrYR/8qxZk1wIQR5JmzqAjeNhXVYTINwZyiqL4d1ds6lJPcAWO o0qVcTDrk/OsQMnvVabgRvI3I+JRxwE9wXId6BCptPrGtt7rCRPgwa10x8RHpjZh9fQm dXuwnepraBg+dVO53ADfbm1AHEDPklycYRI2k= MIME-Version: 1.0 Received: by 10.114.109.15 with SMTP id h15mr3671352wac.105.1279823098644; Thu, 22 Jul 2010 11:24:58 -0700 (PDT) Received: by 10.229.190.7 with HTTP; Thu, 22 Jul 2010 11:24:58 -0700 (PDT) In-Reply-To: <20100722153846.S62748@sola.nimnet.asn.au> References: <20100722153846.S62748@sola.nimnet.asn.au> Date: Thu, 22 Jul 2010 20:24:58 +0200 Message-ID: From: Spil Oss To: Ian Smith , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Changes to ipfw in 8.1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 18:24:59 -0000 On Thu, Jul 22, 2010 at 12:16 PM, Ian Smith wrote: > > This points to a number of issues, not least the effect of people being > led to using the currently dreadful IPFW section of the handbook, which > contains so many conceptual and factual errors that I really don't know > where to begin on a solution .. so I won't discuss that further except > as it relates to the actual ruleset you're using. I'm not a network admin, and happy that it does what I want at all. My concern is mainly that an upgrade to 8.1 will break many systems. > In your just-filed PR http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148827 > you say your ruleset is based on '30.6.5.7 An Example NAT and Stateful > Ruleset', so I'm assuming it's broadly based on example #2 there. > > =A0> On Wed, Jul 21, 2010 at 9:08 PM, Spil Oss wrote= : > =A0> > Hi Sergey, > =A0> > > =A0> > Has the change from ip to ip4 solved the problem for you? The > =A0> > documentation states that proto 'ip' is the same as 'all' "Matches= any > =A0> > packet." > =A0> > > =A0> > Rule # 60 > =A0> > =A0 =A0 $cmd 060 skipto 1000 ip6 from any to any > =A0> > will have already skipped to the ipv6 rules block thus proto 'ip' > =A0> > should always match remaining packets. > > You don't show any rules beyond number 510, so we must take it on faith > that you're handling your ip6 traffic appropriately. =A0I don't know much > about it, and will be guided by the IPv6 rules lately in rc.firewall. > For completeness ######################## IPv6 rules ################## # Allow the uptime pings from SixXS $cmd 1000 allow icmp6 from 2001:dead:beef:c10::1 to 2001:dead:beef:c10::2 in via $pif6 $cmd 1000 allow icmp6 from me6 to 2001:dead:beef:c10::1 out via $pif6 # Open up all IPv6 #$cmd 006 allow ip6 from any to any via $pif6 $cmd 1100 check-state # Authorized outbound packets $cmd 1160 allow ip6 from any to any out via $pif6 $ks $cmd 1161 allow udp from any to any out via $pif6 $ks $cmd 1162 allow icmp6 from any to any out via $pif6 $ks # Authorized inbound packets $cmd 1450 allow tcp from any to $ext6 dst-port ssh in via $pif6 $cmd 1999 reject log all from any to any in via $pif6 $cmd 1999 reject log all from any to any out via $pif6 $cmd 1999 reject log ip from any to any ######################## end of rules ################## > However if natd is barfing on being passed ip6 packets, that should be > fixed in natd, which should do nothing with packets it doesn't care > about - as it does with ip4 packets not eligible for NAT translation - > except to re-enter the firewall at the next higher-numbered rule, which > of course relies on sysctl net.inet.ip.fw.one_pass being set to 0. That may be an issue.... net.inet.ip.fw.one_pass: 1 > Either that or ipfw should explicitly decline to divert non-ip4 traffic. > I don't know whether or how this would also affect ipfw in-kernel nat. > > If in fact no ip6 packets are being passed to natd as rule 60 indicates, > at least for traffic inbound to ipfw, then that is indeed strange, but I > suspect that on the outbound pass, using this rather confusing 'skipto > 500 .. keep-state' logic, perhaps some outbound ip6 packets may have > been being passed to natd .. > > Could you check to see if it works only changing the _outbound_ divert > rule from ip to ip4, leaving the inbound one at 'ip'? =A0If so, this woul= d > validate your original theory re rule 60, on the inbound pass. =A0If not, > it may be a useful data point for resolving the problem. ipfw add 99 divert natd ip from any to any in via $pif ipfw delete 100 NATting still works ipfw delete 500 ipfw add 500 divert natd ip from any to any out via $pif NATting broken ipfw delete 500 ipfw add 500 divert natd ip from any to any out via $pif NATting works again > > =A0> > Meanwhile I found bug 148137 [ipfw] call order of natd and ipfw st= artup scripts > =A0> > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D148137&cat=3Dconf > =A0> > Don't know if that's directly related, but it may be worth a try t= o > =A0> > revert back to the RELENG_8_0 script. > =A0> > > =A0> > Will let you now my findings. > > Did you try that, to see whether it was an issue? =A0More below .. Sorry, didn't try reverting back to the 8.0 script. The ip -> ip4 change fixed it so I didn't need the other option. > > =A0> > Kind regards, > =A0> > > =A0> > Spil. > =A0> > > =A0> > > =A0> > On Wed, Jul 21, 2010 at 2:57 PM, Sergey G Nasonov wrote: > =A0> >> Hello Spill, > =A0> >> > =A0> >> I have get the same trouble after updating my 8.0 Stable. I thing= you need > =A0> >> modify some firewall rules. > =A0> >> > =A0> >> Please change > =A0> >> > =A0> >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbo= und > =A0> >> > =A0> >> to > =A0> >> > =A0> >> $cmd 100 divert natd ip4 from any to any in via $pif # Mangle inb= ound > =A0> >> > =A0> >> and > =A0> >> > =A0> >> $cmd 500 divert natd ip from any to any out via $pif > =A0> >> > =A0> >> to > =A0> >> > =A0> >> $cmd 500 divert natd ip4 from any to any out via $pif > =A0> >> > =A0> >> accordingly. > =A0> >> > =A0> >> -- > =A0> >> > =A0> >> Best Regards, > =A0> >> > =A0> >> Nasonov Sergey > =A0> > > =A0> > > =A0> > On Wed, Jul 21, 2010 at 11:40 AM, Spil Oss wr= ote: > =A0> >> Hi, > =A0> >> > =A0> >> Testing FreeBSD 8.1 I noticed that I seem to have routing or nat = or > =A0> >> firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC l= ast > =A0> >> night?) > =A0> >> - 8.1 booted fine > =A0> >> - connections from the system itself were fine > =A0> >> - connections from my jails to the internet were not working > =A0> >> - connections from my LAN/WLAN to the internet were not working > =A0> >> Reverting back to 8.0-p2 with the same configuration works fine. > =A0> >> > =A0> >> In UPDATING I see that rc.firewall and rc.firewall6 were unified. > =A0> >> > =A0> >> Setup is > =A0> >> - xl0 connected to internet/public IP via dhcp > =A0> >> - bge0/wlan0(ath0) connected to LAN > =A0> >> - jails have ip's on bge0 in the same subnet as the LAN > =A0> >> - allow all from any to any via bge0|wlan0|lo0 > > The latter point looks problematic, see below. > > =A0> >> - NAT using natd > =A0> >> > =A0> >> My guess is that something's changed to ipfw that is affecting my > =A0> >> network settings. Any clues where I went wrong? > =A0> >> > =A0> >> Help appreciated/ Kind regards, > =A0> >> > =A0> >> Spil. > =A0> >> > =A0> >> rc.conf: > =A0> >> firewall_enable=3D"YES" > =A0> >> firewall_script=3D"/etc/ipfw.rules" > =A0> >> > =A0> >> natd.conf > =A0> >> interface xl0 > =A0> >> dynamic yes > =A0> >> same_ports yes > =A0> >> # http/https to http jail > =A0> >> redirect_port tcp 192.168.2.3:80 80 > =A0> >> redirect_port tcp 192.168.2.3:443 443 > =A0> >> > =A0> >> Part of /etc/ipfw.rules > =A0> >> #!/bin/sh > =A0> >> cmd=3D"ipfw -q add" > =A0> >> skip=3D"skipto 500" > =A0> >> pif=3Dxl0 > =A0> >> pif6=3Dgif0 > =A0> >> ext6=3D"2001:dead:beef:1::1" > =A0> >> ks=3D"keep-state" > =A0> >> > =A0> >> ipfw -q -f flush > =A0> >> > =A0> >> # Allow internal traffic > =A0> >> $cmd 002 allow all from any to any via bge0 # exclude LAN traffic > =A0> >> $cmd 003 allow all from any to any via lo0 =A0# exclude loopback = traffic > =A0> >> $cmd 004 allow all from any to any via wlan0 # exclude WLAN traff= ic > =A0> >> $cmd 005 allow all from any to any via bridge0 # exclude WLAN tra= ffic > =A0> >> $cmd 006 allow all from any to any via tun0 # exclude WLAN traffi= c > > There are problems wih this, based on the apparent misunderstanding (by > the present IPFW section's author) of how 'via' works when direction (in > or out) and/or a specific interface (recv or xmit) is not specified. > > I'm assuming that apart from lo0, traffic coming in on some or all of > bge0, wlan0, bridge0 and tun0 is to be translated by NAT if destined to > be going out on the public interface xl0, right? =A0Certainly you've > indicated that your jails are on bge0 with 192.168.x.x addresses, but > these are local aliases which wouldn't show bge0 as the recv interface: right! bge0, wlan0 and bridge0 should be translated by NAT. I think I almost understand all below. Just can't figure out (yet) why the jails have no problem accessing the internet. Many thanks for this detailed explanation! Will use it to my advantage. > > =A0 =A0"A packet may not have a receive or transmit interface: packets > =A0 =A0originating from the local host have no receive interface, while > =A0 =A0packets destined for the local host have no transmit interface." > > Let's consider just one initial packet coming in from bge0 from some > private LAN address, other than your local jail IPs, that's destined for > an outside address and so needs to be NAT'd before transmission. > > On the inbound pass, the packet comes in on bge0 and so satisfies 'via > bge0' so is immediately allowed in, and that's it. =A0That may be ok, as > NAT is here only to be performed on the outbound pass, but it could be > anything, and there's no protection here against it being spoofed, as > opposed to placement of NAT rules in the rc.firewall 'simple' ruleset. > > So having been allowed in, after kernel routing (but before NAT, as we > haven't reached any check-state rule yet) it reenters the firewall for > the outbound pass with its xmit interface set to xl0, but with its recv > interface still set to bge0. > > Thus the unqualified 'via bge0' is still true, so this packet is passed > immediately, with source address still set to the private LAN address, > without having been translated by NAT. =A0As are similarly any packets > bound for the outside initially coming in on wlan0, bridge0 or tun0 that > originate from other than the local host. > > This could be obviated by replacing 'via $if' by 'in recv $if' in the > rules above, so such packets going out pass through the firewall rules, > including setting state for reply packets received on the outside iface. > > So as is, the rules below are only applied to outbound packets that are > NOT received on those interfaces, which doesn't sound like what you'd > intend, except packets generated by or destined for the local box. > > =A0> >> # Allow all encapulated IPv6 to/from tunnel PoP > =A0> >> $cmd 010 allow ip4 from to me via $pif > =A0> >> $cmd 010 allow ip4 from me to via $pif > > Taken on faith. > > =A0> >> # Black-hole some stuff using tables > =A0> >> $cmd 050 drop ip from "table(17)" to any in via $pif > =A0> >> $cmd 050 drop ip from any to "table(17)" out via $pif > =A0> >> > =A0> >> # Separate IPv6 rules (no NAT!) > =A0> >> $cmd 060 skipto 1000 ip6 from any to any > =A0> >> > =A0> >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbo= und > =A0> >> packets from external > =A0> >> $cmd 101 check-state > =A0> >> > =A0> >> # Authorized outbound packets > =A0> >> $cmd 130 $skip icmp from any to any out via $pif $ks > =A0> >> $cmd 150 $skip tcp from any to any out via $pif $ks > =A0> >> $cmd 151 $skip udp from any to any out via $pif $ks > =A0> >> > =A0> >> $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks > =A0> >> > =A0> >> # Deny all inbound traffic from non-routable reserved address spa= ces > =A0> >> $cmd 300 unreach host all from 192.168.0.0/16 =A0to any in via $p= if > =A0> >> #RFC 1918 private IP > =A0> >> $cmd 301 unreach host all from 172.16.0.0/12 =A0 to any in via $p= if > =A0> >> #RFC 1918 private IP > =A0> >> $cmd 302 unreach host all from 10.0.0.0/8 =A0 =A0 =A0to any in vi= a $pif > =A0> >> #RFC 1918 private IP > =A0> >> $cmd 303 unreach host all from 127.0.0.0/8 =A0 =A0 to any in via = $pif =A0#loopback > =A0> >> $cmd 304 unreach host all from 0.0.0.0/8 =A0 =A0 =A0 to any in vi= a $pif =A0#loopback > =A0> >> $cmd 305 unreach host all from 169.254.0.0/16 =A0to any in via $p= if > =A0> >> #DHCP auto-config > =A0> >> $cmd 306 unreach host all from 192.0.2.0/24 =A0 =A0to any in via = $pif > =A0> >> #reserved for docs > =A0> >> $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif= =A0#Sun cluster > =A0> >> $cmd 308 unreach host all from 224.0.0.0/3 =A0 =A0 to any in via = $pif > =A0> >> #Class D & E multicast > =A0> >> > =A0> >> # Deny packets that did not match the dynamic rule table > =A0> >> #$cmd 330 deny all from any to any frag in via $pif # All late fr= agments > > The author (here and in other writings) expounds that fragmented packets > are necessarily bad, and indicate an attack of some sort. =A0Not in fact > so; eg if you were using say zen.spamhaus.org as an RBL you'll be seeing > valid fragmented UDP port 53 packets of around 2000 bytes total all day. > I gather DNSSEC will also require acceptance of fragmented datagrams. > The default rc.firewall rules pass IP frags, and I suggest you do too. > > =A0> >> #$cmd 332 deny tcp from any to any established in via $pif # Deny= ACK > =A0> >> > =A0> >> # Authorized inbound packets > =A0> >> $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply a= nd TTL-exceeded > > Add icmptype 3 here to pass unreachables including path MTU discovery. > > =A0> >> $cmd 420 allow tcp from any to me ssh in via $pif setup $ks > =A0> >> $cmd 421 allow tcp from any to me smtp in via $pif > =A0> >> $cmd 422 allow tcp from any to me http in via $pif > =A0> >> $cmd 423 allow tcp from any to me https in via $pif > =A0> >> $cmd 424 allow tcp from any to me imaps in via $pif > =A0> >> > =A0> >> #$cmd 449 unreach host ip from any to any in via $pif > =A0> >> $cmd 448 reject log all from any to any in via $pif > =A0> >> $cmd 449 reject log all from any to any out via $pif > =A0> >> $cmd 450 reject log ip from any to any > > Security-wise you'd be better off just dropping these using deny than > reject (deprecated, equivalent to unreach host), here and above. > > However I don't wish to let such details obscure the more major issue. > > =A0> >> > =A0> >> # This is skipto location for outbound stateful rules > =A0> >> $cmd 500 divert natd ip from any to any out via $pif > =A0> >> $cmd 510 allow ip from any to any > > cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Thu Jul 22 18:31:11 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D01F106564A for ; Thu, 22 Jul 2010 18:31:11 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 472F18FC08 for ; Thu, 22 Jul 2010 18:31:11 +0000 (UTC) Received: by gwj23 with SMTP id 23so328583gwj.13 for ; Thu, 22 Jul 2010 11:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:content-type; bh=pevhhusyweZxttM2uiw3BHaFE00zf5lhCHnvPjlpctY=; b=cNZpmy65n10RQiJSgLq96q6r76kk4QDZvCM/QbspLlpLbOVCrY+vR8E7S2Ia5kUpbM W8fXiJlGDPSrCpNcmYsrLrVwqd8RRbTEfK9G2ZehMGZe3H63UY+BPuesTZ9r6UKzzY5W KBxf3LCIsFPBPUxF09VpLxsVEXawpfJyQfjII= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=sY/+onQFLSGln4mztgg92NXnDEhCGU4liq9fJZidjQYPVEvNPC0qGTXo1Hsf5KK0d7 wlzDhYZegRc+qFMPzROocairpQAMM0svkuVqvIRZowyIbUxfkAEP/6qAmV/1VfszlHVa pCt8kee+9doBIuUx9ZuThQ54SqioI/guZHTd0= MIME-Version: 1.0 Received: by 10.224.11.1 with SMTP id r1mr1439067qar.226.1279823470605; Thu, 22 Jul 2010 11:31:10 -0700 (PDT) Received: by 10.229.190.7 with HTTP; Thu, 22 Jul 2010 11:31:10 -0700 (PDT) In-Reply-To: References: <20100722153846.S62748@sola.nimnet.asn.au> Date: Thu, 22 Jul 2010 20:31:10 +0200 Message-ID: From: Spil Oss To: Ian Smith , freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: Changes to ipfw in 8.1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 18:31:11 -0000 Correction ipfw delete 500 ipfw add 500 divert natd ip4 from any to any out via $pif NATting works again From owner-freebsd-ipfw@FreeBSD.ORG Thu Jul 22 18:40:03 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F15CE1065673 for ; Thu, 22 Jul 2010 18:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C79708FC20 for ; Thu, 22 Jul 2010 18:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6MIe3OZ079240 for ; Thu, 22 Jul 2010 18:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6MIe3M4079239; Thu, 22 Jul 2010 18:40:03 GMT (envelope-from gnats) Date: Thu, 22 Jul 2010 18:40:03 GMT Message-Id: <201007221840.o6MIe3M4079239@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Spil Oss Cc: Subject: Re: kern/148827: [ipfw] divert broken with in-kernel ipfw X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Spil Oss List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 18:40:04 -0000 The following reply was made to PR kern/148827; it has been noted by GNATS. From: Spil Oss To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/148827: [ipfw] divert broken with in-kernel ipfw Date: Thu, 22 Jul 2010 20:30:31 +0200 It is only the outbound divert rule that needs to be changed from ip to ip4. # ipfw add 99 divert natd ip from any to any in via $pif # ipfw delete 100 NATting still works # ipfw delete 500 # ipfw add 500 divert natd ip from any to any out via $pif NATting broken # ipfw delete 500 # ipfw add 500 divert natd ip4 from any to any out via $pif NATting works again From owner-freebsd-ipfw@FreeBSD.ORG Sat Jul 24 04:53:03 2010 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DACF6106566C; Sat, 24 Jul 2010 04:53:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B223C8FC0A; Sat, 24 Jul 2010 04:53:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o6O4r39j093289; Sat, 24 Jul 2010 04:53:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o6O4r3v4093285; Sat, 24 Jul 2010 04:53:03 GMT (envelope-from linimon) Date: Sat, 24 Jul 2010 04:53:03 GMT Message-Id: <201007240453.o6O4r3v4093285@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/148885: [ipfw] [patch] ipfw netgraph ignores net.inet.ip.fw.one_pass X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 04:53:03 -0000 Old Synopsis: ipfw netgraph ignores net.inet.ip.fw.one_pass New Synopsis: [ipfw] [patch] ipfw netgraph ignores net.inet.ip.fw.one_pass Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jul 24 04:52:36 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148885 From owner-freebsd-ipfw@FreeBSD.ORG Sat Jul 24 17:23:48 2010 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9CDC1065678 for ; Sat, 24 Jul 2010 17:23:48 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 87EFF8FC0A for ; Sat, 24 Jul 2010 17:23:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o6OHNjvv074745; Sun, 25 Jul 2010 03:23:45 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 25 Jul 2010 03:23:45 +1000 (EST) From: Ian Smith To: Spil Oss In-Reply-To: Message-ID: <20100725020910.B62748@sola.nimnet.asn.au> References: <20100722153846.S62748@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-23540912-1279992225=:62748" Cc: freebsd-ipfw@freebsd.org Subject: Re: Changes to ipfw in 8.1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 17:23:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-23540912-1279992225=:62748 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Thu, 22 Jul 2010, Spil Oss wrote: > On Thu, Jul 22, 2010 at 12:16 PM, Ian Smith wrote: > > > > This points to a number of issues, not least the effect of people being > > led to using the currently dreadful IPFW section of the handbook, which > > contains so many conceptual and factual errors that I really don't know > > where to begin on a solution .. so I won't discuss that further except > > as it relates to the actual ruleset you're using. > > I'm not a network admin, and happy that it does what I want at all. My > concern is mainly that an upgrade to 8.1 will break many systems. A fair enough concern. > > In your just-filed PR http://www.freebsd.org/cgi/query-pr.cgi?pr=148827 > > you say your ruleset is based on '30.6.5.7 An Example NAT and Stateful > > Ruleset', so I'm assuming it's broadly based on example #2 there. > > > >  > On Wed, Jul 21, 2010 at 9:08 PM, Spil Oss wrote: > >  > > Hi Sergey, > >  > > > >  > > Has the change from ip to ip4 solved the problem for you? The > >  > > documentation states that proto 'ip' is the same as 'all' "Matches any > >  > > packet." > >  > > > >  > > Rule # 60 > >  > >     $cmd 060 skipto 1000 ip6 from any to any > >  > > will have already skipped to the ipv6 rules block thus proto 'ip' > >  > > should always match remaining packets. > > > > You don't show any rules beyond number 510, so we must take it on faith > > that you're handling your ip6 traffic appropriately.  I don't know much > > about it, and will be guided by the IPv6 rules lately in rc.firewall. > > > > For completeness > ######################## IPv6 rules ################## > > # Allow the uptime pings from SixXS > $cmd 1000 allow icmp6 from 2001:dead:beef:c10::1 to > 2001:dead:beef:c10::2 in via $pif6 > $cmd 1000 allow icmp6 from me6 to 2001:dead:beef:c10::1 out via $pif6 > > # Open up all IPv6 > #$cmd 006 allow ip6 from any to any via $pif6 > > $cmd 1100 check-state > > # Authorized outbound packets > $cmd 1160 allow ip6 from any to any out via $pif6 $ks > $cmd 1161 allow udp from any to any out via $pif6 $ks > $cmd 1162 allow icmp6 from any to any out via $pif6 $ks I expect ip6 includes all ipv6 protocols, so udp (udp6?) and icmp6 - and tcp6 - will also pass on the first of these rules. If you want separate counts (or options) for different protocols, put the more specific ones first (tcp, udp, icmp etc) then an 'all' or here ip6 last to catch other protocols too. I know nothing about other ipv6-specific protocols. > # Authorized inbound packets > $cmd 1450 allow tcp from any to $ext6 dst-port ssh in via $pif6 > > $cmd 1999 reject log all from any to any in via $pif6 > $cmd 1999 reject log all from any to any out via $pif6 > $cmd 1999 reject log ip from any to any > > ######################## end of rules ################## > > However if natd is barfing on being passed ip6 packets, that should be > > fixed in natd, which should do nothing with packets it doesn't care > > about - as it does with ip4 packets not eligible for NAT translation - > > except to re-enter the firewall at the next higher-numbered rule, which > > of course relies on sysctl net.inet.ip.fw.one_pass being set to 0. > > That may be an issue.... > net.inet.ip.fw.one_pass: 1 Ah, then you'd best add net.inet.ip.fw.one_pass=0 to /etc/sysctl.conf .. > > Either that or ipfw should explicitly decline to divert non-ip4 traffic. > > I don't know whether or how this would also affect ipfw in-kernel nat. > > > > If in fact no ip6 packets are being passed to natd as rule 60 indicates, > > at least for traffic inbound to ipfw, then that is indeed strange, but I > > suspect that on the outbound pass, using this rather confusing 'skipto > > 500 .. keep-state' logic, perhaps some outbound ip6 packets may have > > been being passed to natd .. > > > > Could you check to see if it works only changing the _outbound_ divert > > rule from ip to ip4, leaving the inbound one at 'ip'?  If so, this would > > validate your original theory re rule 60, on the inbound pass.  If not, > > it may be a useful data point for resolving the problem. > > ipfw add 99 divert natd ip from any to any in via $pif > ipfw delete 100 > > NATting still works > > ipfw delete 500 > ipfw add 500 divert natd ip from any to any out via $pif > > NATting broken With your later correction: : ipfw delete 500 : ipfw add 500 divert natd ip4 from any to any out via $pif : : NATting works again So no ip6 packets hit the inbound divert rule as rule 60 bypassed it, but it looks like an ip6 pkt must have hit your outbound divert rule. Adding a 'count ip6 from any to any' just before the outbound divert rule would prove that, one way or the other. Or a 'deny log ip6 ...' or even a 'skipto $somewhere ip6 ...' > >  > > Meanwhile I found bug 148137 [ipfw] call order of natd and ipfw startup scripts > >  > > http://www.freebsd.org/cgi/query-pr.cgi?pr=148137&cat=conf > >  > > Don't know if that's directly related, but it may be worth a try to > >  > > revert back to the RELENG_8_0 script. > >  > > > >  > > Will let you now my findings. > > > > Did you try that, to see whether it was an issue?  More below .. > > Sorry, didn't try reverting back to the 8.0 script. The ip -> ip4 > change fixed it so I didn't need the other option. > > > > >  > > Kind regards, > >  > > > >  > > Spil. > >  > > > >  > > > >  > > On Wed, Jul 21, 2010 at 2:57 PM, Sergey G Nasonov wrote: > >  > >> Hello Spill, > >  > >> > >  > >> I have get the same trouble after updating my 8.0 Stable. I thing you need > >  > >> modify some firewall rules. > >  > >> > >  > >> Please change > >  > >> > >  > >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > >  > >> > >  > >> to > >  > >> > >  > >> $cmd 100 divert natd ip4 from any to any in via $pif # Mangle inbound > >  > >> > >  > >> and > >  > >> > >  > >> $cmd 500 divert natd ip from any to any out via $pif > >  > >> > >  > >> to > >  > >> > >  > >> $cmd 500 divert natd ip4 from any to any out via $pif > >  > >> > >  > >> accordingly. > >  > >> > >  > >> -- > >  > >> > >  > >> Best Regards, > >  > >> > >  > >> Nasonov Sergey > >  > > > >  > > > >  > > On Wed, Jul 21, 2010 at 11:40 AM, Spil Oss wrote: > >  > >> Hi, > >  > >> > >  > >> Testing FreeBSD 8.1 I noticed that I seem to have routing or nat or > >  > >> firewall issues. (csupped RELENG_8_1 which was -RELEASE not -RC last > >  > >> night?) > >  > >> - 8.1 booted fine > >  > >> - connections from the system itself were fine > >  > >> - connections from my jails to the internet were not working > >  > >> - connections from my LAN/WLAN to the internet were not working > >  > >> Reverting back to 8.0-p2 with the same configuration works fine. > >  > >> > >  > >> In UPDATING I see that rc.firewall and rc.firewall6 were unified. > >  > >> > >  > >> Setup is > >  > >> - xl0 connected to internet/public IP via dhcp > >  > >> - bge0/wlan0(ath0) connected to LAN > >  > >> - jails have ip's on bge0 in the same subnet as the LAN > >  > >> - allow all from any to any via bge0|wlan0|lo0 > > > > The latter point looks problematic, see below. > > > >  > >> - NAT using natd > >  > >> > >  > >> My guess is that something's changed to ipfw that is affecting my > >  > >> network settings. Any clues where I went wrong? > >  > >> > >  > >> Help appreciated/ Kind regards, > >  > >> > >  > >> Spil. > >  > >> > >  > >> rc.conf: > >  > >> firewall_enable="YES" > >  > >> firewall_script="/etc/ipfw.rules" > >  > >> > >  > >> natd.conf > >  > >> interface xl0 > >  > >> dynamic yes > >  > >> same_ports yes > >  > >> # http/https to http jail > >  > >> redirect_port tcp 192.168.2.3:80 80 > >  > >> redirect_port tcp 192.168.2.3:443 443 > >  > >> > >  > >> Part of /etc/ipfw.rules > >  > >> #!/bin/sh > >  > >> cmd="ipfw -q add" > >  > >> skip="skipto 500" > >  > >> pif=xl0 > >  > >> pif6=gif0 > >  > >> ext6="2001:dead:beef:1::1" > >  > >> ks="keep-state" > >  > >> > >  > >> ipfw -q -f flush > >  > >> > >  > >> # Allow internal traffic > >  > >> $cmd 002 allow all from any to any via bge0 # exclude LAN traffic > >  > >> $cmd 003 allow all from any to any via lo0  # exclude loopback traffic > >  > >> $cmd 004 allow all from any to any via wlan0 # exclude WLAN traffic > >  > >> $cmd 005 allow all from any to any via bridge0 # exclude WLAN traffic > >  > >> $cmd 006 allow all from any to any via tun0 # exclude WLAN traffic > > > > There are problems wih this, based on the apparent misunderstanding (by > > the present IPFW section's author) of how 'via' works when direction (in > > or out) and/or a specific interface (recv or xmit) is not specified. > > > > I'm assuming that apart from lo0, traffic coming in on some or all of > > bge0, wlan0, bridge0 and tun0 is to be translated by NAT if destined to > > be going out on the public interface xl0, right?  Certainly you've > > indicated that your jails are on bge0 with 192.168.x.x addresses, but > > these are local aliases which wouldn't show bge0 as the recv interface: > > right! bge0, wlan0 and bridge0 should be translated by NAT. > > I think I almost understand all below. Just can't figure out (yet) why > the jails have no problem accessing the internet. Many thanks for this > detailed explanation! Will use it to my advantage. The jails are on your local machine so packets from them 'originate on the local host' as below, so have no recv interface (despite being IP aliases on bge0) and don't appear on the inbound pass at all - they're not routed, so are unaffected by rule 2 (as opposed to packets 'in recv bge0' from or 'out xmit bge0' to your LAN hosts, which are routed). So packets from your jails are being properly NAT'd and state is being set awaiting replies, as they're sent out. Whenever struggling to figure out what's going on, I tend to just stick 'count' rules around sections to log unexpected - or confirm expected - traffic. Defensive programming is testing for what "shouldn't happen". Have a good look through rc.firewall 'simple' ruleset, especially re the placement of nat(d) and antispoofing rules; perhaps that'd help clarify? If in doubt between the handbook section and ipfw(8), trust the latter. HTH, Ian > >    "A packet may not have a receive or transmit interface: packets > >    originating from the local host have no receive interface, while > >    packets destined for the local host have no transmit interface." > > > > Let's consider just one initial packet coming in from bge0 from some > > private LAN address, other than your local jail IPs, that's destined for > > an outside address and so needs to be NAT'd before transmission. > > > > On the inbound pass, the packet comes in on bge0 and so satisfies 'via > > bge0' so is immediately allowed in, and that's it.  That may be ok, as > > NAT is here only to be performed on the outbound pass, but it could be > > anything, and there's no protection here against it being spoofed, as > > opposed to placement of NAT rules in the rc.firewall 'simple' ruleset. > > > > So having been allowed in, after kernel routing (but before NAT, as we > > haven't reached any check-state rule yet) it reenters the firewall for > > the outbound pass with its xmit interface set to xl0, but with its recv > > interface still set to bge0. > > > > Thus the unqualified 'via bge0' is still true, so this packet is passed > > immediately, with source address still set to the private LAN address, > > without having been translated by NAT.  As are similarly any packets > > bound for the outside initially coming in on wlan0, bridge0 or tun0 that > > originate from other than the local host. > > > > This could be obviated by replacing 'via $if' by 'in recv $if' in the > > rules above, so such packets going out pass through the firewall rules, > > including setting state for reply packets received on the outside iface. > > > > So as is, the rules below are only applied to outbound packets that are > > NOT received on those interfaces, which doesn't sound like what you'd > > intend, except packets generated by or destined for the local box. > > > >  > >> # Allow all encapulated IPv6 to/from tunnel PoP > >  > >> $cmd 010 allow ip4 from to me via $pif > >  > >> $cmd 010 allow ip4 from me to via $pif > > > > Taken on faith. > > > >  > >> # Black-hole some stuff using tables > >  > >> $cmd 050 drop ip from "table(17)" to any in via $pif > >  > >> $cmd 050 drop ip from any to "table(17)" out via $pif > >  > >> > >  > >> # Separate IPv6 rules (no NAT!) > >  > >> $cmd 060 skipto 1000 ip6 from any to any > >  > >> > >  > >> $cmd 100 divert natd ip from any to any in via $pif # Mangle inbound > >  > >> packets from external > >  > >> $cmd 101 check-state > >  > >> > >  > >> # Authorized outbound packets > >  > >> $cmd 130 $skip icmp from any to any out via $pif $ks > >  > >> $cmd 150 $skip tcp from any to any out via $pif $ks > >  > >> $cmd 151 $skip udp from any to any out via $pif $ks > >  > >> > >  > >> $cmd 200 allow udp from 10.50.0.1 to me 68 in $ks > >  > >> > >  > >> # Deny all inbound traffic from non-routable reserved address spaces > >  > >> $cmd 300 unreach host all from 192.168.0.0/16  to any in via $pif > >  > >> #RFC 1918 private IP > >  > >> $cmd 301 unreach host all from 172.16.0.0/12   to any in via $pif > >  > >> #RFC 1918 private IP > >  > >> $cmd 302 unreach host all from 10.0.0.0/8      to any in via $pif > >  > >> #RFC 1918 private IP > >  > >> $cmd 303 unreach host all from 127.0.0.0/8     to any in via $pif  #loopback > >  > >> $cmd 304 unreach host all from 0.0.0.0/8       to any in via $pif  #loopback > >  > >> $cmd 305 unreach host all from 169.254.0.0/16  to any in via $pif > >  > >> #DHCP auto-config > >  > >> $cmd 306 unreach host all from 192.0.2.0/24    to any in via $pif > >  > >> #reserved for docs > >  > >> $cmd 307 unreach host all from 204.152.64.0/23 to any in via $pif  #Sun cluster > >  > >> $cmd 308 unreach host all from 224.0.0.0/3     to any in via $pif > >  > >> #Class D & E multicast > >  > >> > >  > >> # Deny packets that did not match the dynamic rule table > >  > >> #$cmd 330 deny all from any to any frag in via $pif # All late fragments > > > > The author (here and in other writings) expounds that fragmented packets > > are necessarily bad, and indicate an attack of some sort.  Not in fact > > so; eg if you were using say zen.spamhaus.org as an RBL you'll be seeing > > valid fragmented UDP port 53 packets of around 2000 bytes total all day. > > I gather DNSSEC will also require acceptance of fragmented datagrams. > > The default rc.firewall rules pass IP frags, and I suggest you do too. > > > >  > >> #$cmd 332 deny tcp from any to any established in via $pif # Deny ACK > >  > >> > >  > >> # Authorized inbound packets > >  > >> $cmd 400 allow icmp from any to any icmptypes 0,11 # echo reply and TTL-exceeded > > > > Add icmptype 3 here to pass unreachables including path MTU discovery. > > > >  > >> $cmd 420 allow tcp from any to me ssh in via $pif setup $ks > >  > >> $cmd 421 allow tcp from any to me smtp in via $pif > >  > >> $cmd 422 allow tcp from any to me http in via $pif > >  > >> $cmd 423 allow tcp from any to me https in via $pif > >  > >> $cmd 424 allow tcp from any to me imaps in via $pif > >  > >> > >  > >> #$cmd 449 unreach host ip from any to any in via $pif > >  > >> $cmd 448 reject log all from any to any in via $pif > >  > >> $cmd 449 reject log all from any to any out via $pif > >  > >> $cmd 450 reject log ip from any to any > > > > Security-wise you'd be better off just dropping these using deny than > > reject (deprecated, equivalent to unreach host), here and above. > > > > However I don't wish to let such details obscure the more major issue. > > > >  > >> > >  > >> # This is skipto location for outbound stateful rules > >  > >> $cmd 500 divert natd ip from any to any out via $pif > >  > >> $cmd 510 allow ip from any to any > > > > cheers, Ian --0-23540912-1279992225=:62748--