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 |