Date: Tue, 4 Nov 2008 07:50:43 -0800 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: Matthias Kellermann <mk@adminlife.net> Cc: freebsd-pf@freebsd.org Subject: Re: rdr rule does not work (bad hdr length) Message-ID: <20081104155043.GA51736@icarus.home.lan> In-Reply-To: <49106ECF.4080803@adminlife.net> References: <491012AE.7000409@adminlife.net> <200811041139.10125.max@love2party.net> <49106ECF.4080803@adminlife.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081104155043.GA51736>