From owner-freebsd-ipfw@FreeBSD.ORG Sun Sep 21 04:02:53 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 938CA16A4BF for ; Sun, 21 Sep 2003 04:02:53 -0700 (PDT) Received: from epita.fr (hermes.epita.fr [163.5.255.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54B5443FE1 for ; Sun, 21 Sep 2003 04:02:52 -0700 (PDT) (envelope-from le-hen_j@epita.fr) Received: from carpediem (carpediem.epita.fr [10.42.42.5]) by epita.fr id h8LB2oZ14381 Sun, 21 Sep 2003 13:02:50 +0200 (CEST) Date: Sun, 21 Sep 2003 13:02:49 +0200 From: jeremie le-hen To: freebsd-ipfw@freebsd.org Message-ID: <20030921110249.GA28474@carpediem.epita.fr> References: <200309201510.h8KFAOxL062601@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200309201510.h8KFAOxL062601@lurza.secnetix.de> User-Agent: Mutt/1.4i cc: Oliver Fromme Subject: Re: ssh/scp filtering, iplen problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2003 11:02:53 -0000 > However, the obvious problem is that scp uses the ssh > protocol, so it's on the same port. So my idea was to > differentiate them by the size of the packets. The scp > packets usually use the full MTU size (1500), while the > interactive ssh packets are typically much smaller. It was my first idea too for traffic scheduling, but when I tried this tricky way I found that when I refreshed the screen or execute "ls -lR", resulting ssh packets where quite enormous (eg. the MSS size) and so they were understood as being scp packets. They were therefore scheduled as the latters, making the ssh session unusable. I told myself that this problem should be quite common and so there were necessarily some efficient workarounds. And then I forsaw that ssh traffic which have a terminal attached to it (eg. interactive ssh traffic) got the "lowdelay" value in its IP TOS field, and the ssh traffic which does not (usually scp or ssh with a command given to be executed instead of a shell) got the "throughput" value. IIRC, only SSH tunnels don't have any TOS value. Finally, supposing you have 100KBit/s as bandwidth, you can use this (in a real world, you would certainly take care about traffic direction) : # scp pipe 1 config bw 90KBit/s add pipe 1 tcp from any to any dst-port 22 iptos throughput add pipe 1 tcp from any to any src-port 22 iptos throughput # ssh pipe 2 config bw 10KBit/s add pipe 1 tcp from any to any dst-port 22 iptos lowdelay add pipe 1 tcp from any to any src-port 22 iptos lowdelay Regards, -- Jeremie LE HEN aka TtZ/TataZ jeremie.le-hen@epita.fr From owner-freebsd-ipfw@FreeBSD.ORG Sun Sep 21 05:53:11 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 829CE16A4B3; Sun, 21 Sep 2003 05:53:11 -0700 (PDT) Received: from unbreakable.homeunix.org (a213-22-54-44.netcabo.pt [213.22.54.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 912DF43FE3; Sun, 21 Sep 2003 05:53:10 -0700 (PDT) (envelope-from sub_0@netcabo.pt) Received: from [192.168.1.2] (unknown [192.168.1.2]) by unbreakable.homeunix.org (unknown) with ESMTP id 6437313CAE; Sun, 21 Sep 2003 13:53:08 +0100 (WEST) From: Mario Freitas To: freebsd-ipfw@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-V4jJ/eJUIauNTyrxyjUh" Message-Id: <1064148796.973.50.camel@suzy.unbreakable.homeunix.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sun, 21 Sep 2003 13:53:16 +0100 cc: freebsd-hackers@freebsd.org Subject: jails & ipfw + nat X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: sub_0@netcabo.pt List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2003 12:53:11 -0000 --=-V4jJ/eJUIauNTyrxyjUh Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, I recently configured a jail on a FreeBSD gateway doing nat for the interface alias (the jail address, say 192.168.J.J). I tried with natd and ipnat too. However there are some problems I still do not understand. First when I added "nameserver 192.168.X.X" (the nameserver running outside the jail environment) to the jail, every query to the name server is made via the loopback interface instead of the internal interface, or $intif (where I have 192.168.X.X plus 192.168.J.J). Shouldn't the packet travel(virtually) via the $intif interface (as if the request was coming from any machine on the LAN)? Also, the packets are travelling through the loopback interface, where bind _is not_ listening :) (another weird behaviour?) Second, I've tried using, unsuccessfully, many ipfw rules so any user inside the jail environment can establish statefully any tcp connection to the internet. What I do not understand is why the request does not (virtually) come through $intif (192.168.J.J). Inside the jail, after executing telnet www.google.com 80, tcpdump -i $intif(outside the jail) shows nothing, but tcpdump -i $extif(also outside) shows packets coming from www.google.com:80 to $extip, both in natd and ipnat cases: ipfw logs the packet being denied tcp from www.google.com:80 to $extip in via $extif (keep-state is not triggered). Any clarification would be appreciated. Sincerely, --=20 M=E1rio Freitas (sub_0@netcabo.pt) N=FAcleo Portugu=EAs de FreeBSD (NPF) --=-V4jJ/eJUIauNTyrxyjUh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQA/bZ88mOO46MB/5oURAoXfAKCE9LWe65Ne4t7LpWQ1uUdi0hS5YwCgsr5y vp8WuM/g18zTFsy9O57gsuc= =tUx2 -----END PGP SIGNATURE----- --=-V4jJ/eJUIauNTyrxyjUh-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 22 11:02:21 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BA7E16A4BF for ; Mon, 22 Sep 2003 11:02:21 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 659734400D for ; Mon, 22 Sep 2003 11:01:58 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h8MI1wFY010853 for ; Mon, 22 Sep 2003 11:01:58 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h8MI1wUp010841 for ipfw@freebsd.org; Mon, 22 Sep 2003 11:01:58 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 22 Sep 2003 11:01:58 -0700 (PDT) Message-Id: <200309221801.h8MI1wUp010841@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2003 18:02:21 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/03/23] kern/50216 ipfw kernel panic on 5.0-current when use ipfw 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu f [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2002/12/27] kern/46564 ipfw IPFilter and IPFW processing order is not o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/03/12] bin/49959 ipfw ipfw tee port rule skips parsing next rul o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/08/25] kern/55984 ipfw [patch] time based firewalling support fo 9 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 22 16:07:50 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 793CA16A4B3 for ; Mon, 22 Sep 2003 16:07:50 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBED843FE1 for ; Mon, 22 Sep 2003 16:07:49 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.3) with ESMTP id h8MN7isd061911; Mon, 22 Sep 2003 16:07:44 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id h8MN7id6061910; Mon, 22 Sep 2003 16:07:44 -0700 (PDT) (envelope-from rizzo) Date: Mon, 22 Sep 2003 16:07:44 -0700 From: Luigi Rizzo To: ipfw@freebsd.org Message-ID: <20030922160744.A61711@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: [PATCH FOR REVIEW] layer2 ipfw 'fwd' support X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2003 23:07:50 -0000 hi, for those interested in using ipfw 'fwd' instructions in a bridge (e.g. to create a transparent proxy with a bridge) here is a patch to try for ip_fw2.c (and a trivial one-line change in ip_input.c) The change to ip_input.c matches more closely what the comment says: if the packet is tagged by the firewall as 'PACKET_TAG_IPFORWARD' than you skip the pass through the firewall, but still check to see where the packet goes. The ip_fw2.c change does the following: when the bridge detects a layer2 packet, it passes it to ip_input() [!!!layering violation!!!] with a proper tag so that the packet is subject to the same processing it would have in a router. [BTW i believe the same approach could be used to implement 'divert' within a bridge if we only care for IP packets -- i.e. we tag the packet and pass it to the upper layer] The usual restrictions apply -- if you 'forward' to another box then it must be on the same subnet as one of the interfaces of the middlebox, because IP addresses are unchanged. Also, despite the fact you are doing the forwarding on a bridge, if the packet must go out you need to set net.inet.ip.forwarding=1 because the forwarding is done at layer 3. ------------------------------- So, QUICK USAGE INSTRUCTIONS: sample topology: rl0 rl1 [clients]------[bridge]--+----[rest of the world]] | +----[proxy] on clients: no configuration necessary, as the proxy is transparent! on bridge: sysctl net.link.ether.bridge_cfg="rl0 rl1" sysctl net.link.ether.bridge_ipfw=1 sysctl net.link.ether.bridge=1 sysctl net.inet.ip.forwarding=1 ipfw add forward proxy proto tcp from any to any 80 on proxy: ipfw add forward localhost,8080 tcp from not me to any 80 ------------------------------- cheers luigi Index: ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.6.2.16 diff -u -r1.6.2.16 ip_fw2.c --- ip_fw2.c 17 Jul 2003 06:03:39 -0000 1.6.2.16 +++ ip_fw2.c 22 Sep 2003 22:21:38 -0000 @@ -1977,12 +2022,33 @@ goto done; case O_FORWARD_IP: +#if 0 if (args->eh) /* not valid on layer2 pkts */ break; +#endif if (!q || dyn_dir == MATCH_FORWARD) args->next_hop = &((ipfw_insn_sa *)cmd)->sa; retval = 0; + if (args->eh) { + struct m_hdr tag; + + if (hlen == 0) /* non IP */ + break; + /* + * tag with PACKET_TAG_IPFORWARD + * call ip_input() (need ip_forwarding=1 + * if this has to go out) + * mark packet as comsumed by the firewall + */ + tag.mh_type = MT_TAG; + tag.mh_flags = PACKET_TAG_IPFORWARD; + tag.mh_data = (caddr_t)args->next_hop; + tag.mh_next = m; + args->m = NULL; + retval = IP_FW_PORT_DENY_FLAG; + ip_input((struct mbuf *)&tag); + } goto done; default: Index: ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.130.2.53 diff -u -r1.130.2.53 ip_input.c --- ip_input.c 23 Jun 2003 17:53:50 -0000 1.130.2.53 +++ ip_input.c 22 Sep 2003 22:23:23 -0000 @@ -462,7 +462,7 @@ * skip the firewall a second time */ if (args.next_hop) - goto ours; + goto pass; /* XXX was 'ours' */ args.m = m; i = ip_fw_chk_ptr(&args); From owner-freebsd-ipfw@FreeBSD.ORG Thu Sep 25 01:08:33 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDB7916A4B3; Thu, 25 Sep 2003 01:08:33 -0700 (PDT) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 071A34401E; Thu, 25 Sep 2003 01:08:32 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Sep 2003 10:05:29 +0200 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F07DF43@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: verrevpath - denies local multicast. Is this intended? Thread-Index: AcNzaNX86Vb648MDRommVySnKLYSBgP0qrbA From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Crist J. Clark" cc: freebsd-ipfw@freebsd.org Subject: RE: verrevpath - denies local multicast. Is this intended? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2003 08:08:33 -0000 > The _only_ thing it does is check that the interface a packet arrives > on is the same interface that it would route out of to reach=20 > the source > address of the packet. All that matters in this case is where > 80.86.140.54 gets routed to. > --=20 Have had some mail problems lately and havent been able to respond, so i = try again. verrevpath does not drop multicast packets, except for locally generated = packets that=20 are looped back into the interface. But, those are the packets that it = logs and drops. -- Sten