IP allow-lists and deny-lists — locking the tunnel to your sources

Every Nodetonet tunnel ships with username and password authentication by default. That covers most cases, but credentials are just bytes — anyone you share them with, knowingly or not, gets the same access as you. Paste a proxy URL into a public Gist by mistake, commit it into version control, or let a script leak it through an error log, and the keys are out in the open.

The defence-in-depth answer is a per-tunnel source-IP firewall. You tell Nodetonet which client IPs may connect to a given proxy; everyone else is dropped at the TCP level before they even start the auth handshake. Even with the right credentials, a connection from the wrong IP gets nothing — not even an error message worth fingerprinting.

Allow-list vs deny-list: which mode to pick

There are two complementary modes, both configured per proxy:

You pick one mode per proxy, not both. An empty allow-list means "block everyone" — a fast kill switch if a tunnel is compromised. An empty deny-list is the same as Off.

If your client traffic comes from a dynamic home IP or a CGNAT mobile network, an allow-list will cause more headaches than it prevents. In that case, pair your tunnel with a VPN or cloud bastion that provides a fixed egress, then allow-list that egress address.

Where the setting lives in the panel

Open the proxy you want to lock on /proxies, click Settings, then switch to the IP Restrictions tab. You will see:

• A dropdown for mode — Off, Allow, or Deny.
• A textarea for entries, one per line.

Hit Save and the new rules take effect within a couple of seconds. Existing connections are not killed — only new handshakes are evaluated. So if you accidentally lock yourself out, an in-flight scrape keeps running until it finishes a request and tries to reconnect. Use that window to fix the entry and save again.

Entry formats: single IPs, CIDRs, and IPv6

Each line is a single address or a CIDR range, IPv4 or IPv6:

# single addresses
203.0.113.7
2001:db8::1

# CIDR ranges
198.51.100.0/24       # a whole /24 subnet
10.0.0.0/8            # your private VPN egress
2001:db8::/32         # IPv6 prefix

Comments after a # are stripped. Blank lines are ignored. Hostnames are not accepted — the panel rejects them with a clear error. Reverse-DNS at TCP-accept time is slow, spoofable, and unreliable, so we require explicit IPs. If you are unsure what your current egress IP is, our free What Is My IP tool shows exactly what a server reads from your connection.

What a blocked connection looks like

A blocked source sees the TCP connection succeed, but the proxy negotiation never starts — the server accepts and immediately closes. From curl this looks like:

curl: (52) Empty reply from server

From a SOCKS5 client you typically see a connection closed before handshake message. We deliberately say nothing about why — leaking "you are not on the allow-list" gives an attacker information they do not deserve.

To confirm a rule is working, watch the proxy's request log on the same page. Rejected attempts appear as BLOCKED · acl with the source IP recorded, so you have a full audit trail of who tried and when.

Setting rules programmatically via the REST API

The same controls are available on the REST API. This is especially useful in CI/CD pipelines where you want a job to add its current egress IP to the allow-list at the start of a run, then remove it at the end:

curl -X PATCH -H "Authorization: Bearer $KEY"   -H "Content-Type: application/json"   -d '{"aclMode":"allow","aclEntries":["203.0.113.7","198.51.100.0/24"]}'   https://nodetonet.com/api/v1/proxies/<id>

aclMode accepts off, allow, or deny. aclEntries is an array of strings in the same format the panel accepts. To clear all rules and revert to credential-only, send aclMode: "off" with an empty aclEntries array. You can also manage tokens and generate API keys through the features panel if you are building an automated workflow around multiple proxies.

Layering with per-client ACLs

If you have issued multiple proxy clients on a single tunnel — different credentials per downstream consumer — each client carries its own ACL as well. The evaluation order is:

1. Per-tunnel ACL — the source IP must pass this first.
2. Per-client ACL — if the source IP passes the tunnel-level check, the client-level rules narrow it further.

This means you can run one tunnel for several customers, each locked to their own office IP range, without creating a separate proxy for each. Pair this with per-client quotas and thread limits for a fully isolated multi-tenant setup on a single endpoint.

Combining IP restrictions with domain restrictions

IP restrictions control who can connect to your tunnel. For a complementary control over where the tunnel's exit traffic goes, see domain allow- and deny-lists. Together they give you a two-sided firewall: lock the source on the way in, and lock the destination on the way out.

Common pitfalls

• Forget your own IP. Test from a second connection before saving a restrictive allow-list so you cannot lock yourself out entirely.
• Dynamic home or mobile IPs. CGNAT on a mobile network means your IP changes with every reconnect. Either use a fixed-IP VPN egress or stick with credential-only auth.
• Over-relying on deny-lists. A determined attacker can rotate IPs. Deny-lists are a supplement, not a substitute — use an allow-list wherever your client IPs are predictable.
• Forgetting the proxy checker. After saving rules, run your proxy endpoint through our proxy checker from your allowed IP to confirm the connection goes through, and from a different connection to confirm the block works.

What's next

• Domain allow- and deny-lists — firewall the destination side of your tunnel.
• Per-customer proxy clients — scoped credentials with their own IP rules.
• Quota limits per client — cap bandwidth usage alongside access rules.
• Audit logs — when a blocked source matters, find out who it was.
• The Nodetonet quickstart — if your tunnel is not built yet.
• Create a free account and ship your first secured tunnel in minutes.