UFW / IPTables behaviour

Discussion in 'Installation/Configuration' started by WhitcombeRD, Aug 14, 2019.

  1. WhitcombeRD

    WhitcombeRD Member

    Im running Buster with ISPConfig3.1.14p2, all up to date. Fresh clean install.

    Im running into an odd issue where ive installed OpenVPN and all works nicely except after a reboot.

    Ive added the required ip forwarding rules and also opened the UDP port required in the ISPConfig web module.
    After that all is well.
    EXCEPT when i reboot.
    On reboot the UDP port is still closed (all others work).
    On running ufw status it shows as that port being open BUT IPTables -L does not show it as open.
    If i then manually run ufw reload or go into ispconfig and remove/readd the port it works again until the next reboot.

    Can anyone suggest why this rule does not seem to be applied to iptables on a reboot but works perfectly after a refresh on the session?
  2. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    My guess is you might have multiple firewall systems in place, so after reboot maybe ufw sets rules up first, then another firewall system blows that away and creates a new set of rules.
  3. WhitcombeRD

    WhitcombeRD Member

    Im not sure really with that, this was a fresh VPS with a clean install of ispconfig, no previous files or backups transferred.
    Ive looked and Bastille definitely isnt on the machine and no scripts at all i can see to control iptables except ufw.
    Other changes in the webadmin to the ruleset do update and DO survive a reboot as well. Its just this one in particular that wont ever seem to stick.
  4. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Experiment with booting to single user mode, and start manually the startup scripts one by one. Check between each what the iptables show.
  5. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    That is curious, and would tend to rule out the "another firewall active" idea .. I've not seen that offhand. Does the rule use a dns name (as the source or destination)? Maybe you don't have network up / dns access at the time it first runs? If so, a workaround is probably to just setup a late running init script to run ufw reload, or simply change the rule to an ip. (You wouldn't want to re-work the init script order as it would require the network to be online and active before your firewall is in place, so a small window of not being protected.)
  6. Jesse Norell

    Jesse Norell Well-Known Member Staff Member Howtoforge Staff

    Nevermind that idea, it looks as if ufw does not accept hostnames, only ip addresses. I'm out of ideas on the cause, but maybe do what @Taleman suggested and you'll find some error/clue along the way. Also check logs after a reboot, maybe there'll be some clue.
  7. till

    till Super Moderator Staff Member ISPConfig Developer

    It must be a problem inside UFW as ISPConfig is not involved in starting UFW and ISPConfig does not modify any UFW config files directly. ISPConfig uses the UFW shell commands to open/close ports and to apply changes.
  8. WhitcombeRD

    WhitcombeRD Member

    Nope, the rule is a bog standard one to open up a specific UDP port from the outside world.

    ISPConfig is modifying UFW (however it does that, i havent managed to find the scripts) to the point that ufw thinks the ruleset is there as ufw status shows the rule as present. But it doesnt seem to be in iptables on initial boot. Restarting ufw and its there.
    Ive got a dirty, nasty hack currently of running ufw reload as a post-boot script but obviously thats a messy workaround for now.

    Im wondering if the vpn script (pivpn, installs openvpn and configs) has added the rule somewhere else and its fighting with the existing one or something odd.

Share This Page