centos7 + firewall issue, ispconfig3.x

Discussion in 'ISPConfig 3 Priority Support' started by ronee, Nov 8, 2016.

  1. ronee

    ronee Member HowtoForge Supporter

    Hopefully someone has a comment or two on this.
    We've been battling this issue on and off for some years. Mostly when we experience the problem we migrate all running sites on the server to a new server running debian8 and ispconfig 3.1 and that resolves it, however occasionally such a migration is not easy.

    The issue is:
    Centos7 with standard perfect server ispconfig 3.0x (am assuming 3.1 has the same issue but have no way to easily verify since we are moving everything to debian) appears to have a strange issue with blocking connections through I am guessing the netfilter function of the kernel even if all firewalls appear to be disabled. This is not dependent upon iptables, firewalld, bastille or any other firewall function we have been able to find. Problem still occurs with no firewall record configured in ispconfig. The problem is only manifested when an external firewall or proxy is used in front of the server (for web traffic) when that external firewall/proxy is not on the LAN. If the firewall/proxy is on the local subnet there is no problem. We assume this is because the local subnet by default on Centos7 is whitelisted or in some sort of default trusted zone.

    Essentially what appears to occur is over time connections are blocked for one reason or another from the proxy/firewall directly on the server. We've had some sites experience DDOS attacks and encountered this issue when using an external web application firewall to alleviate.

    We've confirmed firewalld, iptables, bastille etc are all not running when this happens however we have confirmed it is a real issue. Stopping fail2ban also appears to have no effect. Interestingly we rarely saw this on Centos6 but stopping all firewall services would seem to alleviate the problem, but on Centos7 there is no effect.

    Our latest idea was to configure firewalld and set up permanent allow IPs (whitelisted IPs) to see if this fixes the problem.

    Wondering if anyone has ever experienced this or has any comments. Primarily we'd like to verify the source of the problem and how to alleviate it without having to add a local firewall/proxy in front of each server or being forced to migrate the server to resolve.

    Any input appreciated.
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    That's what I would recommend.

    I had several issues with the CentOS perfect server virtual machine which started to block connections after each reboot, the problem seems to be that Fail2ban is not connected to firewalld somehow and it seems to start firewalld partially after boot ven if it i disabled and then it blocks connections, The only solution that I found was to install and enable firewalld and then configure it to open all part needed by the services on this server and leaving the ispconfig firewall off. I guess we will have to implement a firewalld backend for the ispconfig firewall in futire if we don't want to stop using fail2ban on CentOS.
     
  3. ronee

    ronee Member HowtoForge Supporter

    ok great Till that's very appreciated and is consistent with what we were seeing, it is very strange how this spurious blocking comes about

    I take it in your experience it is not necessary to specifically allow IPs, ports are enough? I am also guessing that it is fine to leave the default public zone enabled.

    Thanks again!
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    Yes, I would open the ports for the public zone.
     
  5. ronee

    ronee Member HowtoForge Supporter

    Thanks very much Till.
    Glad to finally get to the bottom of this rather illogical problem. Somewhere there must be an unwritten assumption in CentOS that the local subnet is trusted.
    In any event I thought I would post the solution we settled on which is to switch from firewalld to iptables, reason being that firewalld we found has some expected functionality lacking (such as no ability to log dropped packets) and lends itself to unnecessary complexity. Problem solved, hopefully this info helps someone else.
     

Share This Page