Use the PD DigitalOcean Droplets Firewall page to control incoming connections to a service. A cloud rule permits network traffic; it does not start an application or replace an operating-system firewall.

Check the service and source

Your customer opens the intended service in the Blesta client area. Your hosting team enables Client: Firewall on the package when customers should manage these rules. Review existing rules before making a change, especially the management access you currently depend on.

For SSH, use the port your server actually listens on, commonly 22. For a web service, 80 and 443 are common TCP ports, but add them only when the application should be reachable there. Choose the source address or network that needs access.

Add an inbound rule

These steps describe the customer’s service view. Agree any access change with your customer and preserve your existing authorised management access.

1. Open Firewall for the service.
2. Choose the add-rule control and select the appropriate protocol, such as TCP for standard SSH or HTTPS.
3. Enter the intended port or port range.
4. Enter the source address/range that should be allowed, using the form’s supported syntax.
5. Save and review the resulting rule list.
6. Test the intended connection from an allowed source and confirm unrelated management access still works.

Use a narrow trusted source for management access when appropriate. A public website may intentionally accept wider web traffic; that does not require opening SSH to the same broad source range.

Change access deliberately

Keep a working management method available while editing rules. If your internet connection’s public address changes, a rule for the old address will not match your new source. Review the address actually used by your connecting device or trusted network.

Remove obsolete rules only after confirming the replacement access works. Do not remove unfamiliar application rules just because they are unrelated to the change you are making.

If the port remains unreachable

Check the server state, destination address, cloud rule protocol/port/source, guest firewall and whether the application is listening. A server reporting Running does not prove the application is available. For SSH permission denied, use the key and login checks rather than repeatedly opening more ports.

If the rule itself fails to save, keep the displayed error and request time and compare the actual rule state before trying again. Avoid widening access as a substitute for diagnosing a provider permission or service-state error.

See the PD DigitalOcean Droplets Blesta guide for related tasks, or explore the module.