Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: netfilter@lists.netfilter.org
Subject: Re: Port forwarding - what's wrong with my setup?
Date: Fri, 22 Dec 2006 13:53:11 +0100	[thread overview]
Message-ID: <458BD537.1040808@plouf.fr.eu.org> (raw)
In-Reply-To: <458B87EF.6060007@gmail.com>

Hello,

Nandan Bhat a écrit :
> 
> I intend to have clients connect to 192.168.1.6 on port 11002 
> (arbitrary) and have such traffic to be forwarded to 192.168.0.10 on 
> port 110. Likewise on 192.168.1.6:25000 to 192.168.0.10:25.
[...]
> I expected to be able to telnet 192.168.1.6 on port 11002 and be shown 
> the response of 192.168.0.10 for the POP server. But I get connection 
> refused. Any pointers?

Is the connection refused immediately or does it hangs and fail ?
Do you see related lines in the reject logs ?
Did you try from this box or from hosts in the internal network ? NAT 
rules in the PREROUTING chain do not work with locally generated packets.

> 07 INTIP="192.168.1.6/24"

A single IP address has a /32 prefix length or no prefix length. Here I 
think 192.168.1.6/24 is equivalent to 192.168.1.0/24 (bits beyond the 
prefix length are ignored) so it makes -s/-d matches broader than they 
should be.

> 27 $IPTABLES -A INPUT -i lo -s $UNIVERSE -d $UNIVERSE -j ACCEPT

My advice is don't overload the rules with useless matches. If a rule 
does not care about a given packet parameter (source/destination 
address/port, protocol, ICMP type, state...), just don't put the match. 
It will make your rules shorter and more readable.

> 30 $IPTABLES -A INPUT -i $EXTIF -p ICMP -s $UNIVERSE -d $EXTIP -j ACCEPT

If you don't trust the external network, you don't want to accept all 
ICMP types on the external interface.

> 39 $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $INTIP -m state --state NEW \
> 40  -m tcp -p tcp --dport 21 -j ACCEPT
> 41 $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $INTIP -m state --state NEW \
> 42  -m tcp -p tcp --dport 22 -j ACCEPT
> 43 $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $INTIP -m state --state NEW \
> 44  -m tcp -p tcp --dport 25 -j ACCEPT
> 45 $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $INTIP -m state --state NEW \
> 46  -m tcp -p tcp --dport 80 -j ACCEPT
> 47 $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $INTIP -m state --state NEW \
> 48  -m udp -p udp --dport 137 -j ACCEPT
> 49 $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $INTIP -m state --state NEW \
> 50  -m udp -p udp --dport 138 -j ACCEPT
> 51 $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $INTIP -m state --state NEW \
> 52  -m tcp -p tcp --dport 139 -j ACCEPT
> 53 $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $INTIP -m state --state NEW \
> 54  -m tcp -p tcp --dport 445 -j ACCEPT
> 55 $IPTABLES -A INPUT -i $INTIF -s $INTNET -d $INTIP -m state --state NEW \
> 56  -m tcp -p tcp --dport 3306 -j ACCEPT

You can replace all this with two rules with the 'multiport' match. Or 
you can "factorize" the common matches "-i $INTIF -s $INTNET -d $INTIP 
-m state --state NEW" with a user defined chain to make the rules 
shorter (thus more readable). :-)

> 69 $IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
> 70
> 71 $IPTABLES -A FORWARD -i $INTIF -p tcp -s $INTNET --sport 11002 \
> 72  -d 192.168.0.10 --dport 110 -j ACCEPT
> 73 $IPTABLES -A FORWARD -i $INTIF -p tcp -s $INTNET --sport 25000 \
> 74  -d 192.168.0.10 --dport 25 -j ACCEPT

There is no reason that the source port of the DNATed packets would be 
equal to the original destination port, so these two rules would not 
match. However they are unused because the rule in line #69 accepts the 
packets before.

> 77 $IPTABLES -t nat -A PREROUTING -p tcp -i $INTIF -d $INTIP \
> 78  --dport 11002 -j DNAT --to 192.168.0.10:110
> 79 $IPTABLES -t nat -A PREROUTING -p tcp -i $INTIF -d $INTIP \
> 80  --dport 25000 -j DNAT --to 192.168.0.10:25

Isn't there a MASQUERADE rule in the POSTROUTING chain for packets 
leaving $EXTIF from $INTNET ? The server 192.168.0.10 may refuse 
communications from this netblock.


  reply	other threads:[~2006-12-22 12:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-22  7:23 Port forwarding - what's wrong with my setup? Nandan Bhat
2006-12-22 12:53 ` Pascal Hambourg [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-12-26 12:01 Nandan Bhat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=458BD537.1040808@plouf.fr.eu.org \
    --to=pascal.mail@plouf.fr.eu.org \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox