Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 04 Nov 2008 16:48:31 +0100
From:      Matthias Kellermann <mk@adminlife.net>
To:        Max Laier <max@love2party.net>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: rdr rule does not work (bad hdr length)
Message-ID:  <49106ECF.4080803@adminlife.net>
In-Reply-To: <200811041139.10125.max@love2party.net>
References:  <491012AE.7000409@adminlife.net> <200811041139.10125.max@love2party.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49106ECF.4080803>