Re: Redirecting ports on localhost

[David Cannings <lists@edeca.net>]

On Tuesday 30 March 2004 20:13, David Cannings wrote:
> On Tuesday 30 March 2004 15:15, Fabiano Bonin wrote:
> >  > On Tuesday 30 March 2004 13:46, Fabiano Bonin wrote:
> > Maybe you can show the command needed to my case (i.e., using DNAT as
> > you told above). Sorry if i'm asking too much... I just need the
> > hosts on my local network can access this port through server's eth0.
>
> http://netfilter.org/documentation/HOWTO//NAT-HOWTO-6.html#ss6.2
>
> I've linked to the English HTML version of the HOWTO, other languages
> and formats are available at:
>
> http://netfilter.org/documentation/index.html#documentation-howto
>
> Have a read, see if you can make some sense of it.  If not, post back
> with what you've tried and why it doesn't work.  For the record, I've
> never tried redirecting a port to localhost although I can see no
> reason why it would not work as any other does.  I will have to give it
> a go myself when I have a few minutes spare.

As a followup I have found some time to play with this now.  Spending a 
few minutes on Google turned up a wealth of information regarding this 
problem.  One of the most useful posts was this one:

http://lists.netfilter.org/pipermail/netfilter/2002-November/040104.html

In short: by the looks of it you cannot DNAT to localhost as the kernel 
thinks that it is a martian packet.  As this is a rather old message I 
decided to investigate it myself.

I added a rule to the prerouting chain to DNAT port 3001 (a number I 
picked totally randomly) to 127.0.0.1:3000, this appears to work as far 
as netfilter is concerned, proof follows.  Note the key part of the last 
sentence: "as far as netfilter is concerned".

The following method works as expected in all aspects when the --to 
argument for DNAT is a local interface.  As this is what is expected I 
will not copy and paste proof.

Method:

Machine running netfilter is a 2.4.24 kernel which normally does 
masquerading for a network.  It is 192.168.0.100.

To test, I set netcat to listen on port 3000 on all interfaces in verbose 
mode.  I then used nmap from another machine on the network to scan the 
netfilter machine on port 3001 only.  A combination of netcat running on 
all interfaces and only bound to specific IPs (127.0.0.1, local interface 
IPs, etc) was used.

david@david david $ nmap -sT 192.168.0.100 -p 3001
(.. ouput snipped, port shown as closed ..)

gateway:~# nc -lp 3000 -o dump -vv
listening on [any] 3000 ...
 sent 0, rcvd 0

As you can see from the output, no packets are received by netcat before I 
terminate it, after nmap has reported the port is closed.

The packet counters in iptables are incremented however:

Extract from `iptables -t nat -L -v"

   12   720 DNAT       tcp  --  eth0   any     anywhere             
anywhere            tcp dpt:3001 to:127.0.0.1:3000

I added two -j LOG rules into the PREROUTING table, one before the DNAT 
rule and one after.

/var/log/messages shows that the packet reaches the PREROUTING chain but 
is not present immediately after the rule above, which shows that it was 
matched and netfilter handed it off for routing to 127.0.0.1.

Extract from /var/log/messages:

Mar 30 23:13:54 gateway kernel: IN=eth0 OUT= 
MAC=00:10:a7:07:bf:89:00:e0:18:f1:3c:b9:08:00 SRC=192.168.0.19 
DST=192.168.0.100 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=63265 DF PROTO=TCP 
SPT=36128 DPT=3000 WINDOW=5840 RES=0x00 SYN URGP=0

For clarification, my FORWARD chain had a default ACCEPT policy for the 
duration of the test.

My only minor confusion comes from the fact enabling logging of martian 
packets (`echo 1 >/proc/sys/net/ipv4/conf/all/log_martians`) does not 
output any information to either syslog or messages.  If this were a 
martians problem I would have expected some form of logging output from 
enabling it.

I have not had time to inspect the kernel source file mentioned in the 
post I linked to.  It would be good to see if the match for packets to 
127/8 still counts a source of !127/8 as invalid, somebody here might be 
able to tell us.

Perhaps there is something quite fundamentally wrong with the method I 
used to test, if so I hope somebody can point this out to me.  I also 
hope the evidence I've provided gives enough basis for me to say that 
whilst DNAT works as far as netfilter is concerned that packets "just 
don't get there".  My assumption is that this is caused by the problem 
described in the archived message above; therefore DNAT to loopback will 
not work as expected.

Apologies for the long message, it is a consequence of my attempt at being 
thorough.

David