Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm very new to *nix operating systems, and I'm having some trouble which I believe is because of misconfiguration of the iptables firewall.

My server has SSH running on port 22, and server software running on TCP port 25565. SSH and the server software respond appropriately to connections made from inside the network (that is, connections made using the server's local address, 10.0.0.xx). However, if I attempt to access them from outside the network or using the router's external IP address, they do not respond.

The router is configured to forward those ports to the server; I very much doubt there is an error there.

After researching iptables, I tried a few guides, but I am not seeing any results.

The output of iptables -L is as such:

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:25565
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:27015
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

An nmap scan from inside the network reports that port 22 and 25565 are open, and that ports 80 and 2705 (another server software that I am not running at the moment) are closed. Running nmap with the router's external IP returns no useful results; I believe the router is detecting the scan attempt and refusing to respond.

The server is running Debian in text-only mode.

Does anyone see what the problem is, or have troubleshooting steps to suggest?

In response to comments:

netstat -tpln gives the following (among other things); I assume this is good, though the difference between tcp and tcp6 escapes me.

tcp6       0      0 :::25565                :::*                    LISTEN      3092/java

Hosts.deny is devoid of entries.

However, /var/auth.log has some... interesting contents. Is it normal for people to start trying to bruteforce my root password the very minute SSH is exposed?

But yes, a perusal of the logs seems to suggest that I'm the only person who cannot SSH into my server.

share|improve this question
    
state RELATED,ESTABLISHED should be the first rule not the last. And you should use --ctstate instead. But that's just am optimization, not the solution to your problem. Run tcpdump on the external interface and try to connecto to it, e.g. tcpdump -i eth0 -n tcp port 22. That shows you whether packets arrive at the host and whether the host tries to answer (over this interface). –  Hauke Laging Jul 3 '13 at 1:09
    
Is other program on port 25565 using tcp protocol? Try run netstat -tpln, is this program in the listing? –  Jan Marek Jul 3 '13 at 6:01
    
Is there anything on /etc/hosts.deny. What does /var/log/auth.log say when you try ssh from outside? Also try tcpdump -i eth0 -nn same time as Giovanni has mentioned. –  mezi Jul 3 '13 at 8:11
add comment

5 Answers 5

  • Use tcpdump -i eth0 -nn to see what's going on on the wire. There should be connection attempts and responses like this:

    14:20:38.482053 IP 172.31.170.1.42111 > 172.31.170.102.22: Flags [S], seq ...
    14:20:38.482095 IP 172.31.170.102.22 > 172.31.170.1.42111: Flags [S.], seq ...
    

    if the response to [S] is not [S.] but something else like [R] or an ICMP packet then there's something wrong.

  • Check the routing table: ip route show - is there a default route pointing to the router?
  • Can the router actually ping the server and vice versa?
share|improve this answer
    
tcpdump reveals that nothing is arriving at the machine when accessed via external address. It would seem that would rule out iptables, since I assume it can see things that would otherwise be blocked (it always says "0 packets dropped by kernel"). The routing table entry for the router is "default via 10.0.0.1 dev eth0", which I assume is good. The router is unfortunately not capable of diagnostics; however, it reports that it sees the server, and I assume it is doing so by pinging it. –  Schilcote Jul 3 '13 at 10:26
1  
@Schilcote - if there is no incoming traffic it most likely means the router isn't forwarding the packets from outside to your server. There may be a few separate knobs to turn it on - general forwarding enable, specific rules, NAT settings, etc. The exact settings are very much specific to each router model. –  MLu Jul 3 '13 at 10:31
    
@Schilcote also, did you tried nmap -p 22 external_ip? Check your router firewall/security/intrusion detection rules too, they usually mess with the routing. –  Braiam Jul 3 '13 at 12:59
add comment

iptables is one of the worst (best?) examples of "let's just export the raw kernel tables and let the admin make sense of it" design.

Uncomplicated Firewall will handle the common cases like you describe and leave you with you sanity. It's just a wrapper around iptables, but one that speaks in task structure not kernel structures.

share|improve this answer
1  
Debian is usually using ufw package... But doing firewall with any package without understanding basics is way to the hell. –  Jan Marek Jul 3 '13 at 6:05
add comment

While you can configure iptables by hand, it is much more reliable to use a tool to build the firewall according you your requirements. I find Shorewall to be a well documented and easy to use tool. It is available as a package. If you require IPv6, there is also a Shorewal6 package. There are example configuration for a number of configurations that make a good starting point.

The ucf package can also be used to build a rule set.

Either will set up some standard rules that you may miss when rolling your own firewall.

share|improve this answer
add comment

Try clearing your iptables and set default policy to ACCEPT, if you can connect your problem is with your iptables rules otherwise your router is buggy.

About the entries in your auth.log file, there's several blocklist for known-bot-nets that are most likely trying to break your configuration (or is just you with your testing), install openssh-blacklist-extra to provide additional protection (it should be installed along with sshd, but a quick check could help). Also, should be good idea fail2ban too.

share|improve this answer
add comment

But yes, a perusal of the logs seems to suggest that I'm the only person who cannot SSH into my server.

That rings a bell ... are you trying to connect to your public IP from the internal network? That's not likely to work. You must test your access from the internet side of the router, e.g. from a VPS or a 3G mobile. Just a thought...

share|improve this answer
    
I'll try that then. Connecting to the public IP from inside has never caused problems for me before, that's usually how I test these things, but I'll take your word for it. I did try it from another network just to be sure before, but that was a library and might have had the relevant ports blocked. –  Schilcote Jul 4 '13 at 15:07
    
Had someone else try accessing the server, didn't work. –  Schilcote Jul 4 '13 at 23:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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