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.
next prev parent 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