Centos – iptables refuses connections to squid port on CentOS 5.5

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.

As I understand your question you want this machine (the one, on which we fight with iptables) be able to sent traps to a remote server, right?

In that case, the interesting part is the OUTPUT chain, as it is, what regulates fate of packets originating in the box.

Debug step one: shut down iptables and verify that trap sending works. If it doesn't the problem is not with firewall configuration of the SNMP trap source. Do not proceed to step two until you have things working with iptables stopped.

Debug step two: grep -i /etc/services shows a plethora of entries for various SNMP-related things. You may either read the documentation and find out, on which ports your software communicates, or get ingenious. Assuming the latter add a line at the end of the OUTPUT chain configuration, that sends everything to LOGDROP chain. Then start iptables, verify that the rule is there in the OUTPUT chain and make a trap to be sent. Then take a look inside your /var/log/messages and you'll see an entry generated by the LOGDROP, which will tell you, that a packet from the local machine to the remote machine using protocol UDP, destined to port XXX has been dropped. Bingo!

Debug step three. Add to the OUTPUT chain rules (above the LOGDROP entry) a line, that ACCEPTs outgoing UDP packets (-p udp) to the remote server (-d <IP_ADDRESS>) on port XXX (--dport XXX) determined in Debug step three. Verify (iptables -L -n -v), that the rule is there. Make a trap to be sent and see it arrive safely at the destination. If it does not arrive, your software may communicate on more than one port, but then GOTO Debug step two. In the pathological case that you should determine large (dozens, hundreds...) ports being used by the software, and if your security policy permits that, you may just allow all (or all UDP) outgoing traffic from this box to the remote machine.

Profit ;)