Allowlist

1. The idea
2. Entries
3. Never allowed
4. Open mode
5. Changing the list
6. Tips
7. What a refusal looks like

The idea

Static egress is deny by default. The egress node forwards a connection only when its destination and port match an entry on your list, and refuses the rest. When you hand your address to a database owner, you can say exactly what it can reach.

There are two allowlists, and you need both:

• Ours: the destinations your jobs may reach through your address. You control it, and this page is about it.
• Theirs: the destination's own list of source addresses it accepts. Give its owner your dedicated address (both addresses, on Pro).

Entries

An entry is a destination plus the ports you may use on it.

• A host name entry does not allow its address. Connecting to the IP address that a listed name resolves to is refused, unless that address is listed too. Connect by name.
• Names are checked after resolution. If a listed name resolves to an internal or otherwise blocked address, the connection is refused, so a DNS change at the destination cannot point your address at something it should not reach.
• WireGuard mode uses address ranges and ports only. Host names are not used there, and ping (ICMP) is dropped. Route the same ranges in your AllowedIPs.
• The proxy carries TCP. The proxy port opens a TCP connection to the destination.

Never allowed

Some destinations and ports are refused whatever the list says. You cannot ask for them on a static egress address.

• Internal address space: RFC 1918 ranges, loopback, link-local, carrier-grade NAT space (100.64.0.0/10) and cloud metadata addresses.
• Our own nodes and the addresses of other customers.
• TCP ports 23, 25, 135 to 139 and 445. Outbound mail on port 25 is not available on static egress. It is a separate, reviewed option on IP Tunnel.

Open mode

Instead of a fixed list, an account can be moved to an open mode, where the node forwards to public destinations except those in the blocked list above. It is off by default. We consider it after 14 days of use and a manual review, and it does not lift any of the blocks above. Most integrations are better served by a list: it is what lets a destination owner trust your address.

Changing the list

Email support@penduses.com, or use your dashboard once it is live. For each change give:

• your workspace name, and on Pro which address (or both);
• the host name or address range, and the ports;
• what needs it (a workflow or a service), so that we can tell a mistake from a request.

In the pilot a person applies the change during business hours (Monday to Friday, 09:00 to 17:00 Central European Time). Once it is applied, the egress node picks it up within seconds. To remove an entry, ask the same way, and remove it from the destination's own list too.

Tips

• List what a job needs, and nothing more. A short list is easy to review and to explain to a destination owner.
• Prefer host names in proxy mode. Addresses behind a service move. A name follows them.
• Use /32 for a single host and a range only when you mean the whole range.
• Add the service you verify with. The source IP check needs an echo service on the list. See Verify the source IP.
• Keep other traffic off the proxy. In CI, set the proxy only on the steps that need the dedicated address, so that downloads and registries need no place on your list. See GitHub Action.
• Review it. When an integration ends, remove its entries.

What a refusal looks like

A wrong password is a different answer, 407. See Troubleshooting for what to check.