low cost vps server: which firewall layer opens a port?
If an application is unreachable, first identify whether the provider rule or the VPS operating-system firewall controls that traffic: an OVHcloud edge allow rule cannot open a port blocked inside the guest, while IONOS VPS policies handle incoming requests and netcup policies can handle both directions.
The decision in one pass
A port rule belongs to a particular control point. Record the server product, public IP, direction, protocol, port and source network before changing anything. Then check the provider control plane and the guest operating system separately wherever the product uses more than one layer. This prevents an edge filter from being treated as the server's local firewall. [A] [B]
Practical model (inference): an outside connection can reach an application only when every applicable network filter permits it and the application is listening on the target. The provider pages describe filtering and point to the server or OS firewall; the listener check is an operational diagnostic, not a provider guarantee. [A] [C]
What the provider pages establish
| Provider / product | Control point | Published behavior | What the page does not establish |
|---|---|---|---|
| OVHcloud VPS | Edge Network Firewall plus guest firewall | The edge filter concerns traffic arriving from outside OVHcloud. It cannot open a server port; the OS firewall is the documented route. The checked page says IPv4 only and up to 20 rules per IP. [A] | Whether an application listens or a guest rule is correct. |
| IONOS VPS / VPS+ | Cloud Panel policy for incoming requests | The page lists assigned IP, allowed IP, protocol, port and policy history. Its VPS policy editor creates incoming-request rules. [B] | Outbound-policy controls on this page or guest firewall state. |
| netcup servers with firewall feature | SCP ingress and egress policies | A saved rule changes that direction's implicit default to DROP. UDP request and response traffic needs both directions. The page states up to 500 active rules per server and public interface; the page lists availability from Generation 9 onward. [C] | Whether a specific server has the feature enabled or policy assigned. |
Trace the failing path
Use this sequence before adding a broad allow rule:
- Confirm the destination. Match the public IP to the intended VPS and policy. A rule attached to another address cannot validate the path. OVHcloud documents edge rules per IP; IONOS shows the assigned IP in policy details. [A] [B]
- Write down direction and protocol. Incoming traffic differs from a server's outgoing request. For UDP on netcup, check request and reply paths; its guide says responses are not tracked like TCP. [C]
- Check the provider layer. Verify active policy, source range and destination port. For OVHcloud, treat the edge layer as a filter and inspect the guest firewall separately. [A] [B]
- Check the guest layer and listener. Inspect the operating-system firewall and confirm that the application listens on the expected address and port. Provider pages do not show a reader's live server state. [A] [C]
- Retest from outside and record it. Keep source network, destination IP, protocol, port, time and result together. Keep an independent console route available before changing remote-administration rules.
Inference boundary: if a provider rule matches but a service still fails, inspect the guest firewall, listener and application configuration. This narrows troubleshooting but does not identify the cause until each is checked.
Which layer should you change?
| Condition | Next check | Keep this evidence |
|---|---|---|
| Provider rule filters traffic before it reaches the VM | Check the guest firewall as well as the OVHcloud edge rule. [A] | Public IP, edge rule, local rule, protocol and outside result. |
| Provider control is an incoming policy | Check that IONOS policy and guest firewall; do not assume outbound control. [B] | Policy assignment, allowed source, protocol, port and guest rule. |
| A new netcup policy blocks unrelated traffic | Review the implicit DROP behavior for that direction and add only required paths. [C] | Ingress and egress rules, priority, save time and result. |
Do not infer an open port from a firewall product or saved rule. Verify the effective policy and test from outside against the intended service.
A minimal change record
- Copy the product name and target IP from the control panel.
- Identify the application and source networks; use the application's documentation for port and protocol.
- Record whether traffic is inbound, outbound or both.
- Change the narrowest matching provider rule, then inspect the guest firewall separately.
- Run an outside connection check and save the result. If it fails, revert the last change before widening access.
This is a review method. No firewall policy was changed and no VPS connectivity test was run for this article.
Questions VPS buyers ask
Can a provider firewall open a port when the app is not listening?
No. A rule can permit traffic but does not start an application. Check the listener and guest firewall separately; this is a troubleshooting inference from the documented control layers.
Does an OVHcloud edge rule replace the firewall inside a VPS?
No. OVHcloud says its edge firewall filters outside traffic and points to the operating-system firewall for opening server ports. [A]
Does an IONOS VPS firewall policy configure outbound rules?
The checked VPS policy page describes incoming-request rules. It does not establish outbound-rule controls. [B]
Method and limits
I checked the official English pages linked below on October 4, 2026. The table paraphrases their stated product scope and behavior; no account panel, firewall configuration, port scan or VPS was used. OVHcloud's edge feature note is IPv4-specific, IONOS's cited rules concern VPS/VPS+ incoming requests, and netcup's firewall availability depends on server generation and assigned policy. The pages do not show an individual reader's settings.
This page supplies a dated three-provider rule-scope table, a trace sequence and a downloadable checklist; it does not claim no other page contains similar ideas.
Download the firewall check table
The CSV keeps provider scope, published behavior, limits and checked date together. It is a documentation comparison, not an open-port scan.
Download the comparison table (CSV)Official evidence and number sources
- A — OVHcloud: Enabling and configuring the Edge Network Firewall (scope includes public-IP services such as VPS; edge scope, guest-firewall boundary, IPv4 note and rule limits). Related VPS security guide: How to secure a VPS, last updated January 21, 2026.
- B — IONOS: Overview: Firewall Policies (VPS, migrated Cloud Servers, and VPS+). Defines VPS scope, assigned IP and incoming-rule editor; no publication date is shown in the checked page.
- C — netcup: Firewall. Defines ingress/egress behavior, TCP/UDP handling, implicit rules and limits; last update July 23, 2026.
Related: low cost VPS server: what can you do when SSH stops working?