Gah! I'm losing hair by the second!

For the life of me I cannot get port forwarding under iptables to work. I have the normal setup of a Linux box with two NICs, masqueraded internal LAN etc, and that's all working, but port forwarding is rapidly making me infertile.

I've read countless web pages that say "simply use this rule here", and the rules never, ever work. I'm using the telnet port as a test port, and there's a telnet daemon on the internal machine, but the connection is forever refused.

Here are the lines I'm using:

$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 23 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A PREROUTING -t nat -p tcp -d $EXTIP --dport 23 -j DNAT --to 172.28.221.2:23

These lines appear directly after:

$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F

I have moved them about the script a bit because I know that the order of rules is sometimes important, but to no avail. What the bloody hell am I doing wrong? I've checked, double checked, and triple checked everything over and over again, used countless different variations of these "simple" port forwarding rules, nicked bits and pieces out of other peoples' scripts (thanks Dan) but it's still hosed.

(BTW - I know someone will pick me up on my FORWARD ACCEPT line - I appreciate this but I had to do that to get the masquerading working in the first place - astonishingly. Also, I have a hardware firewall in front of the whole lot anyway so it's not that important for this firewall to be amazingly secure).

Any ideas? The desperation ... *twitch*

Stuii!

is forwarding activated?
$cat /proc/sys/net/ipv4/ip_forward
should be 1 not 0

Are you sure about "--to 192. . ."? Try: "--to-destination 192. . ."

"--dport" modifies "-p tcp". If for no other reason than aesthetics try: "-d $EXTIP -p tcp --dport 23 . . ." Also you don't need :23 after the destination ip.

Check and post the output from 'iptables -nvL' maybe 'route' as well, 'ifconfig' couldn't hurt either.

If FORWARD is flushed, and the policy is ACCEPT, don't bother with explicitly allowing the traffic (i.e. the first rule) It's just another line to get confused/worried about.

Port forwarding is indeed activated. Don't forget that the masquerading does work, and port forwarding would have to be switched on for even this to happen.

I've tried using the full --to-destination flag instead of the abbreviation but it makes no difference.

I reordered the flags as you suggested, but nada

ifconfig and route check out fine, don't forget that IP masquerading is working a treat - it's just the port forwarding that isn't. ifconfig and route would surely have to be correct for masquerading to do anything.

Here is the output from iptables -nvL:

Chain INPUT (policy ACCEPT 54 packets, 3425 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 state NEW,RELATED,ESTABLISHED
0 0 ACCEPT all -- eth0 eth1 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
42 4279 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

... and the output from iptables -t nat -vn -L:

Chain PREROUTING (policy ACCEPT 1250 packets, 101K bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 212.21.109.138 tcp dpt:23 to:172.28.221.2

Chain POSTROUTING (policy ACCEPT 8852 packets, 483K bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * eth0 172.28.221.0/24 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 8852 packets, 483K bytes)
pkts bytes target prot opt in out source destination

I've also checked, double checked and triple checked the kernel configuration. Indeed, I'm lead to believe that this is alright because of the fully functioning IP masquerading. I'd understand more if neither port fowarding or masquerading worked, but this is crazy!

Thanks for your help.

Stuii!

I did forget about the masquerading working. oops.

The tables look fine to me. The kernel is fine otherwise you wouldn't get the tables at all.

The counters indicate that netfilter hasn't seen packets destined for port 23 on 212.2 . . . Are you sure telnet attempts are getting to the NAT box in the first place? Maybe try tcpdump on the external interface while you attempt to telnet. That way you will know if your hardware firewall is blocking the connection attempts.

Otherwise, I am at a loss as well.

Craig

They're definitely getting there, I'm sending them from another host on the eth0 network and it does actually report "Connection refused" rather than timing out.

Crazy! But thanks for your help all the same.

Stuii!

Stuii

Hope your wrappers (hosts.allow and hosts.deny) are not guarding telnet ... also, check whether telnet is disabled under xinetd.

You would be safer using ssh instead of telnet, especially if you are trying to connect over the Internet.

I'm just using telnet as a test port for port forwarding. Once I've got it working I'll be forwarding MS Terminal Services. The telnet port is just quicker to test than Terminal Services are

As far as I know, it's not necessary to enable anything in inetd.conf in order to have a port forwarded. Thanks anyway.

Stuii!

I'm surprised that the counters read zero for your nat rule since the fact that you are getting 'connection refused' instead of a timeout seems to imply that the NAT is successful, but the telnes service is simply refusing connections.

I think the next step in troubleshooting should be to try and eliminate the possibility of a service problem as opposed to an iptables problem. For example:

* Try forwarding to a different service, say port 80, and see if it works.
* Do a tcpdump on the 172.x.x.x machine to confirm whether or not packets are arriving, regardless of what telnetd does with them

If either of the above work, you have a telnet problem. In that case you should either reconsider what ppuru suggested about tcpwrappers or just forget about telnet, remove the horrid thing from your system and get on with using terminal services or similar.