Container Firewall

The Container Firewall lets you control network access to application nodes by defining rules based on traffic source, protocol, destination port, priority, and action. Firewall rules can be managed from the platform dashboard, through SSH, or programmatically with the platform API.

On this page

Overview
Manage the Firewall from the Platform UI
Default Firewall Rules
Add Default Inbound Ports During Deployment
Firewall Rule Management
Restrict Access Through the User Interface
Restrict Access Through SSH
Configure Rules Through the Platform API
Important Notes
Common Issues and Solutions

Overview

The firewall determines whether a node can accept or initiate network connections. Each connection is checked against configured rules, including its source, transport protocol, destination port, processing priority, and whether the request should be allowed or denied.

Tip: If you need to restrict communication between environments in the same account automatically, use the platform network-isolation functionality where available.

Container firewall and environment isolation illustration — Firewall and isolated environment communication concept.

Manage the Firewall from the Platform UI

Standard platform nodes normally include firewall settings that can be reviewed and managed directly from the dashboard. Depending on the platform configuration, some custom Docker-based or Windows-based containers may not expose the same firewall interface.

1Open Firewall Settings

In the dashboard, locate the required environment, open Settings, and select Firewall.

Availability: The Firewall section depends on the hosting provider’s platform configuration. If it is not available, contact platform support.

Firewall settings in environment dashboard — Container Firewall settings in the environment dashboard.

Firewall Tabs

Tab	Purpose
Overview	Shows general firewall information, allows the firewall state to be enabled or disabled, and displays isolated environment groups that include the current environment.
Inbound Rules	Controls incoming connections. Traffic that does not match an allow rule is denied by default.
Outbound Rules	Controls outgoing connections. Traffic that does not match a rule is allowed by default.

Default Firewall Rules

When a container is created, the platform automatically prepares firewall rules required for standard stack operation. Required default rules can be restored when the firewall service restarts.

The first system rule is normally read-only, uses priority 1, and permits access required by platform infrastructure.
This high-priority rule supports platform orchestration, SSH Gate, Web SSH, and shared load-balancer connectivity.
Stack-specific and custom rules are placed between the mandatory first and last records.
The last read-only inbound rule uses priority 65535 and denies traffic that was not already allowed.

Important: Change default firewall rules only when you understand the impact. Standard rules may be required for SSH, HTTP, HTTPS, FTP, mount points, add-ons, or other stack features.

Default inbound firewall rules — Example of default inbound firewall rules.

Add Default Inbound Ports During Deployment

For automated deployment, the OPEN_INBOUND_PORTS environment variable can create initial inbound firewall rules while a node is being installed.

1Open the environment topology

Create a new environment, select the required software stack, and open its Variables configuration.

Container variables button — Open the Variables configuration for the selected node.

2Specify the ports

Provide individual ports or port ranges in the variable value.

OPEN_INBOUND_PORTS = {port1}, {port2}, … , {portN}

For example, a single port can be written as 1234, while a range can be written as 33062-34000. The configured values are exposed for both TCP and UDP after the container is created.

Inbound ports environment variable — Example of ports configured through an environment variable.

Firewall rules created from inbound port variables — Inbound firewall rules created during node installation.

Note: The variable is processed only during node installation. If you need to change ports later, modify firewall rules directly.

Cloud Scripting Example

jpsType: install name: OPEN_INBOUND_PORTS env variable nodes: nodeType: apache2 nodeGroup: cp env: OPEN_INBOUND_PORTS: 3306, 33061, 33062

Firewall Rule Management

The firewall toolbar lets you add, edit, remove, enable, disable, and refresh rules.

Rule Parameters

Parameter	Description
Nodes	Select the environment layer to which the rule applies.
Name	Enter a descriptive rule name or choose a predefined option.
Protocol	Select TCP, UDP, or TCP/UDP.
Port Range	Enter one port, such as `80`, or a range, such as `1024-2048`. Leave blank for all ports.
Source	Select custom IP addresses, predefined network ranges, or environment nodes.
Priority	Defines processing order. Lower numbers are evaluated first.
Action	Allow or deny traffic that matches the rule.

Supported Source Types

Custom IP Address(es): comma-separated IPv4 addresses, IPv6 addresses, or CIDR blocks. Keep IPv4 and IPv6 values in separate rules.
Predefined ranges: options can include All, All IPv4, All IPv6, Local Network, or Internet/Public Access.
Environment Nodes: select a layer from an environment in the account. Matching node addresses can update automatically when the layer scales.

Add inbound firewall rule form — Add an inbound firewall rule.

When editing an existing rule, most settings can be changed except the selected target node layer. Rules can also be disabled temporarily for testing and enabled again later. Use Refresh after topology or server-side changes.

Restrict Access Through the User Interface

The following example blocks incoming traffic from a specific public IP address. Make sure the target node has a public IP before testing external connectivity.

Add new inbound rule from firewall settings — Start by adding a new inbound rule.

Field	Example Value
Nodes	Select the container layer that should be restricted.
Name	`my-rule`
Protocol	TCP
Port Range	Leave blank to apply the deny rule to all ports.
Source	Custom IP Address(es): `111.111.111.111`
Priority	900
Action	Deny

Deny firewall rule for a specific IP address — Example rule that denies access from a specific IP address.

After the rule is active, matching requests from that source are rejected according to the selected protocol and port scope.

Blocked connection example — Example of a connection blocked by the firewall rule.

Restrict Access Through SSH

SSH-based configuration can be used for advanced firewall scenarios, including custom NAT behavior. Rules created manually through SSH may not appear in the dashboard and can take precedence over UI-managed rules.

Check Whether the Firewall Is Enabled

cat /etc/jelastic/metainf.conf

Confirm that FIREWALL_ENABLED is set to 1. If firewall support is disabled, contact the hosting provider.

Checking firewall enabled setting via SSH — Checking the firewall status through SSH.

Add a Custom nftables Rule

vim /etc/nftables/user-defined.nft

For example, the following rule blocks new TCP connections from 111.111.111.111 to destination port 1111:

insert rule ip filter INPUT ip saddr 111.111.111.111 ct state new tcp dport 1111 counter drop

Custom nftables firewall rule — Example custom nftables rule.

Legacy containers: Older CentOS 7-based containers may use iptables instead of nftables. Use the appropriate configuration method for the operating system and IP version.

Restart and List Firewall Rules

sudo /usr/bin/jem firewall fwstart

sudo jem firewall list \;

Configure Rules Through the Platform API

Firewall configuration can also be automated through platform environment-security API methods.

AddRule / AddRulesCreate one firewall rule or multiple rules.

EditRuleUpdate the parameters of an existing rule.

GetRulesRetrieve the current firewall rule list.

RemoveRule / RemoveRulesDelete one or more rules.

SetFirewallEnabledEnable or disable the environment firewall.

SetRuleEnabled / SetRulesEnable a rule or replace the active rule set.

Important Notes

Inbound traffic that does not match an allow rule is denied by default.
Outbound traffic that does not match a rule is allowed by default.
Lower priority numbers are evaluated before higher values.
Do not remove mandatory system firewall rules.
Use separate rules for IPv4 and IPv6 source addresses.
Rules configured through SSH may not be visible in the dashboard.
When making restrictive changes, keep a separate active session available so you can recover access if necessary.

Common Issues and Solutions

Issue	Likely Cause	Solution
Firewall section is missing	The feature is disabled by the hosting provider.	Contact platform support and request firewall activation.
Application becomes unreachable	A required allow rule was removed, disabled, or placed after a deny rule.	Review rule priorities and restore required HTTP, HTTPS, SSH, or application-specific access.
A rule does not affect traffic	A higher-priority rule matches first.	Review the full rule order and adjust priority where required.
IPv4 and IPv6 values are rejected	Both address families were included in one custom-source rule.	Create separate IPv4 and IPv6 rules.
OPEN_INBOUND_PORTS changes are ignored	The variable was changed after installation.	Add or edit firewall rules manually after node creation.
An SSH-created rule is missing in the UI	Manually defined rules are not represented in the dashboard list.	Inspect the relevant nftables or iptables configuration and list active rules through SSH.
Scaled nodes do not receive expected custom source rules	Static IP addresses were used instead of an environment-layer source.	Use the Environment Nodes source so addresses can follow scaling changes.