0

I'm trying to do some simple tcp port forwarding

 [root@wcmisdlin02 ~]# cat /proc/sys/net/ipv4/ip_forward 0 [root@wcmisdlin02 ~]# /bin/echo 1 > /proc/sys/net/ipv4/ip_forward [root@wcmisdlin02 ~]# cat /proc/sys/net/ipv4/ip_forward 1 [root@wcmisdlin02 ~]# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- anywhere anywhere ACCEPT icmp -- anywhere anywhere icmp any ACCEPT esp -- anywhere anywhere ACCEPT ah -- anywhere anywhere ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns ACCEPT udp -- anywhere anywhere udp dpt:ipp ACCEPT tcp -- anywhere anywhere tcp dpt:ipp ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:mysql ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:https REJECT all -- anywhere anywhere reject-with icmp-host-prohibited [root@wcmisdlin02 ~]# iptables --table nat --append PREROUTING --proto tcp --dport 80 --jump DNAT --to 10.52.208.223:80 [root@wcmisdlin02 ~]# iptables --table nat --list PREROUTING Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- anywhere anywhere tcp dpt:http to:10.52.208.223:80 [root@wcmisdlin02 ~]# curl --verbose http://10.52.208.221:80 * About to connect() to 10.52.208.221 port 80 * Trying 10.52.208.221... Connection refused * couldn't connect to host * Closing connection #0 curl: (7) couldn't connect to host [root@wcmisdlin02 ~]#
Improve this question
2
  • Is the web service on 10.52.208.223 actually running? Commented Sep 16, 2010 at 21:26
  • yes, webserver on .223 is running no problem Commented Sep 17, 2010 at 17:19

2 Answers 2

Reset to default
1

You're sending the traffic to 10.52.208.221. Given the config you posted, your problem is the webserver, not the firewall. Your rules look to be correct. FORWARD and INPUT are redirected to RH-Firewall-1-INPUT where your first rule is to allow all traffic. As somebody else pointed out, you could be allowing all traffic on eth1, while the world is actually coming in eth0. Secondary, you have to NAT the traffic as it goes back out to the world

iptables --table nat --append POSTROUTING --proto tcp --dport 80 --jump MASQUERADE -o OUT_INTERFACE

Your traffic originating from the router will never hit the input or forward chains, but instead traverse the output chain on to the webserver. Other systems in that subnet will similarly go directly to the webserver. Systems out on the world at large however will traverse the INPUT / FORWARD chains and need SNAT as well as DNAT so that it appears to the world to be one machine. You still cannot test from within your network. you must test from the opposite interface from the webserver. Get me your IP addresses and I'll point you to the proper configs.

Improve this answer
4
  • webserver is running and by hitting .221 it should redirec / serve from .223 and even though that rule seems to be fine, its not working! Commented Sep 17, 2010 at 17:21
  • 2
    You can't do that, you have to request 10.52.208.221 from another machine, not the system acting as a firewall. Commented Sep 17, 2010 at 18:37
  • 1
    Richard June is correct. You are on the same subnet as the destination so no routing is happening and the PREROUTING rules aren't being hit. BTW whenever I use iptables I use the verbose option. It shows the interfaces to which the rules apply and, which is helpful in this case, the number of packets that matched each rule. E.g., iptables --table nat --list PREROUTING --verbose Commented Oct 25, 2010 at 22:35
  • Richard, could you update your main answer? Commented Oct 25, 2010 at 22:44
0

Getting a connection refused means that at least a host is accepting the TCP packets, but no service is listening on that port. What happens when you connect from a different IP to both 10.52.208.221:80 and to 10.52.208.223?

I can't test it right now, but I've seen some scenarios where connecting from the host where the IP tables are set to a NAT'ed IP doesn't work. I'm not sure if that's the case here, since you don't explicitly define an interface where the rule is applied to, but I've seen some cases where Linux sees the IP you want to connect to as "local" and using the loopback interface and skipping iptables.

Anyway, can you try it from outside of the box?

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.