rdr rule does not work (bad hdr length)

[Jeremy Chadwick]

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 |