🛡️ Native Firewall before your GPU Server

Traffic Flow

Your GPU Server operates behind our NAT infrastructure and network security layer, meaning traffic always passes through the Trooper.AI network firewall before reaching the server.

UDP traffic is blocked by default, but it can be enabled through the firewall settings if required.

This architecture allows you to manage network security centrally while focusing entirely on building and running your AI workloads.

How to use the built-in Network Level Firewall

The Trooper.AI firewall interface provides a native firewall positioned directly in front of your GPU Server. This allows you to control network traffic before packets reach the operating system of the GPU server.

This security layer is fully integrated into the Trooper.AI infrastructure and can be accessed via Actions > “Firewall Rules”.

The interface works as follows:

• (1) Rule Table – Displays all configured firewall rules. Rules can be sorted, edited, or deleted.
• (2) Default Routes – Defines the default behavior for traffic that does not match any rule.
• (3) Rule Editor – Add new rules based on port ranges, IP ranges, and action (Allow / Deny).

This design allows you to control network exposure of your GPU server without modifying the operating system configuration.

Troubleshooting

Checke these steps if you can not reach your services on your GPU server after doing something on the Firewall or Network Stack. If you still cannot access your machine anymore, please first check your firewall settings and then contact us: Support Contacts

IMPORTANT: Disabling any local Firewall (If Accidentally Enabled)

If a local firewall such as UFW was enabled on the server and is causing connectivity issues, it can be disabled with:

sudo ufw disable

Output:

Firewall stopped and disabled on system startup

Then disable the service:

sudo systemctl disable ufw

Output:

Synchronizing state of ufw.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable ufw
Removed /etc/systemd/system/multi-user.target.wants/ufw.service.

You should completely remove any local Firewall on your GPU server. This will make your life easier!

Troubleshooting: Why are my firewall rules not working as expected?

Firewall rules are evaluated from top to bottom.

The first rule that matches the traffic is applied, and no further rules are checked.

Example of incorrect order:

1  Deny  0.0.0.0/0      Port 14141
2  Allow 78.168.0.0/16  Port 14141

In this case, rule 1 blocks all SSH traffic before rule 2 is reached.

Correct order:

1  Allow 78.168.0.0/16  Port 14141
2  Deny  0.0.0.0/0      Port 14141

Always place more specific allow rules above general deny rules.

Troubleshooting: Why does my firewall rule not match my IP?

Firewall rules use CIDR ranges to define allowed or blocked IP addresses.

Make sure the range actually includes your IP.

Examples:

If the CIDR range is incorrect, the firewall rule will never match your connection.

Troubleshooting: Why is my port still blocked?

Check that the correct port is allowed in the firewall. You can find the correct ports in the manage dashboard of your Blib. If the wrong port is allowed in the firewall, traffic will never reach your GPU server.

Troubleshooting: Why is my web interface blocked?

The Trooper.AI firewall controls all incoming ports, including those used by web interfaces.

If the port used by services such as:

• OpenWebUI
• Jupyter Notebook
• internal dashboards
• custom AI tools

is blocked in the firewall, the web interface will also be unreachable.

A common secure configuration is to restrict access to your company IP range.

Example:

Allow 203.0.113.0/24  Port 14511
Deny  0.0.0.0/0       Port 14511

This allows only users from your organization to access the secure web interface.

Troubleshooting: Why is SSH not reachable?

If SSH access fails, check the following:

1. Do not install a local UFW (Firewall) that will block your internal SSH port 22
2. Your IP address must be within the allowed CIDR range
3. The allow rule with public SSH port (something like 14511 - not 22, thats internal port) must appear above any deny rules

Additionally, verify the SSH Allow setting at the bottom of the firewall configuration table.

If SSH is disabled at the bottom of the firewall settings, the server will only accept SSH connections from IP addresses allowed by the rules above.

Troubleshooting: Why does traffic still get blocked even though I added a rule?

Traffic that does not match any rule will follow the Default Routes defined in the firewall settings.

If a rule does not match exactly (wrong IP range, wrong port, or wrong order), the traffic may fall through to the default deny rule.

Always verify:

• rule order - first match wins (from top to bottom)
• CIDR range - see examples
• port number - seen on manage dashboard
• default route behavior

Final check: Try click ALLOW ALL and check if that work. If yes it’s a rule above not matching correctly.