0

I have a situation, where my server can't connect to an SMTP server, while my PC can. But the same server can connect to another SMTP server. I think that my firewall might be blocking it. How can I reliably test, if this issue caused by my firewall/iptables? Ideally, with or each one alone.

There are many rules in the iptables and I may miss things. I was thinking of a tool, which would tell me if a e.g. outgoing connection to a host at port with TCP or UDP would be blocked or not.

PS: it is a Debian server and my laptop and the server are in different networks.

Genom
  • 1
  • What OS are involved? Where are the different machines you mention (networkly speaking)? Do you have an actual physical firewall? What have you already tried? What was the result? – Ginnungagap Apr 13 '23 at 05:55
  • Are PC and server in the same or different subnets? Are other firewalls involved? What is the exact error message you encounter? – Gerald Schneider Apr 13 '23 at 06:07
  • How can I reliably test, if this issue caused by my firewall/iptables? first step I would do is check the configuration of firewall/iptables – Jaromanda X Apr 13 '23 at 06:18
  • 1
    To check if the problem is the host based / local firewall on the server itself can be relatively easy : "temporarily disable that firewall" - To diagnose if the problem is another firewall (in your or your ISP's network for example) can be a bit more complex. When you get a "connection refused" error (from a friendly firewall rather than one that silently drops blocked packets) see: https://serverfault.com/q/1109623/37681 – HBruijn Apr 13 '23 at 07:21
  • Sorry for not being clear. I meant software firewall and I did not realize that there are different types in Linux systems ufw and firewalld. – Genom Apr 13 '23 at 07:52
  • There are many rules in the iptables and I may miss things just show your rules and we can tell you if they are a problem or not. – Gerald Schneider Apr 13 '23 at 08:10
  • @GeraldSchneider but that's not the point. I would like to have a reliable method to test the rules without manually inspecting them. 1) Humans easily miss details in long list of entries. 2) I can't automate serverfault :) – Genom Apr 13 '23 at 08:46
  • Then learn how to read the output. Recommendations for tools are off topic here. – Gerald Schneider Apr 13 '23 at 08:48
  • Well the problem is not to learn or I am not necessarily asking also for a tool (even though I used the term above), the problem is to have a simple method without going through each rule one by one. – Genom Apr 13 '23 at 09:00
  • Use the following command to test for an open TCP connection nc -vz TARGET_IP TARGET_PORT. – paladin Apr 13 '23 at 10:12
  • @paladin Thanks! I tried this but this does not tell me if the connection is blocked by my local firewall or by the firewall of the remote host. – Genom Apr 13 '23 at 12:18
  • Usually, if it's blocked by your local firewall, you will receive a reject signal, meaning the connection attempt will fail immediately. If it's blocked by the remote machine, you will receive a drop, meaning the connection attempt will fail after a drop timeout, often up to 60 seconds and more. – paladin Apr 13 '23 at 12:24
  • @paladin This is not true, I added a rule to block remote IP and it caused a time out after some time instead of failing immediately. – Genom Apr 13 '23 at 13:08
  • Because you used a drop, instead of a reject. For internal network, you should always use a reject, only for external networks, or public networks, a drop is a good choice. – paladin Apr 13 '23 at 13:24

0 Answers0