From owner-freebsd-ipfw@FreeBSD.ORG Sun Jun 14 15:27:07 2009 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 74A17106564A for ; Sun, 14 Jun 2009 15:27:07 +0000 (UTC) (envelope-from holger.rauch@empic.de) Received: from ox.heitec.net (ox.heitec.net [93.93.253.50]) by mx1.freebsd.org (Postfix) with SMTP id B4D028FC0A for ; Sun, 14 Jun 2009 15:27:06 +0000 (UTC) (envelope-from holger.rauch@empic.de) Received: from ox.heitec.net ([10.100.1.50]) by eSafe SMTP Relay 1243430578; Sun, 14 Jun 2009 17:16:04 +0200 Received: by ox.heitec.net (Postfix, from userid 110) id B946F1A002; Sun, 14 Jun 2009 17:16:03 +0200 (CEST) Received: from siena.er.heitec.net (unknown [10.64.80.14]) by ox.heitec.net (Postfix) with ESMTPSA id B1DAA1A001 for ; Sun, 14 Jun 2009 17:16:03 +0200 (CEST) Received: by siena.er.heitec.net (Postfix, from userid 1000) id 78B481E8C; Sun, 14 Jun 2009 17:16:30 +0200 (CEST) Date: Sun, 14 Jun 2009 17:16:30 +0200 From: Holger Rauch To: freebsd-ipfw@freebsd.org Message-ID: <20090614151630.GA27009@heitec.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Organization: EMPIC GmbH, Werner-von-Siemens-Str. 61, 91052 Erlangen, Germany, Reg. No: 2873 / Fuerth / Germany, CEO / Managing Director: Joerg K. Kottenbrink, WWW: http://www.empic.eu X-ESAFE-STATUS: [esafe] Mail clean X-ESAFE-DETAILS: [esafe] Subject: Questions on "Hide NAT" and 1:1 NAT Scenarios Using IPFW2 insteadof natd 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, 14 Jun 2009 15:27:07 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi to everybody, up to now, I've only seen a working example for "hide NAT" (hiding several = IP addresses belonging to an internal private subnet "behind" an official, ext= ernally accessible IP) based on user space natd from one of my former colleagues. That means I'm new to kernel (IPFW) based NAT and thus asking for help on t= his mailing list since the NAT fragments mentioned below don't work for me as expected = (i.e. I see no IPFW log message and no NAT takes place). I'm referring to a FreeBSD 7.1-STABLE amd64 system with the following kerne= l options compiled in (default policy is deny). The machine acts as a gateway (IP for= warding enabled; no sysctls for layer2 enabled) and has six network interfaces in total=20 (bge0, bge1, em0-3). Two different forms of NAT should take place depending= on whether the packets flow between network interfaces bge0<->bge1 (hide NAT) and bge0= <->em1 (1:1 NAT for a certain set of hosts). For the remaining interface combinati= ons bge0<->em0,em2,em3 no NAT should be performed since they are used to gain a= ccess to other internal subnets represented by private IP addresses. The combinations bge1<->em[0-3] are not permitted (blocked/logged by corresponding IPFW rule= s): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #enable logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=3D100 #limit verbosity options IPFIREWALL_FORWARD #packet destination changes options IPFIREWALL_NAT #ipfw kernel nat support options IPDIVERT #divert sockets options DUMMYNET options IPSTEALTH #support for stealth forwarding options LIBALIAS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D So, at least I shouldn't be missing any relevant kernel options, right?=20 The following NAT rule fragments were taken from a larger firewall #! /bin/sh script, which is structured in the following manner: a) General logging/filtering rules for bogus packets (unsupported private IP addresses, broadcasts, illegal inner<->outer network interface combinations, etc.) number range logging rules: 1000-1499 number range filtering rules: 1500-1999 b) filtering/logging rules with no NAT (bge0<->em0,em2,em3) number range logging rules: 2000-2499 number range filtering rules: 2500-2999 c) 1:1 NAT fragment (see below) fixed rule number: 3000 d) filtering/logging rules to individual hosts for which 1:1 NAT is supposed to be performed number range logging rules: 3001-3499 number range filtering rules: 3500-3999 e) hide NAT fragment (see below) fixed rule number: 4000 f) filtering/logging rules to individual hosts for which hide NAT is supposed to be performed number range logging rules: 4001-4499 number range filtering rules: 4500-4999 OK, here the NAT fragments (inferred from the ipfw man page since I couldn't find a better resource; unfortunately, neither the IPFW HOWTO nor the IPFW advanced supplement HOWTO is of help here): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # 1:1 NAT (intaddr1...intaddr5 <-> extaddr1...extaddr5) ${fwcmd} add 3000 nat 1 all from any to any via em1 ${fwcmd} nat 1 config redirect_addr intaddr1 extaddr1 \ redirect_addr intaddr2 extaddr2 \ redirect_addr intaddr3 extaddr3 \ redirect_addr intaddr4 extaddr4 \ redirect_addr intaddr5 extaddr5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Would the following alternative approach achieve the same (seems slightly more elegant to me)? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D int_nat_hosts=3D"\{ intaddr1,intaddr2,intaddr3,intaddr4,intaddr5 \}" ext_nat_hosts=3D"\{ extaddr1,extaddr2,extaddr3,extaddr4,extaddr5 \}" ${fwcmd} nat 1 config redirect_addr ${int_nat_hosts} ${ext_nat_hosts} # hide NAT (10.51.0.0/16 -> one externally accessible IP address aa.bb.cc.d= d) ${fwcmd} nat 2 config ip aa.bb.cc.dd log deny_in reset same_ports ${fwcmd} add 4000 nat 2 all from any to any via bge1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General questions on both NAT scenarios: - How to debug IPFW-based NAT in general? - Is it OK to use "from any to any" in the ...add nat... rules above or wou= ld you recommend specifying the address ranges explictly? - Would using "skipto" rules be a good alternative here? In case you need additional info, please don't hesitate to ask. Thanks in advance for any help! Kind regards, Holger --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAko1FE4ACgkQbiVtWpZdKQIZGwCfdDqhjuuCfb3zOXnlpP8DTroD iRMAn2k+llk+GAhLkvMK7j/D+ik5dnp1 =J3E4 -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 15 11:06:57 2009 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 3FD501065670 for ; Mon, 15 Jun 2009 11:06:57 +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 2CDD98FC0A for ; Mon, 15 Jun 2009 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5FB6vse076959 for ; Mon, 15 Jun 2009 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5FB6u9F076955 for freebsd-ipfw@FreeBSD.org; Mon, 15 Jun 2009 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Jun 2009 11:06:56 GMT Message-Id: <200906151106.n5FB6u9F076955@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, 15 Jun 2009 11:06:57 -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/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 kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s 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 p kern/115755 ipfw [ipfw] [patch] unify message and add a rule number whe o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule p kern/113388 ipfw [ipfw] [patch] Addition actions with rules within spec o kern/112708 ipfw [ipfw] ipfw is seems to be broken to limit number of c o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou s kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 59 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Thu Jun 18 12:08:18 2009 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 5D63410657B9 for ; Thu, 18 Jun 2009 12:08:18 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D61B18FC14 for ; Thu, 18 Jun 2009 12:08:16 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1MHFGp-00077q-8z for freebsd-ipfw@freebsd.org; Thu, 18 Jun 2009 10:55:03 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Jun 2009 10:55:03 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Jun 2009 10:55:03 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Ivan Voras Date: Thu, 18 Jun 2009 12:54:02 +0200 Lines: 16 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090615) Sender: news Subject: PR kern/117234 - ipfw + ipv6 tcp acks 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, 18 Jun 2009 12:08:28 -0000 Hi, Can someone please review and if possible commit this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=117234 There are multiple versions of the patch in the PR, there is none for -CURRENT. The problem is that, for ipv4, ipfw sends keepalives for TCP connections handled by dynamic rules, while on ipv6 the dynamic rules simply expire after a timeout, causing connections to be broken in a bad way (established TCP packets simply get dropped). I don't know if the patch is the correct way to solve the problem, but it apparently works. From owner-freebsd-ipfw@FreeBSD.ORG Thu Jun 18 14:06:54 2009 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 17EF4106566B for ; Thu, 18 Jun 2009 14:06:54 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-fx0-f206.google.com (mail-fx0-f206.google.com [209.85.220.206]) by mx1.freebsd.org (Postfix) with ESMTP id 998698FC0A for ; Thu, 18 Jun 2009 14:06:53 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by fxm2 with SMTP id 2so119044fxm.43 for ; Thu, 18 Jun 2009 07:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:disposition-notification-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=/l3WX6yNiuFQcvjOzYtSiIGhu274VVoXFQqmWWWK8Kc=; b=xqjADCM11mjJ15DytGLKngmzxt2u90AATT+Fg8mEgMmqArJZe5B8IiBZERftFuw9Ke JXjj6wwqD3R/B1G12YrFikUs8uez7HdXWqXGdELNY+ibbMSMpTKDexV+pjIjuexu/VtV RqpLlxE4tRl/CkFJa1Et/NOdkoFsmI6iBGCgc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:disposition-notification-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=lmlYxrH3gfI9gz2wsH3uWlaltADXPRwQQf7YE65AWz7cVH5fuANtPOwplpzSn1IvQw zyIG+al0lvxb4tT1G7aqfQVvqcv0p2vC8CS3QU2PJcLS5DtDXGM7KK6mVSkL3imVRiHR +m1BAa0/d5DY/ZxndGwWNoyreXKny3Vosmc0s= Received: by 10.204.70.135 with SMTP id d7mr1341169bkj.194.1245332350147; Thu, 18 Jun 2009 06:39:10 -0700 (PDT) Received: from gizmo.nevosoft.local ([195.182.128.54]) by mx.google.com with ESMTPS id y15sm3573785fkd.53.2009.06.18.06.39.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Jun 2009 06:39:09 -0700 (PDT) From: subbsd To: freebsd-ipfw@freebsd.org Date: Thu, 18 Jun 2009 17:39:06 +0400 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906181739.07185.subbsd@gmail.com> Subject: about net.inet.ip.fw.default_to_accept sysctl OID in generic-kernel builds 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, 18 Jun 2009 14:06:54 -0000 Hello maillist In my custom kernel with IPFIREWALL_DEFAULT_TO_ACCEPT, this OID (net.inet.ip.fw.default_to_accept) is present in system and i can control him in loader.conf. I see OID when sysctl(8) execute and when i looks in binary kernel or ipfw.ko: % strings /boot/kernel/ipfw.ko /boot/kernel/kernel | grep net.inet.ip.fw.default_to_accept net.inet.ip.fw.default_to_accept net.inet.ip.fw.default_to_accept (it presents in ipfw.ko and kernel) But ipfw.ko from GENERIC kernel does not produce this OID so, booting machine on GENERIC kernel with FIREWALL and "65535 pass ip from any to any" is not possible. In /usr/src/sys/netinet/ipfw/ip_fw2.c i see: #ifdef SYSCTL_NODE ... SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, default_to_accept, CTLFLAG_RDTUN, &default_to_accept, 0, "Make the default rule accept all packets."); TUNABLE_INT("net.inet.ip.fw.default_to_accept", &default_to_accept); #endif /* SYSCTL_NODE */ What is SYSCTL_NODE and why net.inet.ip.fw.default_to_accept not producing in ipfw.ko without IPFIREWALL_DEFAULT_TO_ACCEPT ? Thanks.