Inbound IP rules: allow only IP ranges you trust
Allow only the IP ranges you trust to reach a Voroa web service: who can set rules, setup, CIDR rule format, what a blocked request sees, and common questions.
You can configure which IP addresses can connect to your Voroa services over the public internet:
By setting inbound IP rules, you grant access only to IP ranges you trust. It is the simplest way to lock down an internal dashboard, a staging site or an admin panel, because it does not depend on your own code getting an authentication check right.
Every workspace, on every plan, can set inbound IP rules for:
- Individual web services and static sites
- Individual managed Postgres databases, through their own allowlist; see connecting to Postgres from outside Voroa
After you add rules, Voroa only allows inbound connections from the IP ranges you specify. Requests from
any other address are automatically blocked with a 403 Forbidden response. Voroa blocks them before
they reach your service, so your code never runs for a blocked request.
Inbound IP rules apply only to connections from the public internet. They control who can reach your service, not which addresses your service can connect out to.
Permissions
| Resource | Required role | Plan requirement |
|---|---|---|
| Web service or static site | Admin, Developer or Contributor* | All workspaces |
| Managed Postgres | See connecting to Postgres from outside Voroa | All workspaces |
*In a protected environment, new rules cannot be added. Removing a rule is always allowed, so you can never lock yourself out for good.
Setup
Managed Postgres
A managed Postgres database has its own allowlist for external connections. See connecting to Postgres from outside Voroa.
Web services and static sites
- In the Voroa dashboard, open the service and go to Settings > Inbound IP Rules.
- If you have not added anything yet, the list is empty, and an empty list means everyone can reach the service.
- Enter an address or range under the list, add an optional description so you remember what it is, and
click Add rule. To remove a rule, click Remove next to it.
- Learn more about the rule format below.
The moment you add your first rule, every address not on the list is blocked. Add the address you are working from first, or you will lock yourself out of your own service. If that happens, remove the rule: removing is always allowed.
That’s it. Your new rules take effect within a few seconds. Nothing is redeployed and your service is not restarted.
Rule format
Inbound IP rules are allowlists of IP ranges written in CIDR notation. Voroa allows connections from the ranges you list and blocks connections from all other IPs.
Only IPv4 ranges are supported. An IPv6 address is refused. If some of your visitors arrive over IPv6, a rule written for their IPv4 address does not cover those requests.
Some example rules:
| Rule | Meaning |
|---|---|
| (no rules) | Allow any IP address. This is the default for every service. |
203.0.113.0/24 |
Allow IP addresses 203.0.113.0 through 203.0.113.255. This might be a company’s office network or a trusted third-party service. |
198.51.100.16/29 |
Allow IP addresses 198.51.100.16 through 198.51.100.23. This smaller range of 8 addresses might be one subnet of an office network. |
203.0.113.42/32 |
Allow only the IP address 203.0.113.42. The /32 suffix limits the rule to that one address, which is useful for allowing only your own development machine. A bare address without /32 is accepted and treated the same way. |
A service can have up to 20 rules.
How rules are applied
Every request from the public internet is checked against the service’s rules before it is passed on.
An address that matches any rule is allowed through to your service; any other address gets
403 Forbidden and the request goes no further:
The rules apply to every address the service answers on: its Voroa address (onvoroa.com, and getvoroa.com for older services) and every
custom domain.
FAQ
Can I set IP rules for a background worker or a cron job?
No. These service types never receive traffic from the public internet, so the setting is not shown for them.
How do I allow connections from all IP addresses?
Remove all of the service’s rules. With no rules, every address can reach the service; this is the default.
What happens if I delete all rules for a service?
The service is open to everyone again. (This is the opposite of a list that blocks everything: on Voroa, an empty list never blocks traffic.)
Why are my visitors blocked even though their address is on the list?
Voroa checks the address of the connection it actually receives. If your visitors reach your service through another CDN or proxy in front of Voroa, the address Voroa sees is that proxy’s, not your visitor’s. Allow the proxy’s ranges instead.
Does a service with IP rules keep DDoS protection and edge caching?
No. A service with inbound IP rules is served directly rather than through the edge network, so DDoS protection and edge caching do not apply to it while it has rules.
Do inbound IP rules block TCP connectivity checks?
Usually not. Voroa enforces inbound IP rules when it receives an actual request (for example an HTTPS
request), after the initial TCP connection is established. Tools like nc and telnet that only test
whether a socket opens can show a successful connection from a blocked address. Real requests from that
address are still blocked.