Outbound IP ranges for firewall allow-lists
The two subnets Paige connects from, the firewall rules that let its FTP and Content Central exports through — including the passive-FTP port range most setups miss — and how to verify from the right side of your network.
Paige connects outbound from two subnets, both located in the USA:
| Subnet | Location |
|---|---|
34.34.225.0/24 | USA |
34.96.49.0/24 | USA |
Allow inbound traffic from both ranges on the destination server, and you're done. The rest of this page is the detail that makes the rule actually work.
When you need this
Paige is a cloud service, so anything it delivers to your network arrives from Ademero's cloud rather than from a machine on your own network. You need these ranges whenever Paige must reach a destination you control — most commonly:
- FTP or FTPS delivery — Paige exports processed documents to a drop folder on your server.
- Content Central delivery — Paige exports into an on-premise or self-hosted Content Central instance.
- Any other endpoint on your network that Paige is configured to send to.
If your firewall denies inbound traffic by default — as most do — exports will fail until these ranges are allowed.
How to apply them
On the firewall protecting the destination server, create an inbound rule that allows the two subnets above to reach the service Paige is delivering to. Two things to get right:
Allow both ranges, not just one. Paige may connect from either subnet, and which one it uses can vary between runs. Allowing only the range you happened to see in a log produces intermittent failures that are difficult to diagnose.
Filter on the source IP address only — never on the source port. Outbound connections use ephemeral source ports that change on every connection, so a rule that pins a source port will block traffic unpredictably. Match on source IP and destination port, and leave the source port unrestricted.
FTP and FTPS destinations
FTP needs two things open on your side, and both matter:
- The control connection — inbound TCP port 21, or your custom control port.
- The passive data port range — the block of high ports your FTP server is configured to use, commonly a range such as 50000–51000. Passive FTP negotiates a second connection on one of these ports for the actual file transfer.
A common failure looks like success at first: Paige authenticates without trouble, then the transfer hangs and times out. That is almost always the passive range being blocked while port 21 is open. Confirm the passive range your FTP server is configured to use, and allow that range inbound from both Paige subnets as well.
If your server sits behind NAT, also make sure the FTP service is configured to advertise its public IP address in passive-mode responses. With FTPS the control channel is encrypted, so your firewall and NAT device cannot inspect or rewrite that response for you.
Content Central destinations
Allow the two subnets inbound to the port Content Central listens on — typically 80 or 443, or a custom port if your deployment uses one — and make sure that port is reachable from outside your network.
Verifying it works
Test from outside your own network. A connection that works from a workstation on your local network proves nothing about whether Paige can reach you, and many routers will not loop a connection from inside the network back to your own public address.
The most reliable check is to trigger an actual export from Paige and confirm the file arrives. For a quicker preliminary test, connect to the public address and port from any connection outside your network — a phone hotspot works.
If exports are still failing
| Symptom | Likely cause |
|---|---|
| Connection refused, or times out immediately | The inbound rule is missing, or the port forward doesn't reach the destination server |
| Login succeeds, but the transfer hangs or times out | The passive FTP port range isn't allowed, or the server is advertising a private IP address in passive mode |
| Works sometimes, fails other times | Only one of the two subnets is allowed |
| Works from inside your network, fails from outside | The rule was tested from the local network — retest from an external connection |
Keeping this current
These ranges are stable but not guaranteed to be permanent. Before a large deployment or migration, confirm with Ademero support that the ranges above are still current — and let support know if your firewall policy requires advance notice of changes.