0

I'm implementing Ratchet's push example in my server (websockets) on port 9090. These are current iptables policies:

[root@myserver ~]# iptables -L -n -v
Chain INPUT (policy ACCEPT 309 packets, 22420 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    6   380 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:9090 flags:0x17/0x02 
 1765 79738 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 state NEW,ESTABLISHED 
  831 80329 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
   37  2866 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
1657K   67M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
   57  4891 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
1645K   99M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
  763 44632 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
    7   348 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:21 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:21 state NEW,RELATED,ESTABLISHED 
    6   384 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:1337 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:11211 

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

Chain OUTPUT (policy ACCEPT 3204K packets, 162M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1881  129K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:3306 state ESTABLISHED 

For some reason I can't access port 9090 from the client nor via telnet.

The browser console returns this:

WebSocket connection to 'ws://XX.XX.XX.XX:9090/' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED autobahn.min.js:62

(XX.XX.XX.XX is my server's ip)

telnet localhost returns this:

[root@myserver html]# telnet localhost 9090
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused

update

I ran ss -tnlp and this is the result:

[root@myserver ~]# ss -tnlp
State      Recv-Q Send-Q                                            Local Address:Port                                              Peer Address:Port 
LISTEN     0      50                                                            *:3306                                                         *:*      users:(("mysqld",1317,10))
LISTEN     0      128                                                          :::11211                                                       :::*      users:(("memcached",1361,27))
LISTEN     0      128                                                           *:11211                                                        *:*      users:(("memcached",1361,26))
LISTEN     0      128                                                          :::80                                                          :::*      users:(("httpd",6378,4),("httpd",6381,4),("httpd",6382,4),("httpd",6383,4),("httpd",6384,4),("httpd",6385,4),("httpd",6386,4),("httpd",6387,4),("httpd",6388,4))
LISTEN     0      32                                                            *:21                                                           *:*      users:(("vsftpd",1073,3))
LISTEN     0      128                                                          :::22                                                          :::*      users:(("sshd",2661,4))
LISTEN     0      128                                                           *:22                                                           *:*      users:(("sshd",2661,3))
LISTEN     0      100                                                         ::1:25                                                          :::*      users:(("master",1442,13))
LISTEN     0      100                                                   127.0.0.1:25                                                           *:*      users:(("master",1442,12))
LISTEN     0      128                                                          :::443                                                         :::*      users:(("httpd",6378,6),("httpd",6381,6),("httpd",6382,6),("httpd",6383,6),("httpd",6384,6),("httpd",6385,6),("httpd",6386,6),("httpd",6387,6),("httpd",6388,6))
5
  • What if you remove the flags:0x17/0x02 part? – ThoriumBR Sep 10 '14 at 23:31
  • Use the -v flag to show counters for each rule to confirm if the traffic is matching on that rule. Also, are you sure there's anything actually listening on port 9090? Use ss -tnlp to check. – fukawi2 Sep 11 '14 at 2:36
  • @ThoriumBR if I remove the flags, same result. – Andres SK Sep 11 '14 at 15:54
  • @fukawi2 I've added the -v parameter and updated the data. I also ran ss -tnlp, the results are in the updated question. Any ideas? – Andres SK Sep 11 '14 at 15:55
  • There is no process listen on port 9090. – Navern May 7 '15 at 21:21
3

To check whether a process is listening/using the socket, try lsof -i:9090.

As fukawi2 said, maybe your process is not listening to it. Or maybe another one is, and prevents yours from using it.

0

You can see from your iptables -nvL output that your rule is being hit (6 hits in your output).

Your ss -tnlp shows that there are no processes bound to port 9090 (Local Address:Port column), so the incoming packets to 9090 are passing iptables, but the kernel has nothing to do with them (no process bound), so the kernel sends back a TCP RST packet which results in your connection refused error.

In short, your problem is not iptables, it's that your process either isn't running, or is not binding to port 9090 correctly/successfully.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.