Skip to main content
Each VPS has its own firewall. It runs outside your server, and you choose which incoming traffic it lets in. You manage the rules from the Firewall tab on the server’s page. To open it, click My VPS in the sidebar, open your server, and select the Firewall tab. You can also get there from the Firewall rules link on the Access tab.
A running server's instance page open on the Firewall tab, with three findings at the top: Public SSH review, Web ports open and Outbound policy. Below them, the Firewall Rules card has Inbound (3) selected next to Outbound (0) and an Add rule button, above a table with Action, Protocol, Ports, Source, Description and Priority columns that lists Allow rules for TCP ports 22, 80 and 443 from 0.0.0.0/0, described as Default SSH access, HTTP and HTTPS, each with edit and delete icons.

A server's Firewall tab with inbound rules for SSH and web traffic

​
How the firewall works

  • Inbound traffic needs a rule. After you save a change, traffic reaches your server only on ports that an enabled rule allows.
  • Outbound traffic is allowed. Your server can connect out to the internet without any rules.
  • New servers allow SSH from anywhere. When a new server is ready, its firewall allows TCP port 22 from any address: from any IPv4 address (0.0.0.0/0) if the server has a public IPv4 address, and from any IPv6 address (::/0) if it has a public IPv6 address. These rules have the description “Default SSH access”, so you can connect right away.
  • New Windows servers have only the SSH rule. To connect with Remote Desktop, add a rule for TCP port 3389. See the recipe below.
  • SSH must stay open. Every save must keep an enabled Allow rule for TCP whose ports include 22. This keeps you from locking yourself out, and it applies to Windows servers too.
  • Every save replaces the whole rule set. When you add, edit or delete one rule, SinarCloud updates your server’s firewall to match your complete list of rules. If the update fails, your rules don’t change.
The Firewall Rules card has two views, Inbound and Outbound, each with its number of rules. Your rules appear under Inbound, ordered by priority. Each row shows the rule’s Action, Protocol, Ports, Source, Description and Priority, with buttons to edit or delete it. A rule that isn’t enforced shows Disabled next to its action. Outbound stays empty because outbound rules aren’t supported yet. The line under the views says when the rules last changed. Your most recent change also shows as Firewall rules updated under Recent activity on the Overview tab.
While a server is still being created, its firewall has no rules yet. The card shows No inbound rules. and says nothing can reach the server until you add one, including SSH. The line under the views shows a firewall status such as NOT_CONFIGURED. The SSH rule appears when the server is ready, which usually takes 1–2 minutes. Wait for it before you add other rules.

​
Supported rules

The firewall currently supports Inbound rules with the Allow action for TCP or UDP, from an IP address or range.
The rule form also offers Outbound, Block, ICMP (ping), All protocols and the Ping service. You can’t save rules with these options yet. If you try, the dialog shows an error and your rules don’t change.
Because ICMP rules aren’t supported yet, don’t expect your server to answer ping. To check that a service is reachable, test its port instead, for example with ssh or curl.

​
Add a rule

1

Open the rule form

On the Firewall tab, click Add rule. The Add firewall rule dialog opens.
2

Choose a service or set the details

Under Common services, click the service you want to open. This sets an Inbound Allow rule for you. For web services, an empty Source is filled in with any address. For SSH, RDP, MySQL and PostgreSQL, enter the address you connect from.Or set the details yourself. If you opened the form from the Outbound view, Direction starts on Outbound, so switch it to Inbound. Then set Action to Allow, choose TCP or UDP, and enter the Ports.
3

Set the source

Enter an IP address or range in Source, or click Anywhere IPv4 or Anywhere IPv6. If you open SSH, Remote Desktop, VNC or a database port such as MySQL, PostgreSQL, SQL Server, Redis or MongoDB to any address, the dialog warns you. Limit the source to your own address where you can.
4

Check and save

Read the summary above Advanced, for example “Allows inbound TCP traffic on port 443 from any IPv4 address.” Then click Add rule. If you entered a list of ports, the button reads Add 2 rules, for example. When your server’s firewall is updated, you see Firewall rule added. (or 2 firewall rules added.) and the new rules appear in the list.
If a matching rule already exists, the dialog tells you before you save, for example “There’s already a matching rule for port 22.”

​
Edit or delete a rule

To change a rule, click the pencil icon (Edit rule) in its row. Update the fields in the Edit firewall rule dialog, then click Save changes. You see Firewall rule updated. when it’s done. To remove a rule, click the trash icon (Delete rule) in its row. Check the rule in the Delete firewall rule dialog, then click Delete rule. You see Firewall rule deleted. when it’s done. Two limits protect you from locking yourself out:
  • You must keep at least one rule. You can’t delete your last rule. The dialog says “This is the last rule.” and Delete rule stays disabled. Add a replacement first.
  • You must keep an SSH rule. To change where SSH is allowed from, edit the existing SSH rule, or add the new SSH rule before you delete the old one.

​
Common recipes

The default SSH rule accepts connections from any address. To accept SSH only from your own network:
  1. Find your public IP address, for example by searching “what is my IP” in your browser.
  2. Click Edit rule on the rule for TCP port 22 from 0.0.0.0/0.
  3. Replace the Source with your address, for example 203.0.113.10, and click Save changes.
  4. If your server also has an SSH rule from ::/0, delete it, or edit it to your IPv6 address.
If your IP address changes, SSH connections from the new address are blocked. Come back to this tab and update the rule. You don’t need SSH to edit the firewall.
If you also run a firewall inside your server’s operating system, such as ufw or Windows Defender Firewall, open the same ports there too. Traffic must pass both firewalls.

​
Review findings

The top of the Firewall tab reviews your current rules and shows up to three findings:
  • Public SSH review: an enabled rule opens TCP port 22 to any address. The finding reads “SSH should stay limited to trusted IP ranges.” Consider limiting SSH as in the recipe above.
  • Web ports open: TCP port 80 or 443 is open to any address. This is expected for a public website.
  • Outbound policy: outbound traffic uses the default allow policy.

​
If a save fails

Before saving, the console checks that nobody else changed the rules since you opened the dialog. If they changed, you see “The firewall changed while you were editing.” Close the dialog, review the latest rules, and try again.
Check that the rule is an Inbound Allow rule for TCP or UDP, that each priority is different, and that an enabled SSH rule for port 22 remains. If you entered a list of ports, leave Priority empty so each new rule gets its own number. Fix the field and save again.
Check that the rule isn’t marked Disabled, and that its Source includes the address you connect from. Then check the firewall inside your server’s operating system, and make sure an application is listening on that port.
The buttons are disabled while a change is saving. They stay disabled while a server is being deleted and after it is deleted, because its firewall is then read-only.
The console couldn’t read your server’s rules. Click Retry. Your rules haven’t changed.
If a save keeps failing, see Troubleshooting or get support.