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