From owner-freebsd-pf@FreeBSD.ORG Mon Nov 3 11:06:57 2008 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F32A106564A for ; Mon, 3 Nov 2008 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 3D0918FC1D for ; Mon, 3 Nov 2008 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 mA3B6vO8010991 for ; Mon, 3 Nov 2008 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 mA3B6u5O010987 for freebsd-pf@FreeBSD.org; Mon, 3 Nov 2008 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Nov 2008 11:06:56 GMT Message-Id: <200811031106.mA3B6u5O010987@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2008 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/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o conf/127511 pf [patch] /usr/sbin/authpf: add authpf folders to BSD.ro o kern/127439 pf [pf] deadlock in pf o kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/82271 pf [pf] cbq scheduler cause bad latency 24 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Nov 3 17:27:14 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21B60106568F for ; Mon, 3 Nov 2008 17:27:14 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE9F8FC21 for ; Mon, 3 Nov 2008 17:27:13 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mA363O8b008780 for ; Mon, 3 Nov 2008 17:03:24 +1100 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mA363LK0010362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Nov 2008 17:03:22 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mA363Lhs045510; Mon, 3 Nov 2008 17:03:21 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mA363LGE045509; Mon, 3 Nov 2008 17:03:21 +1100 (EST) (envelope-from peter) Date: Mon, 3 Nov 2008 17:03:21 +1100 From: Peter Jeremy To: Ermal =?iso-8859-1?Q?Lu=E7i?= Message-ID: <20081103060321.GA45414@server.vk2pj.dyndns.org> References: <9a542da30710161409o4732a77bybdf4ba35d7491bb@mail.gmail.com> <200710171043.08126.max@love2party.net> <9a542da30710211232v4d3c930fg8ea778a12f3f16cb@mail.gmail.com> <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: [PATCH] PF+dummynet X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2008 17:27:14 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Oct-27 19:45:59 +0000, Ermal Lu=E7i wrote: >Attached is the patch against -CURRENT for integrating PF with dummynet! > >It gives full dummynet support in pf.conf syntax and removes dummynet >depndency to ipfw. I've recently found this and applied it to 7.1-PRERELEASE. There were a few rejects and a couple of printf format problems which were all quite easy to fix. I also found an incorrect getopt() string in pfctl, incorrect PLR definition, and an uninitialised dnflow variable. Actually using it presents some more problems. Firstly, if you have ipfw in the kernel then dummynet packets appear to loop indefinitely. Disabling ipfw fixed this (I had built ipfw into the kernel incase I couldn't get pf+dummy to work). The above left me with wierd delays and incorrect packet counts on the rules. Further sleuthing shows that I'm falling foul of the state rules that pf is creating - though the behaviour is still wierd. Given the following: dnpipe 128 bandwidth 2Mb delay 500 queue 64KB dnpipe 136 bandwidth 2Mb delay 500 queue 64KB r1) pass in quick on vlan128 from any to 192.168.136.0/22 dnpipe 128 r2) pass in quick on vlan136 from any to 192.168.128.0/22 dnpipe 136 I get the following: t0 ICMP ECHO REQ a->b -> match r1: pass to pipe 128 (delay 500msec), create state s1 t+.5s -> ICMP ECHO REQ a->b t+.5s <- ICMP ECHO RESP b->a match r2: pass to pipe 136 (delay 500msec), create state s2 match s1: pass to pipe 128 (delay 500msec) t+1.5s ICMP ECHO RESP b->a <- t2 ICMP ECHO REQ a->b -> match s1: pass to pipe 128 (delay 500msec) match s2: pass to pipe 136 (delay 500msec) t2+1s -> ICMP ECHO REQ a->b t2+1s <- ICMP ECHO RESP b->a match s2: pass to pipe 136 (delay 500msec) match s1: pass to pipe 128 (delay 500msec) t2+2s ICMP ECHO RESP b->a <- I managed to fix ICMP by testing that the rule direction matches the packet direction before passing it to dummynet. Unfortunately, this means that TCP only goes through dummynet in one direction (since TCP only has a single state entry). I think the duplicate ICMP state entry is a bug in pf. And the dummynet patches need to support two pipes (one for each direction). I am still looking into this. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkOlCkACgkQ/opHv/APuIdDegCglsBa2q7OY5emhmD6oTz3ZP7Y 9YUAnR7u3ankRApRO4/cAlYzxq6MjsZ6 =b1p9 -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 09:33:49 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 157921065674 for ; Tue, 4 Nov 2008 09:33:49 +0000 (UTC) (envelope-from mk@adminlife.net) Received: from mx.adminlife.net (mx.adminlife.net [85.214.17.98]) by mx1.freebsd.org (Postfix) with ESMTP id CBEEB8FC1D for ; Tue, 4 Nov 2008 09:33:48 +0000 (UTC) (envelope-from mk@adminlife.net) Received: from [192.168.0.51] (p54881D2F.dip0.t-ipconnect.de [84.136.29.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matthias@adminlife.net) by mx.adminlife.net (Postfix) with ESMTPSA id BF5A1125403 for ; Tue, 4 Nov 2008 10:14:58 +0100 (CET) Message-ID: <491012AE.7000409@adminlife.net> Date: Tue, 04 Nov 2008 10:15:26 +0100 From: Matthias Kellermann User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: freebsd-pf@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 09:33:49 -0000 Hi list, I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in a local network and want to forward one port from host a to host b. host a is the pf host. This is the rule to redirect traffic from host a to b: rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state If I try to get a telnet connection from my client 192.168.0.51 the connection gets stuck and nothing happens. This is the output of tcpdump on the pflog0 interface: # tcpdump -netttvvi pflog0 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > 192.168.0.10.23: [|tcp] 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] Anybody has an idea whats wrong here? Regards, Matthias From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 09:38:08 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C83311065672 for ; Tue, 4 Nov 2008 09:38:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 72C048FC14 for ; Tue, 4 Nov 2008 09:38:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA01.westchester.pa.mail.comcast.net with comcast id axap1a0070cZkys51xe7bz; Tue, 04 Nov 2008 09:38:07 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA10.westchester.pa.mail.comcast.net with comcast id axe01a00E2P6wsM3Wxe198; Tue, 04 Nov 2008 09:38:07 +0000 X-Authority-Analysis: v=1.0 c=1 a=T2B_cOh0iMAA:10 a=nl8DGsr-ROMA:10 a=QycZ5dHgAAAA:8 a=SM0CpC2kzljQxVL6d0MA:9 a=0nkXmo7RI8iCSUzaDxAA:7 a=T4eI4mkpxv4E9J8pAHCeKuqT_eIA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 53034C9419; Tue, 4 Nov 2008 01:38:00 -0800 (PST) Date: Tue, 4 Nov 2008 01:38:00 -0800 From: Jeremy Chadwick To: Matthias Kellermann Message-ID: <20081104093800.GA43676@icarus.home.lan> References: <491012AE.7000409@adminlife.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <491012AE.7000409@adminlife.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 09:38:08 -0000 On Tue, Nov 04, 2008 at 10:15:26AM +0100, Matthias Kellermann wrote: > Hi list, > > I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). > > I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in > a local network and want to forward one port from host a to host b. > > host a is the pf host. This is the rule to redirect traffic from host a > to b: > > rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 > pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state > > If I try to get a telnet connection from my client 192.168.0.51 the > connection gets stuck and nothing happens. This is the output of tcpdump > on the pflog0 interface: > > # tcpdump -netttvvi pflog0 > 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > > 192.168.0.10.23: [|tcp] > 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, > offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > > 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] > > Anybody has an idea whats wrong here? This is not a pf problem. tcpdump's snaplen defaults to 56 bytes, which is too small when reading from pflog. Use the -s flag to increase the snaplen to 256 bytes, for example. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 09:52:11 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 708821065672 for ; Tue, 4 Nov 2008 09:52:11 +0000 (UTC) (envelope-from mk@adminlife.net) Received: from mx.adminlife.net (mx.adminlife.net [85.214.17.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9558FC20 for ; Tue, 4 Nov 2008 09:52:10 +0000 (UTC) (envelope-from mk@adminlife.net) Received: from [192.168.0.51] (p54881D2F.dip0.t-ipconnect.de [84.136.29.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matthias@adminlife.net) by mx.adminlife.net (Postfix) with ESMTPSA id E492C125403; Tue, 4 Nov 2008 10:51:40 +0100 (CET) Message-ID: <49101B48.2060704@adminlife.net> Date: Tue, 04 Nov 2008 10:52:08 +0100 From: Matthias Kellermann User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Jeremy Chadwick References: <491012AE.7000409@adminlife.net> <20081104093800.GA43676@icarus.home.lan> In-Reply-To: <20081104093800.GA43676@icarus.home.lan> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 09:52:11 -0000 Jeremy Chadwick wrote: > On Tue, Nov 04, 2008 at 10:15:26AM +0100, Matthias Kellermann wrote: >> # tcpdump -netttvvi pflog0 >> 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, >> offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > >> 192.168.0.10.23: [|tcp] >> 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, >> offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > >> 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] >> >> Anybody has an idea whats wrong here? > > This is not a pf problem. tcpdump's snaplen defaults to 56 bytes, which > is too small when reading from pflog. Use the -s flag to increase the > snaplen to 256 bytes, for example. > Thanks Jeremy. Did that. This is the output of tcdump after increasing the snaplen to 256 bytes: # tcpdump -s 256 -netttvvi pflog0 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 23993, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.43758 > 192.168.0.10.23: S, cksum 0xeb13 (correct), 3072328535:3072328535(0) win 5840 000319 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 22314, offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.43758 > 192.168.0.10.23: S, cksum 0x4553 (correct), 108273612:108273612(0) win 0 I still have no clue whats going wrong here. Regards, Matthias From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 09:57:49 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5820106567B for ; Tue, 4 Nov 2008 09:57:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 99BFF8FC0A for ; Tue, 4 Nov 2008 09:57:49 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id axxB1a0050QkzPwA4xxpAZ; Tue, 04 Nov 2008 09:57:49 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id axxo1a0052P6wsM8Nxxokq; Tue, 04 Nov 2008 09:57:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=T2B_cOh0iMAA:10 a=nl8DGsr-ROMA:10 a=QycZ5dHgAAAA:8 a=hS0_rkcWputuvXv1jKgA:9 a=8i6Y-82Ne3fWIvDrRJAA:7 a=8nvb05qNahQEaUJbPfAdvnoI8v8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 15E44C9419; Tue, 4 Nov 2008 01:57:48 -0800 (PST) Date: Tue, 4 Nov 2008 01:57:48 -0800 From: Jeremy Chadwick To: Matthias Kellermann Message-ID: <20081104095748.GA44045@icarus.home.lan> References: <491012AE.7000409@adminlife.net> <20081104093800.GA43676@icarus.home.lan> <49101B48.2060704@adminlife.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49101B48.2060704@adminlife.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 09:57:49 -0000 On Tue, Nov 04, 2008 at 10:52:08AM +0100, Matthias Kellermann wrote: > Jeremy Chadwick wrote: > > On Tue, Nov 04, 2008 at 10:15:26AM +0100, Matthias Kellermann wrote: > >> # tcpdump -netttvvi pflog0 > >> 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, > >> offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > > >> 192.168.0.10.23: [|tcp] > >> 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, > >> offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > > >> 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] > >> > >> Anybody has an idea whats wrong here? > > > > This is not a pf problem. tcpdump's snaplen defaults to 56 bytes, which > > is too small when reading from pflog. Use the -s flag to increase the > > snaplen to 256 bytes, for example. > > > > Thanks Jeremy. Did that. This is the output of tcdump after increasing > the snaplen to 256 bytes: > > # tcpdump -s 256 -netttvvi pflog0 > 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 23993, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.43758 > > 192.168.0.10.23: S, cksum 0xeb13 (correct), 3072328535:3072328535(0) win > 5840 > 000319 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 22314, > offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.43758 > > 192.168.0.10.23: S, cksum 0x4553 (correct), 108273612:108273612(0) win 0 > > > I still have no clue whats going wrong here. Try changing "synproxy state" to "keep state", and see if you have the same problem. Note that you may need to reset your state table after changing this rule (see pfctl -k). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 10:23:12 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25507106567A; Tue, 4 Nov 2008 10:23:12 +0000 (UTC) (envelope-from mk@adminlife.net) Received: from mx.adminlife.net (mx.adminlife.net [85.214.17.98]) by mx1.freebsd.org (Postfix) with ESMTP id D716B8FC1B; Tue, 4 Nov 2008 10:23:11 +0000 (UTC) (envelope-from mk@adminlife.net) Received: from [192.168.0.51] (p54881D2F.dip0.t-ipconnect.de [84.136.29.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matthias@adminlife.net) by mx.adminlife.net (Postfix) with ESMTPSA id A03BB125403; Tue, 4 Nov 2008 11:22:41 +0100 (CET) Message-ID: <4910228C.3020400@adminlife.net> Date: Tue, 04 Nov 2008 11:23:08 +0100 From: Matthias Kellermann User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Jeremy Chadwick References: <491012AE.7000409@adminlife.net> <20081104093800.GA43676@icarus.home.lan> <49101B48.2060704@adminlife.net> <20081104095748.GA44045@icarus.home.lan> In-Reply-To: <20081104095748.GA44045@icarus.home.lan> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 10:23:12 -0000 Jeremy Chadwick wrote: > Try changing "synproxy state" to "keep state", and see if you have the > same problem. Note that you may need to reset your state table after > changing this rule (see pfctl -k). Ok, I tried that. Here is the result: # tcpdump -s 256 -netttvvi pflog0 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35529, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x5fae (correct), 3300997001:3300997001(0) win 5840 2. 998190 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35530, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x5cc0 (correct), 3300997001:3300997001(0) win 5840 6. 000214 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35531, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x56e4 (correct), 3300997001:3300997001(0) win 5840 12. 000425 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35532, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x4b2c (correct), 3300997001:3300997001(0) win 5840 Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 424191065675 for ; Tue, 4 Nov 2008 10:25:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id DD2028FC08 for ; Tue, 4 Nov 2008 10:25:37 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id ayQc1a0030QkzPwAAyRdBB; Tue, 04 Nov 2008 10:25:37 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id ayRc1a0042P6wsM8NyRcxe; Tue, 04 Nov 2008 10:25:36 +0000 X-Authority-Analysis: v=1.0 c=1 a=T2B_cOh0iMAA:10 a=nl8DGsr-ROMA:10 a=QycZ5dHgAAAA:8 a=SEfSj_MgGtjgpgcXghsA:9 a=Q-c_3rMwE1tgFwk7Rme04cbf9bUA:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 0265EC9419; Tue, 4 Nov 2008 02:25:35 -0800 (PST) Date: Tue, 4 Nov 2008 02:25:35 -0800 From: Jeremy Chadwick To: Matthias Kellermann Message-ID: <20081104102535.GA44596@icarus.home.lan> References: <491012AE.7000409@adminlife.net> <20081104093800.GA43676@icarus.home.lan> <49101B48.2060704@adminlife.net> <20081104095748.GA44045@icarus.home.lan> <4910228C.3020400@adminlife.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4910228C.3020400@adminlife.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 10:25:38 -0000 On Tue, Nov 04, 2008 at 11:23:08AM +0100, Matthias Kellermann wrote: > Jeremy Chadwick wrote: > > Try changing "synproxy state" to "keep state", and see if you have the > > same problem. Note that you may need to reset your state table after > > changing this rule (see pfctl -k). > > Ok, I tried that. Here is the result: > > # tcpdump -s 256 -netttvvi pflog0 > 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35529, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > > 192.168.0.10.23: S, cksum 0x5fae (correct), 3300997001:3300997001(0) win > 5840 > 2. 998190 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35530, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > > 192.168.0.10.23: S, cksum 0x5cc0 (correct), 3300997001:3300997001(0) win > 5840 > 6. 000214 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 35531, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.38439 > > 192.168.0.10.23: S, cksum 0x56e4 (correct), 3300997001:3300997001(0) win > 5840 > 12. 000425 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id > 35532, offset 0, flags [DF], proto TCP (6), length 60) > 192.168.0.51.38439 > 192.168.0.10.23: S, cksum 0x4b2c (correct), > 3300997001:3300997001(0) win 5840 0,nop,wscale 6 > > If I stop the connection attempts from the client the tcpdump output > stops too. Others will have to assist. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 10:39:17 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9F4D106568C for ; Tue, 4 Nov 2008 10:39:17 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id 78DB48FC1B for ; Tue, 4 Nov 2008 10:39:17 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-033-030.pools.arcor-ip.net [88.66.33.30]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1KxJJa2Wlk-0003ow; Tue, 04 Nov 2008 11:39:16 +0100 Received: (qmail 10874 invoked from network); 4 Nov 2008 10:39:10 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 4 Nov 2008 10:39:10 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Tue, 4 Nov 2008 11:39:09 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <491012AE.7000409@adminlife.net> In-Reply-To: <491012AE.7000409@adminlife.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811041139.10125.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18JFEXmiFofyP1yN5q64TLdCmw2yOldDbgkL7Q vgdt0CDhJeziK+H9Oixf+lem+YAI1sUWEDVpjb6/fcQmEnojc2 ITdarfLKLg4xAa5Y2z8bw== Cc: Subject: Re: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 10:39:18 -0000 On Tuesday 04 November 2008 10:15:26 Matthias Kellermann wrote: > I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). > > I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in > a local network and want to forward one port from host a to host b. > > host a is the pf host. This is the rule to redirect traffic from host a > to b: > > rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 > pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state > > If I try to get a telnet connection from my client 192.168.0.51 the > connection gets stuck and nothing happens. This is the output of tcpdump > on the pflog0 interface: > > # tcpdump -netttvvi pflog0 > 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, > offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > > 192.168.0.10.23: [|tcp] > 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, > offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > > 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] > > Anybody has an idea whats wrong here? redirection only works if your pf box sees both directions of the connection. In your case, however, 192.168.0.10 probably knows how to contact 192.168.0.51 directly. So what happens is: .51 -> SYN (src=.51,dst=.250) -> pf -> SYN (src=.51,dst=.10) -> .10 <---------------------------- SYN/ACK (src=.10,dst=.51) <- But .51 is waiting for a SYN/ACK from .250. You can solve this by either: - moving .10 into a separate LAN for which the pf box is the default gw - userland reflection (e.g. nc(1) from inetd(8)) - having your clients connect to the correct box in the first place (split horizon DNS etc.) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 15:48:33 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 426681065689 for ; Tue, 4 Nov 2008 15:48:33 +0000 (UTC) (envelope-from mk@adminlife.net) Received: from mx.adminlife.net (mx.adminlife.net [85.214.17.98]) by mx1.freebsd.org (Postfix) with ESMTP id 016C58FC1E for ; Tue, 4 Nov 2008 15:48:32 +0000 (UTC) (envelope-from mk@adminlife.net) Received: from [192.168.0.51] (p54881D2F.dip0.t-ipconnect.de [84.136.29.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matthias@adminlife.net) by mx.adminlife.net (Postfix) with ESMTPSA id 885A5125403; Tue, 4 Nov 2008 16:48:03 +0100 (CET) Message-ID: <49106ECF.4080803@adminlife.net> Date: Tue, 04 Nov 2008 16:48:31 +0100 From: Matthias Kellermann User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Max Laier References: <491012AE.7000409@adminlife.net> <200811041139.10125.max@love2party.net> In-Reply-To: <200811041139.10125.max@love2party.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 15:48:33 -0000 Max Laier wrote: > On Tuesday 04 November 2008 10:15:26 Matthias Kellermann wrote: >> I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). >> >> I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in >> a local network and want to forward one port from host a to host b. >> >> host a is the pf host. This is the rule to redirect traffic from host a >> to b: >> >> rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 >> pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state >> >> If I try to get a telnet connection from my client 192.168.0.51 the >> connection gets stuck and nothing happens. This is the output of tcpdump >> on the pflog0 interface: >> >> # tcpdump -netttvvi pflog0 >> 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, >> offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > >> 192.168.0.10.23: [|tcp] >> 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, >> offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > >> 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] >> >> Anybody has an idea whats wrong here? > > redirection only works if your pf box sees both directions of the connection. > In your case, however, 192.168.0.10 probably knows how to contact 192.168.0.51 > directly. So what happens is: > > .51 -> SYN (src=.51,dst=.250) -> pf -> SYN (src=.51,dst=.10) -> .10 > > <---------------------------- SYN/ACK (src=.10,dst=.51) <- > > But .51 is waiting for a SYN/ACK from .250. You can solve this by either: > - moving .10 into a separate LAN for which the pf box is the default gw > - userland reflection (e.g. nc(1) from inetd(8)) > - having your clients connect to the correct box in the first place > (split horizon DNS etc.) Thanks for your explanation, Max. I've added the following line to /etc/inetd.conf: telnet stream tcp nowait nobody /usr/bin/nc /usr/bin/nc -w 20 192.168.0.10 23 Works fine! I've tried the same thing with other protocols (e.g. SSH). Doing an scp transfer is really slow this way. Any ideas what could cause this issue? (this is not pf related anymore, but perhaps someone has a quick answer). Regards, Matthias From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 15:50:45 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7E661065688 for ; Tue, 4 Nov 2008 15:50:45 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 508D58FC08 for ; Tue, 4 Nov 2008 15:50:44 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA01.westchester.pa.mail.comcast.net with comcast id azC11a00A0ldTLk513qkpD; Tue, 04 Nov 2008 15:50:44 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA04.westchester.pa.mail.comcast.net with comcast id b3qj1a00G2P6wsM3Q3qjQ1; Tue, 04 Nov 2008 15:50:44 +0000 X-Authority-Analysis: v=1.0 c=1 a=T2B_cOh0iMAA:10 a=nl8DGsr-ROMA:10 a=QycZ5dHgAAAA:8 a=gwWgsKh55nTBr89N8ksA:9 a=jxN51i565H3q-xJWfVYA:7 a=H0NStPCU1_EhJNvB7dbVsJ7yjd8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id 12306C9419; Tue, 4 Nov 2008 07:50:43 -0800 (PST) Date: Tue, 4 Nov 2008 07:50:43 -0800 From: Jeremy Chadwick To: Matthias Kellermann Message-ID: <20081104155043.GA51736@icarus.home.lan> References: <491012AE.7000409@adminlife.net> <200811041139.10125.max@love2party.net> <49106ECF.4080803@adminlife.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49106ECF.4080803@adminlife.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-pf@freebsd.org Subject: Re: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 15:50:45 -0000 On Tue, Nov 04, 2008 at 04:48:31PM +0100, Matthias Kellermann wrote: > Max Laier wrote: > > On Tuesday 04 November 2008 10:15:26 Matthias Kellermann wrote: > >> I'm trying to set up a simple rdr rule in pf (7.0-RELEASE-p5). > >> > >> I have two hosts - host a (192.168.0.250) and host b (192.168.0.10) - in > >> a local network and want to forward one port from host a to host b. > >> > >> host a is the pf host. This is the rule to redirect traffic from host a > >> to b: > >> > >> rdr proto tcp from any to 192.168.0.250 port 23 -> 192.168.0.10 > >> pass log (all) proto tcp from any to 192.168.0.10 port 23 synproxy state > >> > >> If I try to get a telnet connection from my client 192.168.0.51 the > >> connection gets stuck and nothing happens. This is the output of tcpdump > >> on the pflog0 interface: > >> > >> # tcpdump -netttvvi pflog0 > >> 000000 rule 0/0(match): pass in on sis0: (tos 0x10, ttl 64, id 26668, > >> offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.51.54460 > > >> 192.168.0.10.23: [|tcp] > >> 000266 rule 0/0(match): pass out on sis0: (tos 0x10, ttl 64, id 25527, > >> offset 0, flags [DF], proto TCP (6), length 44) 192.168.0.51.54460 > > >> 192.168.0.10.23: tcp 24 [bad hdr length 0 - too short, < 20] > >> > >> Anybody has an idea whats wrong here? > > > > redirection only works if your pf box sees both directions of the connection. > > In your case, however, 192.168.0.10 probably knows how to contact 192.168.0.51 > > directly. So what happens is: > > > > .51 -> SYN (src=.51,dst=.250) -> pf -> SYN (src=.51,dst=.10) -> .10 > > > > <---------------------------- SYN/ACK (src=.10,dst=.51) <- > > > > But .51 is waiting for a SYN/ACK from .250. You can solve this by either: > > - moving .10 into a separate LAN for which the pf box is the default gw > > - userland reflection (e.g. nc(1) from inetd(8)) > > - having your clients connect to the correct box in the first place > > (split horizon DNS etc.) > > Thanks for your explanation, Max. > > I've added the following line to /etc/inetd.conf: > telnet stream tcp nowait nobody /usr/bin/nc /usr/bin/nc -w 20 > 192.168.0.10 23 > > Works fine! > > I've tried the same thing with other protocols (e.g. SSH). Doing an scp > transfer is really slow this way. Any ideas what could cause this issue? > (this is not pf related anymore, but perhaps someone has a quick answer). Simple: you've created a wonderful, beautiful bottleneck by using netcat as a form of buffering mechanism. You can tune netcat to your hearts content, and probably improve things a bit, but you're more or less screwed (to put it frankly). I highly recommend Max's first recommendation. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 15:53:53 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A202B1065673 for ; Tue, 4 Nov 2008 15:53:53 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 538618FC24 for ; Tue, 4 Nov 2008 15:53:53 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by qw-out-2122.google.com with SMTP id 9so1421045qwb.7 for ; Tue, 04 Nov 2008 07:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mQOCmlo9H+GPVZTh8St00AB7O0iDpo8DEJ6AURtB+N4=; b=x888isOmYMIYUTBY7elnlOyWnUSVEvFpTvqfukpTtKJPF6zkeg9DJDywWW43PeeiXb 5CMPQKS0n05fbCqyAAX1MvQvq3VDNx0Jgv5Z6h1Fy2o31nuAO34VjnE3XQjfJEHkrKyY vN7jEuLeZeOLtcKDZ3Wo8zOG+/vkYJTc379Lk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jS+gJY0GdiKcRf5hAHduSNMTpfSOzBwLNztrgv/SLJOU3K2sZYW22Vx1ASHWWgl47W mByUoVRLVEg+M3jNZUyRUFvrXtQDdf7NoMF+vTj5mZ9GlQoXAHpZ00wWuAoI0syQODkI Tk5z6vR1i5FLgk+3OMweelU8LzbvNIu0GYUZI= Received: by 10.215.40.16 with SMTP id s16mr1873268qaj.215.1225814032551; Tue, 04 Nov 2008 07:53:52 -0800 (PST) Received: by 10.214.43.4 with HTTP; Tue, 4 Nov 2008 07:53:52 -0800 (PST) Message-ID: <9a542da30811040753m1a2728bcu365c65da8fb61721@mail.gmail.com> Date: Tue, 4 Nov 2008 16:53:52 +0100 From: "=?ISO-8859-1?Q?Ermal_Lu=E7i?=" To: "Peter Jeremy" In-Reply-To: <20081103060321.GA45414@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9a542da30710161409o4732a77bybdf4ba35d7491bb@mail.gmail.com> <200710171043.08126.max@love2party.net> <9a542da30710211232v4d3c930fg8ea778a12f3f16cb@mail.gmail.com> <9a542da30710280617t11e668e2o4d122998192f71c@mail.gmail.com> <20081103060321.GA45414@server.vk2pj.dyndns.org> Cc: freebsd-pf@freebsd.org Subject: Re: [PATCH] PF+dummynet X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 15:53:53 -0000 On Mon, Nov 3, 2008 at 7:03 AM, Peter Jeremy wrote: > On 2007-Oct-27 19:45:59 +0000, Ermal Lu=E7i wrote: >>Attached is the patch against -CURRENT for integrating PF with dummynet! >> >>It gives full dummynet support in pf.conf syntax and removes dummynet >>depndency to ipfw. > > I've recently found this and applied it to 7.1-PRERELEASE. There were > a few rejects and a couple of printf format problems which were all > quite easy to fix. I also found an incorrect getopt() string in > pfctl, incorrect PLR definition, and an uninitialised dnflow variable. > Actually using it presents some more problems. > > Firstly, if you have ipfw in the kernel then dummynet packets appear > to loop indefinitely. Disabling ipfw fixed this (I had built ipfw > into the kernel incase I couldn't get pf+dummy to work). > > The above left me with wierd delays and incorrect packet counts on the > rules. Further sleuthing shows that I'm falling foul of the state > rules that pf is creating - though the behaviour is still wierd. > > Given the following: > dnpipe 128 bandwidth 2Mb delay 500 queue 64KB > dnpipe 136 bandwidth 2Mb delay 500 queue 64KB > r1) pass in quick on vlan128 from any to 192.168.136.0/22 dnpipe 128 > r2) pass in quick on vlan136 from any to 192.168.128.0/22 dnpipe 136 > > I get the following: > t0 ICMP ECHO REQ a->b -> > match r1: pass to pipe 128 (delay 500msec), create state s1 > t+.5s -> ICMP ECHO REQ a->b > t+.5s <- ICMP ECHO RESP b->a > match r2: pass to pipe 136 (delay 500msec), create state s2 > match s1: pass to pipe 128 (delay 500msec) > t+1.5s ICMP ECHO RESP b->a <- > > t2 ICMP ECHO REQ a->b -> > match s1: pass to pipe 128 (delay 500msec) > match s2: pass to pipe 136 (delay 500msec) > t2+1s -> ICMP ECHO REQ a->b > t2+1s <- ICMP ECHO RESP b->a > match s2: pass to pipe 136 (delay 500msec) > match s1: pass to pipe 128 (delay 500msec) > t2+2s ICMP ECHO RESP b->a <- > > I managed to fix ICMP by testing that the rule direction matches the > packet direction before passing it to dummynet. Unfortunately, this > means that TCP only goes through dummynet in one direction (since TCP > only has a single state entry). I think the duplicate ICMP state entry > is a bug in pf. And the dummynet patches need to support two pipes > (one for each direction). I am still looking into this. actually this is the latest against RELENG_7 which is confirmed to work with full features of pf(4) like route-to/reply-to etc... http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7/dummynet.R= ELENG_7.diff?rev=3D1.5 The problem that is that i have yet to find time to post it here but since you have interes here it is. Its problem is that from the whole patches here http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7/ you need to apply these others before it applies cleanly fairq.RELENG_7.diff <-- Mathew Dillon ALTQ_FAIRQ discipline dscp.RELENG_7.diff <-- a simple dscp syntax addition queuestats.RELENG_7.diff <-- you do not need this actually hfscconfig.RELENG_7.diff <-- this is on pfSense and only discussed with Ma= x killifstates.RELENG_7.diff <-- pfctl -b $ip addition to kill states from the gateway ip(interface ip) dummynet.RELENG_7.diff <-- dummynet(4) divert.RELENG_7.diff <-- divert(4) these are incorporated in the latest snapshots of pfSense but if you want to do the patching yourself I have no problems with it. Since i am sending this mail there is another patch that might interest you http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7/pfil.RELEN= G_7.diff?rev=3D1.1 it allows to reorder pfil hook or even disable one of them. Its a long time i am saying i will make them ready for review and commit for FreeBSD but still not found it. So i cannot state more on this. Feedback is always welcomed. The syntax on the this new patch is pass in ........ keep state dnpipe 1 or pass in ........ keep state dnpipe (1 ) or pass in ........ keep state dnpipe (1,3) where the latest pipe/queue 1 applies to in direction and pipe/queue 3 applies to out direction. > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviou= r. > --=20 Ermal From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 15:56:39 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 670441065689 for ; Tue, 4 Nov 2008 15:56:39 +0000 (UTC) (envelope-from bsemene@cyanide-studio.com) Received: from relay.cyanide-studio.com (ns23199.ovh.net [91.121.7.6]) by mx1.freebsd.org (Postfix) with ESMTP id 1FA7D8FC17 for ; Tue, 4 Nov 2008 15:56:39 +0000 (UTC) (envelope-from bsemene@cyanide-studio.com) Received: from mail.cyanide-studio.com (LAubervilliers-153-52-12-153.w217-128.abo.wanadoo.fr [217.128.107.153]) by relay.cyanide-studio.com (Postfix) with ESMTP id 688C5965ABC for ; Tue, 4 Nov 2008 15:34:01 +0000 (UTC) Received: from localhost (unknown [10.1.8.14]) by mail.cyanide-studio.com (Postfix) with ESMTP id B503D17BDC13 for ; Tue, 4 Nov 2008 16:34:00 +0100 (CET) Received: from mail.cyanide-studio.com ([10.1.8.3]) by localhost (mailguard.cyanide-studio.com [10.1.8.14]) (amavisd-maia, port 10024) with ESMTP id 65178-02 for ; Tue, 4 Nov 2008 16:34:00 +0100 (CET) Received: from [10.1.8.220] (unknown [10.1.8.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bsemene@cyanide-studio.com) by mail.cyanide-studio.com (Postfix) with ESMTP id 8F62817BDC12 for ; Tue, 4 Nov 2008 16:34:00 +0100 (CET) Message-ID: <49106B68.2060007@cyanide-studio.com> Date: Tue, 04 Nov 2008 16:34:00 +0100 From: Bastien Semene User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: can't add a port forwarding X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 15:56:39 -0000 Hi everyone, I'm currently facing a weird problem. I have a pf box acting as a gateway for some services and want to add a port forwarding for https. So I added the following rule : rdr pass on $ext_if proto tcp from any to any port 443 -> $atlas_ip //variables are correct since I have a similar rule for port 80. The "pfctl -s nat" shows this : nat on bge0 inet from 10.1.8.1 to any -> "external_interface_ip" rdr pass on bge0 inet proto tcp from any to any port = http -> 10.1.8.1 rdr pass on bge0 inet proto tcp from any to any port = https -> 10.1.8.1 An Nmap from outside shows this : # nmap -P0 -p80,443,17900 "external_interface_ip" Starting Nmap 4.20 ( http://insecure.org ) at 2008-11-04 16:22 CET Interesting ports on "external_interface_ip": PORT STATE SERVICE 80/tcp open http 443/tcp closed https 17900/tcp filtered unknown I tried reloading pf rules with "pfctl -F all -f /etc/pf.conf", restarting the machine, but nothing changed. The securelevel is also at -1, so pf should take the changes into account. And of course the destination https server receives nothing on https port. http and preconfigured nat/forwards works perfectly. I tried to comment the "scrub in all" option, but because the rdr line doesn't seem to be affected, I'm not sure this one is. If someone has an idea or direction to follow I take every piece of thought. Thanks all. From owner-freebsd-pf@FreeBSD.ORG Tue Nov 4 16:11:15 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B4591065676 for ; Tue, 4 Nov 2008 16:11:15 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id DD7E78FC1A for ; Tue, 4 Nov 2008 16:11:14 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-002-145.pools.arcor-ip.net [88.66.2.145]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1KxOUr3dke-0007wC; Tue, 04 Nov 2008 17:11:14 +0100 Received: (qmail 14445 invoked from network); 4 Nov 2008 16:11:13 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 4 Nov 2008 16:11:13 -0000 From: Max Laier Organization: FreeBSD To: Jeremy Chadwick Date: Tue, 4 Nov 2008 17:11:12 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <491012AE.7000409@adminlife.net> <49106ECF.4080803@adminlife.net> <20081104155043.GA51736@icarus.home.lan> In-Reply-To: <20081104155043.GA51736@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811041711.12983.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18XQZCOG2/j057++NWofo7sW+i6Kc8pqGDKSUs ayLZ0WKIns7yXfUBmdrwDveOvuDS8nHEI7sK/37FIoeIzkK+H2 steTOzPC/Nu63OG2RgDag== Cc: freebsd-pf@freebsd.org Subject: Re: rdr rule does not work (bad hdr length) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2008 16:11:15 -0000 On Tuesday 04 November 2008 16:50:43 Jeremy Chadwick wrote: > On Tue, Nov 04, 2008 at 04:48:31PM +0100, Matthias Kellermann wrote: ... > > > > Thanks for your explanation, Max. > > > > I've added the following line to /etc/inetd.conf: > > telnet stream tcp nowait nobody /usr/bin/nc /usr/bin/nc -w 20 > > 192.168.0.10 23 > > > > Works fine! > > > > I've tried the same thing with other protocols (e.g. SSH). Doing an scp > > transfer is really slow this way. Any ideas what could cause this issue? > > (this is not pf related anymore, but perhaps someone has a quick answer). > > Simple: you've created a wonderful, beautiful bottleneck by using netcat > as a form of buffering mechanism. You can tune netcat to your hearts > content, and probably improve things a bit, but you're more or less > screwed (to put it frankly). > > I highly recommend Max's first recommendation. Basically, yes. Userland redirection is a hack. It's easy to setup and will get you going. There are more efficient implementations than netcat - e.g. rinetd from ports. Ultimately, however, if you are looking for throughput without too much impact on the forwarding box etc. ... you must use a different mechanism - such as in-kernel redirection as provided by pf. For that you need a different network layout, however. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News