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.
