VPS firewall rules should describe who can reach each service and why that connection is needed. A firewall that blocks everything can make a website unusable, while a rule that accepts everything provides little control. The useful target is a tested set of necessary paths with an explicit administrative recovery route.
A VPS may have both a provider firewall and a firewall inside Linux. Containers, private networks and IPv6 can add further details. Tools differ across distributions, so this article focuses on planning and verification rather than a universal set of commands that could interrupt your connection.
This workflow on getaboutcolumbia explains how to map services, apply rules without losing access and diagnose the layer responsible when a connection fails. It also shows why a successful local test does not prove that outside traffic will work.
Write down the connections before editing rules
For each service, identify the destination port, protocol, listening address and permitted source. A public web server normally needs public web connections, whereas SSH can often be limited to a trusted administrative network or VPN. A database used only by the local application may need no public listener at all.
Include outgoing dependencies. The application may contact a payment service, email provider, package repository, DNS resolver or remote backup destination. If outbound access is restricted, those paths need deliberate treatment. Do not assume the hostname of an external service maps permanently to one address unless the service explicitly supports that arrangement.
Complete SSH access verification and recovery preparation before changing any rule that could affect remote administration. Keep the existing connection open, confirm the actual SSH port and source address, and test the provider console. A browser console is useful only if it has already been proven available to the person making the change.
Separate public and private communication in the plan. For example, an application server might accept public HTTPS while a database accepts connections only from that application's private address. This reduces exposure, but private networking still requires authentication, authorization and suitable transport protection; being on a private route does not make every client trustworthy.
Understand the two main enforcement layers
Ubuntu's firewall documentation explains its host firewall tooling, including UFW. Red Hat's firewalld documentation describes a different management model involving zones and runtime or persistent configuration. Use the tool intended for the installed system, and avoid mixing several managers unless you understand which component owns the effective rules.
Provider firewalls act outside the guest operating system. DigitalOcean's firewall rule documentation illustrates how inbound and outbound rules can be scoped to particular sources and destinations. The same traffic must satisfy every applicable layer. An operating system rule allowing a connection cannot override a provider rule that drops it first.
A practical hypothetical deployment has one web server and one database server. The web server accepts public web traffic and restricted administration. The database accepts its database protocol from the web server's private address and administration through an approved route. The plan also records backup traffic and health checks, because neither should be discovered accidentally during an outage.
Use comments or a separate rule register to explain each permission. Record the owner, business purpose and whether the rule is temporary. A temporary migration allowance that never expires can become a permanent opening no one remembers requesting.
If Docker or another container runtime is involved, evaluate its networking behavior separately. The responsibilities of running Docker on a VPS include understanding published ports and their interaction with firewall rules. Testing only the host's ordinary service ports may miss a container endpoint exposed through a different path.
Apply changes incrementally and verify outside the server
Save or export the existing configuration through the supported tooling. Establish the intended administrative allowance first and test it from a fresh connection before removing older permissions. When the firewall supports a documented timed rollback, it can provide additional protection, but it does not replace the console and second-session checks.
Apply one logical change at a time. Test the permitted path from an authorized source and the rejected path from a source that should not have access, using systems you control. For public web traffic, test the actual domain, TLS endpoint and application response rather than only whether a TCP connection opens.
Inspect listening services when a rule appears correct but the connection still fails. A process bound only to a loopback address will not accept a remote connection merely because the port is permitted. Conversely, a service bound broadly may be exposed if an expected filtering layer is absent or attached to the wrong instance.
Check persistence during a planned maintenance window. Some tools distinguish current runtime rules from rules loaded after reboot. A configuration that works now but disappears on restart is unfinished. Verify IPv6 independently whenever the server has an IPv6 address or an AAAA record, following the same intended access policy for both address families.
Mistakes to avoid
Do not disable the entire firewall to diagnose a single failing path, restrict SSH to an address you have not confirmed or assume default web ports cover custom application listeners. Avoid blocking essential IPv6 control traffic indiscriminately; IPv6 connectivity and firewall checks explain why that can break otherwise valid traffic. Review abandoned migration rules after the migration ends.
Two final recommendations
Maintain a short connection inventory beside the deployment record. When someone requests a new rule, require the source, destination, protocol and operational reason so the change can be tested and later removed accurately.
Make firewall review part of service removal and server replacement. Retiring an application should also retire its obsolete permissions, monitoring exceptions and temporary administrative routes.
Conclusion
VPS firewall rules work best when they follow the application's real connection paths. The goal is controlled reachability with preserved administrative access and a known recovery method.
Account for provider and host layers, confirm listening addresses and test the intended policy from outside the server. Include persistent configuration and both IP families in the verification.
Keep the rule set understandable. A small collection of permissions with clear owners and reasons is easier to maintain than a growing list of unexplained openings.
