IP Allowlists
Restrict a tunnel to specific IP addresses or CIDR ranges. Control who can open the public link and where the tunnel may be started from.
Summary
What is an IP allowlist?#
An IP allowlist restricts a tunnel to source addresses you list. Localport matches the source address of each connection against the list and refuses anything absent from it, before the connection reaches your service.
Every tunnel and fleet has two allowlists, under Network & Security in its Settings. Neither is set by default.
| Inbound IP Whitelist | Network IPs | |
|---|---|---|
| Restricts | Source addresses that may reach the tunnel | Source addresses the agent may connect from |
| Applies to | Visitors opening the public address | The machine running the Localport agent |
| Checked | On each new connection, and on every HTTP request | Each time the agent connects |
| When empty | Any address may reach the tunnel | The agent may connect from any address |
Editing either list requires the Admin role.
Accepted address formats#
Both fields take a comma-separated list mixing single addresses and CIDR ranges, in IPv4 or IPv6.
203.0.113.4, 198.51.100.0/24, 2001:db8::1
Each list holds up to 50 entries. A range counts as one entry however many addresses it covers, so 198.51.100.0/24 is a single entry standing for 256 addresses. An entry that is neither a valid address nor a valid range is refused when you save, and the field names the entry at fault.
Restrict who can reach the tunnel#
1. Open the tunnel's Settings and find Network & Security.
2. Enter the addresses in Inbound IP Whitelist, separated by commas.
3. Click Save.
Use an inbound allowlist when the audience for a link is a known network, such as an office range, a customer's VPN, a partner's fixed egress address, or the published ranges of a monitoring service.
An unlisted caller receives no response. The connection closes before anything is routed to your service, so a restricted tunnel is indistinguishable from one that does not exist.
The check runs on the connection, so it covers every protocol: HTTP, HTTPS, TCP and TLS. On an HTTP tunnel it runs again on each request.
Matching uses the connection's own source address. Forwarded headers such as X-Forwarded-For are not read, so a caller cannot present an address it does not hold. The address is the only thing examined: no header, path or body takes part in the decision.
Use your public IP address
curl https://api.ipify.org.Restrict where the tunnel can start#
Put the addresses in Network IPs and save. The agent can then bring this tunnel online only from those addresses. Use it for a machine with a fixed address, such as a deploy server, a bastion host, or hardware in a fixed location.
The check runs as the agent connects. From an unlisted address the tunnel does not come online, and the agent reports the refusal instead of retrying.
The tunnel token alone is then not enough to publish the tunnel. The connection also has to originate from a listed address.
Allowlists on a fleet#
A fleet carries the same two allowlists, set once for the whole fleet. There is no per-device list.
Inbound IP Whitelist covers every device address under the fleet. A rejected visitor reaches no device on it, whichever one they addressed.
Network IPs covers every device that connects, including devices that join later. A device on an unlisted network cannot join the fleet.
Applying changes#
Saving applies both allowlists immediately, with no restart and no reconnection.
- Inbound IP Whitelist: connections the new list rejects are closed, on every protocol. Widening or clearing the list leaves every connection in place.
- Network IPs: a connected agent whose address the new list rejects is disconnected, and does not reconnect. On a fleet this covers every affected device.
- A tunnel that is offline picks up both lists the next time it connects.
Order of checks#
An IP allowlist filters by source address. It does not authenticate the caller, so any client on a listed network is admitted.
On an HTTP tunnel the checks run in a fixed order on every request: the IP allowlist, then the client certificate on a fleet, then the password, then your header rules, then the webhook signature. The first refusal ends the request.
- Basic Auth puts a username and password in front of an HTTP tunnel.
- Header Authentication requires a header you name, carrying a value you set. It suits scripts and API clients.
- Webhook Verification checks the signature the sending platform attaches, against your signing secret.
- Remote Access identifies each caller by a certificate you issued, and decides which of your devices that caller may reach.
Frequently asked questions#
How do I restrict my tunnel to one IP address?
Open the tunnel's Settings, put the address in Inbound IP Whitelist under Network & Security, and save. Only that address can open the link from then on. Clear the field to allow anyone again.
What is the difference between Inbound IP Whitelist and Network IPs?
Inbound IP Whitelist restricts the source addresses that may reach the tunnel over its public address. Network IPs restricts the source addresses the Localport agent may connect from when it brings the tunnel online. The first applies to your visitors, the second to your own machine.
What does a blocked visitor see?
No response. The connection closes before anything is routed to your service, so a restricted tunnel is indistinguishable from one that does not exist. There is no error page and no status code.
Do allowlist changes affect connections that are already open?
Yes. Saving a narrower Inbound IP Whitelist closes the connections the new list rejects, on every protocol, and a narrower Network IPs disconnects any agent it rejects. Widening or clearing a list leaves every connection in place.
Can I use CIDR ranges?
Yes. Both fields take single addresses and CIDR ranges in the same comma-separated list, in IPv4 or IPv6, such as 203.0.113.4, 198.51.100.0/24.
How many addresses can I add?
Up to 50 entries per list. A CIDR range counts as one entry however many addresses it covers, so a /24 costs one of the 50 and admits 256 addresses.
Does an IP allowlist apply to every device on a fleet?
Yes. A fleet holds one Inbound IP Whitelist and one Network IPs list, and both govern the whole fleet. A visitor the inbound list refuses is refused for every device, and every device has to connect from an address on the Network IPs list.
Does an IP allowlist work on TCP tunnels?
Yes, on every protocol. The check runs on the connection before anything is routed to your service, so HTTP, HTTPS, TCP and TLS are covered by the same list.
I locked myself out. What now?
Clear the field in the dashboard and save. A tunnel's allowlist does not apply to the dashboard, so it remains reachable. To avoid a repeat, read your public source address with curl https://api.ipify.org from the machine you connect from and list that.
Is an IP allowlist enough on its own?
An IP allowlist filters by source address and does not authenticate the caller, so any client on a listed network is admitted. Combine it with Remote Access where each caller has to present a certificate you issued.
What to read next#
- Basic Auth. A username and password in front of an HTTP tunnel.
- Header Authentication. Require a shared header value.
- Webhook Verification. Prove a webhook came from the provider.
- Remote Access. Per-caller identity with client certificates.
- HTTP Tunnels. The tunnel these settings sit on.
- TCP Tunnels. Databases, SSH and game servers.