One vitally useful piece of information when trying to debug a set of firewall rules, is the actual firewall rules :) can you show us the output of either iptables-save or iptables -L -n -v
–
stewMay 17 '12 at 18:56

1 Answer
1

The order of iptables rules is important, as first-match-wins. Red Hat, like most sensible people, usually puts a blanket REJECT at the end of its chain, and adding rules to permit solr traffic - or any other kind of traffic - after that won't help, as the packet will never get that far down the chain.

If this is what's biting you, you need to do an iptables -L -n -v --line-number, find the number of the blanket rule at the end, and use iptables -I RH-Firewall-1-INPUT n ... to insert your ACCEPT at line number n, where n is less than the number of the blanket REJECT.

Edit: thanks for the listing. See that blanket REJECT all -- * * at the end? There's no point adding your ACCEPT after that, as you'll never get that far. Try doing the --line-number listing to find out where you need to insert that line - anywhere before the last line should do - and see if that works.

Edit 2: can you also confirm that netstat -an|grep 8983 on the server returns something sensible?

Edit 3: then your server's not listening on port 8983, which is why you can't connect to it even after opening up the port in the firewall. If you had a listener on that port, you'd see something like

The above example being taken from my webserver, which is why it's port 443 not 8983. You're going to need to find out why there's no listener on 8983 before we can make any more progress.

Edit 4: you can't connect to a daemon that's not listening. I know you said that "taking down the firewall fixes everything", and that may have been true when the daemon was listening; but right now I doubt it. If you're willing to repeat the experiment: taking the firewall down, confirming that netstat -an|grep 8983 on the server still returns nothing, and then showing that telnet server 8983 gives a connection, I shall be pleasantly surprised.

and this confirms that he's on the right track. your current firwall rules say that all INPUT goes to the RH-Firewall-1-INPUT chain, and if nothing matches there, then it tries the one you added to accept 8093, however the last rule of RH-Firewall-1-INPUT always matches, so it never hits your rule. Insert your rule before the last rule of RH-Firewall-1-INPUT or as the first rule of INPUT
–
stewMay 17 '12 at 19:08

Thanks again but adding the rule before the last line of the RH-Firewall-1-INPUT Chain, it is still not working. See above.
–
syn4kMay 17 '12 at 20:23