Qnap Webinterface not reachable after starting fail2ban

Third Party Help
1

Hi there,

I’ve deployed vaultwarden, with caddy (Cloudflare DNS, public Domain), running as docker container, and everything is working well.
Now I wanted to harden it a little bit more - so I’ve deployed fail2ban, guided by the Wiki.

A few details of my environment:

  • Qnap x64 NAS (home.mydomain.com:8443)
  • Vaultwarden 1.25.2, alpine Docker Image, Ports: 1080, 3012, Bridge mode
  • Caddy 2 alpine Docker image, Lets Encrypt, Cloudflare (pwd.mydomain.de), NAT mode
  • fail2ban, configured by Wiki, with Cloudflare add-on, host mode
    All config files are exacly configured like mentioned in the Wiki. When I start fail2ban container, I can open pwd.mydomain.com and its banning as expected.
    But when the fail2ban container is running, I can’t reach my NAS over home.mydomain.com:8443.
pwd.mydomain.com:443 {
  log {
    level INFO
    output file {$LOG_FILE} {
      roll_size 10MB
      roll_keep 10
    }
  }

  # Use the ACME HTTP-01 challenge to get a cert for the configured domain.
  tls home@mydomain.com {
      dns cloudflare {env.CLOUDFLARE_API_TOKEN}
  }

  # This setting may have compatibility issues with some browsers
  # (e.g., attachment downloading on Firefox). Try disabling this
  # if you encounter issues.
  encode gzip


  # Uncomment to improve security (WARNING: only use if you understand the implications!)
  header {
       # Enable HTTP Strict Transport Security (HSTS)
       Strict-Transport-Security "max-age=31536000;"
       # Enable cross-site filter (XSS) and tell browser to block detected attacks
       X-XSS-Protection "1; mode=block"
       # Disallow the site to be rendered within a frame (clickjacking protection)
       X-Frame-Options "DENY"
       # Prevent search engines from indexing (optional)
       X-Robots-Tag "none"
       # Server name removing
       -Server
  }

  # Uncomment to allow access to the admin interface only from local networks
  @insecureadmin {
    remote_ip 192.168.42.0/24
    path /admin*
  }
  redir @insecureadmin /

  # The negotiation endpoint is also proxied to Rocket
  reverse_proxy /notifications/hub/negotiate 192.168.42.42:1080

  # Notifications redirected to the WebSocket server
  reverse_proxy /notifications/hub 192.168.42.42:3012

  # Proxy everything else to Rocket
  reverse_proxy 192.168.42.42:1080 {
       # Send the true remote IP to Rocket, so that bitwarden_rs can put this in the
       # log, so that fail2ban can ban the correct IP.
       header_up X-Real-IP {remote_host}
  }
}

I have no idea why. Does anyone have any clues?

2

Well, i think fail2ban is blocking all ports, and thus will prevent you from connecting.

Either configure fail2ban to only block specific ports or put your own IP into the ignore list.