Firewalls

Control network access to your instances with powerful, flexible firewall rules.

What are Firewalls?

Firewalls provide network security by controlling inbound and outbound traffic to your instances:

  • Rule-based Access: Define allowed and denied traffic
  • IP Whitelisting: Restrict access by IP address
  • Port Control: Open only necessary ports
  • Multi-instance: Attach one firewall to multiple instances
  • Stateful: Connection tracking for enhanced security

Key Features

🔒 Security

  • Control inbound and outbound traffic
  • IP-based access control
  • Port and protocol filtering
  • Default deny all approach

🎯 Flexibility

  • Attach to multiple instances
  • Support for CIDR blocks
  • Custom port ranges
  • Priority-based rule ordering

📊 Monitoring

  • View active rules
  • Track firewall status
  • Audit rule changes

Getting Started

Create a Firewall

  1. Navigate to Firewalls in the main menu and click Create firewall, or open an instance's Security tab and click New firewall to start with that instance already attached
  2. Enter a name and an optional description
  3. Add rules with the quick-add presets (SSH, HTTP, HTTPS, PostgreSQL and more) or with Add inbound rule / Add outbound rule
  4. Attach the instances the firewall should protect
  5. Click Create and deploy to push the rules right away, or Create firewall to keep it as a draft

Add Firewall Rules

Each rule has:

  • Direction: Inbound or Outbound
  • Action: Allow or Deny
  • Protocol: TCP, UDP, ICMP, GRE or ESP
  • Port: a single port, a range such as 8000-8080, or * for any port
  • Sources/Destinations: IP addresses, CIDR blocks, or other DanubeData instances

You can edit rules from two places:

  • The instance's Security tab (databases, caches, VPS, queues and serverless containers): expand the firewall, click Edit rules, then Save or Save and deploy. You never have to leave the instance page.
  • The firewall page under Firewalls: click Edit rules in the Rules card.

Saved rules are not enforced until you deploy them. Save and deploy does both in one step; Deploy pushes the saved rules to every instance the firewall protects.

Attach to Instances

  • From an instance: open its Security tab and click Attach firewall, then pick a firewall. Its rules deploy to the instance right away.
  • From a firewall: open the firewall page and use Attach instance in the Protected instances card.

Firewall Rules

Rule Components

Each firewall rule has:

  • Direction: Inbound (incoming) or Outbound (outgoing)
  • Action: Allow or Deny
  • Protocol: TCP, UDP, ICMP, or All
  • Port(s): Port number, range, or "all"
  • Source: IP address or CIDR (for inbound rules)
  • Destination: IP address or CIDR (for outbound rules)
  • Priority: Lower numbers = higher priority

Rule Examples

Allow SSH Access

  • Direction: Inbound
  • Action: Allow
  • Protocol: TCP
  • Port: 22
  • Source: 0.0.0.0/0 (or your IP)

Allow HTTP/HTTPS

  • Direction: Inbound
  • Action: Allow
  • Protocol: TCP
  • Ports: 80, 443
  • Source: 0.0.0.0/0

Allow PostgreSQL from Specific IP

  • Direction: Inbound
  • Action: Allow
  • Protocol: TCP
  • Port: 5432
  • Source: 192.168.1.100/32

Allow All Outbound

  • Direction: Outbound
  • Action: Allow
  • Protocol: All
  • Port: All
  • Destination: 0.0.0.0/0

Deny Outbound SMTP (Anti-spam)

  • Direction: Outbound
  • Action: Deny
  • Protocol: TCP
  • Port: 25
  • Destination: 0.0.0.0/0

Default SMTP Blocking

All new VPS instances include locked firewall rules that block outbound SMTP traffic:

  • Port 25 (SMTP) — Blocked
  • Port 465 (SMTPS) — Blocked

These rules are locked and cannot be removed or modified through the dashboard. They are in place to prevent spam and email abuse from the platform.

Need to Send Email?

If your application requires outbound SMTP access (e.g., running a mail server or sending transactional emails directly), you can request unblocking:

  1. Go to Support in the dashboard
  2. Create a new support ticket
  3. Include:
    • The VPS instance name/IP
    • Which port(s) you need unblocked (25, 465, or both)
    • Your use case and reason for needing direct SMTP access
  4. Our team will review and respond to your request

Tip: For most applications, we recommend using a third-party email service (e.g., Mailgun, Postmark, SendGrid) which uses port 587 (Submission) and is not blocked.

External Access to Managed Databases, Caches & Queues

Managed databases, caches, and queues are private by default — reachable only from resources inside your team's network, and from teams you have peered with.

When you enable public access (external DNS) on a managed database, cache, or queue, the instance gets a public hostname and external clients can connect right away: its default firewall allows the service port from any address. Turning public access back off closes the public endpoints again.

Restricting public access

The inbound rules of the instance's firewall apply to its public endpoints too, including a database's connection proxy endpoints and every queue protocol port.

  • Write rules for the service's standard port (5432 for PostgreSQL, 3306 for MySQL and MariaDB, 6379 for Redis, Valkey and Dragonfly, 5672 for AMQP), not for the public port in your connection string.
  • An allow rule from specific addresses, such as 203.0.113.10/32, limits public connections to those addresses. An allow rule from 0.0.0.0/0 keeps the endpoint open to everyone.
  • A deny rule wins over any allow rule.
  • If no allow rule covers the service port, the public endpoint rejects every connection.
  • Public connections only match public IP addresses and ranges. Private ranges (such as 10.0.0.0/8) and the resources a rule picks never match them.
  • Changes take effect within about 2 minutes. When a rule changes, open connections to that endpoint are closed once; clients that are still allowed can reconnect straight away.

Clients running inside DanubeData, such as VPS instances, serverless containers and other managed services, should use the instance's private hostname. On a restricted endpoint, their connections through the public hostname are rejected.

Restricting access inside your team

The same inbound rules decide, port by port, which of your own resources can connect over the private network. When several firewalls are attached, their rules combine.

  • A port with an allow rule that has no sources, or one from 0.0.0.0/0 or ::/0, is open to your whole team.
  • A port whose allow rules all list specific sources accepts only the resources those rules pick. Pick each one under Sources: serverless containers (their scheduled and one-off runs included), VPS instances, private networks, managed apps, and other databases, caches or queues.
  • A port that no allow rule covers is closed to your team's resources, just as the public endpoint is closed.
  • IP addresses, private ranges included, never match resources inside your team. A rule that lists only addresses keeps the port to those addresses on the public endpoint, and closed to your team.
  • If a resource a rule picks is deleted, the rule keeps restricting the port, and the firewall page shows the source as deleted until you remove it.
  • The instance's own replicas, connection proxies and metrics exporter, its backups, and SQL Studio always keep access.

Resources in other teams cannot reach your managed services at all. Teams you have peered with reach them only on ports that are open to your whole team.

For queues, enabling external DNS is also what exposes the MQTT, STOMP, and AMQP protocol ports — see Connecting via MQTT & STOMP.

Common Configurations

Web Server

Text
Inbound:
- Allow TCP 80 from 0.0.0.0/0
- Allow TCP 443 from 0.0.0.0/0
- Allow TCP 22 from your-ip/32

Outbound:
- Allow All to 0.0.0.0/0

Database Server

Text
Inbound:
- Allow TCP 3306 from your app (pick its VPS or container under Sources)
- Allow TCP 22 from your-ip/32

Outbound:
- Allow All to 0.0.0.0/0

Redis Cache

Text
Inbound:
- Allow TCP 6379 from your app servers (pick them, or their private network, under Sources)
- Allow TCP 22 from your-ip/32

Outbound:
- Allow All to 0.0.0.0/0

Development Server

Text
Inbound:
- Allow TCP 22 from your-ip/32
- Allow TCP 80, 443 from 0.0.0.0/0
- Allow TCP 3000-4000 from your-ip/32

Outbound:
- Allow All to 0.0.0.0/0

IP Addressing

Single IP

Use /32 for a single IP address:

Text
192.168.1.100/32

CIDR Blocks

Use CIDR notation for ranges:

Text
192.168.1.0/24    # 192.168.1.0 - 192.168.1.255
10.0.0.0/16       # 10.0.0.0 - 10.0.255.255

Special Addresses

Text
0.0.0.0/0         # All IPv4 addresses (anywhere)
your-ip/32        # Your specific IP only
10.0.0.0/8        # Private network range

Managing Firewalls

Edit Firewall

  1. Go to your firewall page
  2. Choose Edit name and description from the actions menu
  3. Click Save changes, or Save and deploy to push the rules at the same time

Add/Remove Rules

  1. Open the instance's Security tab or the firewall page
  2. Click Edit rules, then add, change or remove rules
  3. Click Save to store the changes, or Save and deploy to apply them to every protected instance

Deploy

  • Deploy on the firewall page or on the Security tab pushes the saved rules to all protected instances
  • Each protected instance shows its own deployment status (Deploying, Applied, Failed) and the error message when a deployment fails; a failed instance offers Retry on this instance in its actions menu

Attach/Detach Instances

  1. Go to the firewall page or the instance's Security tab
  2. Use Attach firewall / Attach instance, or Detach
  3. Changes apply within about a minute

Delete Firewall

  1. Detach from all instances first
  2. Go to firewall page
  3. Click Delete Firewall
  4. Confirm deletion

Best Practices

Security

  1. Least Privilege: Only allow necessary traffic
  2. Specific IPs: Use specific IPs instead of 0.0.0.0/0 when possible
  3. SSH Access: Restrict SSH to your IP
  4. Regular Audits: Review rules regularly
  5. Defense in Depth: Use firewalls + application security

Organization

  1. Naming Convention: Use descriptive names (e.g., "web-prod-fw")
  2. Documentation: Add descriptions to rules
  3. Reusability: Create firewalls for common use cases
  4. Separation: Separate firewalls for different environments

Performance

  1. Minimal Rules: Use as few rules as needed
  2. Order Matters: Place common rules first
  3. CIDR Blocks: Use CIDR blocks instead of multiple single IPs

Troubleshooting

Cannot Connect to Instance

  1. Check firewall rules allow traffic
  2. Verify correct port is open
  3. Check source IP is allowed
  4. Review firewall attachment

Accidental Lockout

  1. Use web console access
  2. Detach firewall from instance
  3. Fix rules
  4. Re-attach firewall

Rules Not Working

  1. Check rule priority
  2. Verify protocol and port
  3. Ensure firewall is attached
  4. Review direction (inbound vs outbound)

Firewall Status

Statuses

  • Active: Firewall is protecting instances
  • Updating: Changes being applied
  • Error: Issue with firewall configuration

Checking Status

  1. Go to your firewall page
  2. View status badge
  3. Check attached instances

Internal Instance Selection

Some instances can communicate privately:

Internal Sources

When creating rules, you can select:

  • IP Addresses: Specific IPs or CIDR blocks
  • Internal Instances: Other instances in your project

Benefits

  • No need to remember IP addresses
  • Automatic updates if instance IP changes
  • Simplified management

Example

Allow database access from specific app servers:

  1. Create inbound rule for port 3306
  2. Select "Internal Instances" as source
  3. Choose your app server instances
  4. Click Add Rule

Advanced Features

Source-based Filtering

Route rules based on:

  • IP address or CIDR
  • Specific instances in your project
  • Private network subnets

Port Ranges

Specify multiple ports:

Text
22          # Single port
80,443      # Multiple ports
3000-4000   # Port range

Protocol Options

  • TCP: Web, SSH, databases
  • UDP: DNS, VPN
  • ICMP: Ping, traceroute
  • All: All protocols

Next Steps

Need help? Contact our support team through the dashboard.