Why a firewall exception may be needed

In Reverse Proxy mode, connections to your backend come from X4B's backend communication addresses. Per-IP connection limits can therefore group many visitors together and mistake that shared source for an attack. Tunneled traffic can retain the original client addresses.

Testing

  1. Confirm that the application listens on the configured backend address and port.
  2. Open Services, find your service, and choose Action > IP Addresses. Find the Backend Communication IP Addresses section and record the listed addresses.
  3. Check host and provider firewall logs for rejected connections from those sources.
  4. Add a rule allowing the required application port and protocol from those addresses, then retest through the protected frontend.
  5. For a tunnel, allow the selected tunnel protocol between its endpoints as well as the intended traffic through the tunnel.
Backend Communication IP Addresses used to scope backend firewall exceptions
Use your service’s current backend communication addresses in firewall rules.

Keep the firewall enabled during testing. Save the existing rules and retain console access before changing rules that could affect remote administration.

Resetting an existing iptables ruleset

On Linux systems using iptables:

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Adding an exception in CSF

Use the installed CSF version's supported rule syntax to allow the required source addresses, ports and protocols. Its allow-file is commonly /etc/csf/csf.allow. Apply the changes through CSF, then verify the resulting rules and application access. A broad source allowlist can expose more services than a port-specific rule.

Review the exception whenever the Dashboard's backend communication addresses change. Include relevant rule counters or log entries when asking support to investigate connectivity.