3

I'm new to servers and iptables. I have a web app (happens to be bugzilla) running on my Centos 6.7 apache/httpd server, and it attempts to connect out to the web (updates.bugzilla.org) via port 80. It also attempts to connect out (to smtp.gmail.com) using port 465. However, it cannot. This is in spite of having a default output policy of ACCEPT and having opened the relevant ports for input.

I'm not sure where to go from here. Where should I look to begin troubleshooting this? What are the likely culprits?

Some output:

$ service iptables status

Table: filter

Chain INPUT (policy ACCEPT)

num target prot opt source destination

1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

3 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22

4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80

5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443

6 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25

7 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587

Chain FORWARD (policy DROP) num target prot opt source destination

Chain OUTPUT (policy ACCEPT) num target prot opt source destination

AND:

iptables -L -v Chain INPUT (policy ACCEPT 881 packets, 106K bytes)

pkts bytes target prot opt in out source destination

0 0 ACCEPT all -- lo any anywhere anywhere

436 183K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED

0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh

1 60 ACCEPT tcp -- any any anywhere anywhere tcp dpt:http

0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:https

0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:smtp

0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:submission

Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 348 packets, 56741 bytes)

pkts bytes target prot opt in out source destination

I'm hopeful that it is not a bugzilla or centos-specific thing, as I have accomplished a successful bugzilla install on ubuntu desktop, although that was while using ubuntu's ufw (I think I also tried it with iptables, but would have to try again to verify).

UPDATE:

For those web searching and seeing this at a later date, it turns out this was a SELinux issue! Needed to enable the boolean 'httpd_can_network_connect' (for others, use 'getsebool -a').

Community
  • 1
tniles
  • 133
  • 5
  • are you logging blocked outgoing traffic? http://www.thegeekstuff.com/2012/08/iptables-log-packets/ – user993553 Sep 30 '15 at 23:05
  • Don't think so... let me try that and tinker a bit. Thanks! – tniles Sep 30 '15 at 23:08
  • Nothing looks wrong with your rules in regards to outgoing traffic. I suspect you might find this is actually not a firewall issue at all. With this input rule in place `ACCEPT all -- 0.0.0.0/0 0.0.0.0/0` you have nothing to lose turning iptables off altogether *for testing purposes only*. – Brandon Xavier Sep 30 '15 at 23:40
  • What are you unable to connect to? What is the error that you receive? – Michael Hampton Oct 01 '15 at 01:59
  • Thanks for the tip on logging dropped packets. While the firewall is not the exact issue, this does look like something that should be helpful (hope to try later). – tniles Oct 01 '15 at 15:43

1 Answers1

2

Try this:

service iptables save
service iptables stop
chkconfig iptables off

Boom, no firewall. Test again.

Try using telnet to test that port: 

telnet updates.bugzilla.org 80

Once connected with telnet, type "get" and see if there's a response.

Example:

# telnet updates.bugzilla.org 80
Trying 63.245.223.29... 
Connected to updates.bugzilla.org.
Escape character is '^]'
get
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.0.15</center>
</body>
</html>
Connection closed by foreign host.

Didn't work?

Try tcptraceroute to see where it gets blocked:

tcptraceroute updates.bugzilla.org 80

Could there be something else blocking ports? A firewall, router, ISP?

Ryan Babchishin
  • 6,160
  • 2
  • 16
  • 36
  • Thanks for the help everyone! Turns out the issue is not iptables after all. Telnet got the same output as in Ryan's post, and turning off the firewall did not change things. It did allow me to ping my server, so I know it was down. My confidence in my basic understanding of iptables has been restored. – tniles Oct 01 '15 at 15:38
  • FWIW, while it should have been obvious, I did not think to turn off the firewall completely to rule it out (guess I was maybe paranoid, too?). This makes sense because as Brandon (and my OP) pointed out, the outgoing is a default of ACCEPT. But iptables/firewall management is new to me, and I wasn't sure if maybe a FORWARD policy or some other INPUT policy was required. Getting the firewall completely out of the way was the best way to confirm this. – tniles Oct 01 '15 at 15:42
  • Follow-up (one more thought): Ryan, if I saw the same output as your telnet output (above), would that be correct that, as you said, "something else" is NOT blocking ports? (e.g. other firewall, router, ISP?) In other words, what output should I expect to see if something else is blocking ports. I ask because I just realized this is the same output I get whether or not my server's firewall is active. – tniles Oct 01 '15 at 15:47
  • "telnet igor 80" -> Trying 192.168.1.125... telnet: Unable to connect to remote host: Connection refused or something similar... or it will just hang. – Ryan Babchishin Oct 01 '15 at 15:49