Your developer adds the office VPN range to a SaaS vendor's allowlist on Friday. On Monday, an assistant reboots the office router while fixing a printer, the public address changes, and the team loses access to an admin panel. The firewall rule didn't fail. The assumption that a network address would stay fixed did.
IP whitelisting remains useful for restricting administrative portals, APIs, servers, mail relays, and partner integrations. It also becomes fragile when cloud egress, mobile networks, reverse proxies, and SaaS vendor updates enter the picture. The practical challenge isn't only how to allow an address. It's deciding which address represents a trusted source, where to enforce the rule, and how to keep access working when that source changes.
What Whitelisting IP Addresses Really Means
An IP whitelist is an explicit access-control list. A protected service accepts connections from approved source addresses or ranges and rejects other sources by default. A blocklist takes the reverse approach, permitting general access while denying addresses linked to unwanted activity. Default-deny allowlisting narrows the entry path for sensitive services, but legitimate users can be locked out when their network conditions change.
The phrase whitelist IP addresses usually refers to a policy applied to a public source address, private subnet, or CIDR range. CIDR, or Classless Inter-domain Routing, expresses that scope without requiring a separate rule for every host. RFC 4632 from the IETF describes CIDR as a way to conserve the existing 32-bit IPv4 space and limit growth in global routing tables.
The four enforcement layers
A production allowlist can be enforced at several points:
- Host firewall: Linux or Windows filters traffic reaching one machine.
- Network firewall: A cloud security group, subnet firewall, or edge appliance filters traffic before it reaches the host.
- Application layer: A reverse proxy, web server, API gateway, or application evaluates the apparent source address.
- SaaS vendor panel: A hosted service applies its own network policy before granting access.
These layers maintain separate rules. A cloud security group may allow an address that the web server rejects, while a SaaS panel may deny traffic that passed every internal firewall. Cloud workloads often leave through shared or changing egress addresses, SaaS providers may require their own allowlist updates, and mobile carriers can assign rotating public addresses. A static rule therefore needs an owner, an update process, and a fallback path.
Proxy routing adds another check. Confirm whether the enforcement point sees the network origin or a forwarded client address, and review this guide to IP address spoofing before trusting proxy-supplied headers.
Practical rule: Whitelist the smallest range that works. Document where each entry lives, who owns it, why it exists, and how to revoke it.
Keep an out-of-band administrative path, such as a separate management channel or console access, so a changed egress address does not turn a routine network event into an outage. An allowlist controls network reachability. It does not replace authentication, device checks, logging, or change management.
Reading CIDR Notation Without Mistakes
A single mistyped prefix can open an entire network or block a legitimate cloud workload. CIDR notation makes the scope explicit: a base address, a slash, and a prefix length. The prefix length states how many leading bits identify the network. Administrators may also express the same boundary with a dotted-decimal netmask, but slash notation is more common in firewall rules, cloud consoles, and vendor documentation.
Three IPv4 examples
203.0.113.7/32 identifies one IPv4 host. Every address bit belongs to the network portion, making /32 the narrowest IPv4 allowlist entry. Use it for one stable administrator, gateway, or egress address.
203.0.113.0/24 contains 256 total addresses and 254 usable hosts. That range can suit a controlled office, VPN, or cloud subnet, yet it may still include systems unrelated to the service being protected.
203.0.0.0/16 contains 65,536 total addresses and 65,534 usable hosts. Such a prefix may represent a deliberately managed allocation, but an error here exposes a far wider set of sources. A /8 covers 16,777,216 addresses, compared with 256 for a /24. Approve broad prefixes deliberately, and verify the resulting range before saving the rule.
| Prefix | Addresses | Typical Use |
|---|---|---|
/32 |
One IPv4 host | A single fixed administrator or gateway |
/24 |
256 total, 254 usable hosts | A controlled subnet or office range |
/16 |
65,536 total, 65,534 usable hosts | A large managed allocation |
IPv6 uses the same principle. An individual host is commonly written as /128, while a delegated network may use /64. IPv4 and IPv6 require separate policy entries and separate tests.
Mistakes that cause outages
- Accidental
/0: This matches the entire IPv4 address space and defeats a narrow source restriction. - Wrong base alignment: The base address must sit on the network boundary defined by the prefix. Pairing a host address with a broad prefix can produce a range different from the one intended.
- Mixed address families: An IPv4 rule does not filter IPv6 traffic. If both protocols are active, create equivalent policies and test each path.
- Dynamic egress assumptions: A
/32works only while the address remains stable. Cloud NAT changes, SaaS allowlists, and mobile carrier assignments can invalidate it. A deliberately bounded range may survive rotation, but it also grants access to more sources.
Choose the smallest prefix that supports the expected DHCP, cloud egress, or carrier renumbering event. Then test both an address that should pass and one that should fail.
Whitelisting on Linux and Windows Firewalls
A host firewall is the last line of defense, not the first place to solve every access problem. Apply network-level restrictions where possible, then use the host firewall to limit exposure if a service is reachable through another interface or routing path.
Linux choices
For a legacy host or a rule that needs direct kernel-level inspection, iptables remains familiar:
sudo iptables -A INPUT -s 203.0.113.0/24 -j ACCEPT
That command accepts traffic from the specified range, but it doesn't create a complete default-deny policy by itself. Place an explicit reject or drop rule after required allow rules, and inspect rule order before making the change permanent.
For newer deployments, nftables is the modern packet-filtering framework and supports sets for managing multiple addresses efficiently. A set is easier to update than a long chain of individual rules, especially when a vendor publishes changing ranges.
Ubuntu administrators often choose ufw, a friendlier wrapper:
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
Use ufw when the team wants readable commands and uncomplicated service policies. Its application profiles can simplify common service definitions, but review the generated rules rather than assuming a profile matches your intended exposure.
Make the rule survive a reboot
A runtime rule that disappears after restart creates a false sense of protection. Save the firewall configuration using the persistence mechanism appropriate to the distribution, or manage it through configuration automation so the rule, owner, and review date remain part of the system's declared state.
For a single fixed management host, prefer a /32. Use a subnet only when the network administrator can explain why every address in that subnet should reach the service. The same principle applies to SSH, database ports, internal dashboards, and deployment endpoints.
Windows administrators can use the graphical firewall console or PowerShell:
New-NetFirewallRule -DisplayName "Office SSH" -Direction Inbound -RemoteAddress 203.0.113.0/24 -Action Allow -Protocol TCP -LocalPort 22
Keep the rule tied to a purpose, not an informal label such as “temporary access.” If your workflow depends on a proxy gateway, document the gateway's egress behavior and review proxy server configuration fundamentals before adding source ranges.
Test from an external host that should be allowed and another that should be denied. Testing SSH from localhost only proves that the machine can reach itself. It says nothing about the path, source address, or rule order seen by an outside client.
Allowlisting IPs in AWS, Azure, and GCP
Cloud allowlisting follows one repeatable pattern. Identify the correct boundary object, add a narrow inbound rule for the source address or CIDR, preserve a deny-by-default posture, then validate from the network path. The difficult part is often selecting the correct object, not writing the rule.
Find the boundary before editing it
In AWS, use a security group for an instance or load balancer. A network ACL applies at subnet level and uses stateless rules, while an AWS WAF IP set handles Layer 7 filtering for web traffic at supported edge and load-balancing surfaces.
Azure uses network security groups for VM and subnet traffic. Web-tier restrictions can also live in an edge WAF policy or an App Service access restriction, depending on where the application receives traffic.
GCP uses VPC firewall rules for ingress traffic, commonly narrowed with target tags. HTTP(S) load balancer traffic can receive an additional web-tier policy through an edge security service.
| Provider | Network-level rule | Web-tier allowlist | Common mistake |
|---|---|---|---|
| AWS | Security groups or network ACLs | WAF IP sets | Editing the wrong group attached to the wrong interface |
| Azure | Network security groups | Edge WAF or App Service restrictions | Restricting the VM while the application is exposed elsewhere |
| GCP | Ingress VPC firewall rules and target tags | Edge policy for HTTP(S) load balancers | Creating a rule that doesn't target the serving workload |
Validate the actual route
Record the source address visible at the enforcement point. A request from a developer's laptop may appear as a VPN gateway, NAT gateway, proxy egress, or load-balancer hop rather than the laptop's local address. Allow the address that the service sees, not the address displayed by an unrelated network interface.
Use a request such as curl from the approved external source, then inspect the response and access logs. Repeat from a denied source. If you're testing a web application, verify both the edge policy and the origin policy, because a successful edge response doesn't prove that the origin is protected from direct access.
Never leave 0.0.0.0/0 in place after testing. Temporary broad access is a common troubleshooting shortcut, but it becomes a permanent exposure when nobody owns the follow-up task. Record the rule in ticketing or infrastructure code, require peer review for broad ranges, and attach an expiration or review date.
A vendor allowlist can be much larger than one cloud rule. A 2026 analysis of SaaS vendor allowlists found 66 services publishing official ranges, 38 advising customers not to pin static IPs, and 27,513 published CIDR blocks across those vendors. The analysis also found that only 8 of 66 services offered a monitorable change signal, while 28 of 66 had no machine-readable endpoint and 43 of 66 published no IPv6 ranges. The available CIDR reference provides the underlying standards context for interpreting those ranges, but the operational lesson is broader. Vendor documentation, update signals, and IPv6 coverage must be treated as maintenance dependencies.
Setting IP Rules in Cloudflare, Nginx, and Apache
The CDN and reverse-proxy layer is where many production allowlist decisions take effect. An edge rule can reject a request before it reaches the origin, but the origin still needs protection if someone can connect to it directly.
Cloudflare-style IP access controls can allow, block, challenge, or apply other security actions to an IPv4 or IPv6 CIDR, ASN, or country. Scope the policy to the intended zone or account, and confirm whether the request arrives through the proxy. An edge allow rule is not sufficient if the origin's public address remains reachable outside that path.
Nginx ordering matters
Nginx supports allow and deny directives inside http, server, or location blocks:
allow 203.0.113.7;
deny all;
Place the narrow allow rule before the broad denial. Nginx evaluates the matching access directives in order, so a broad rule in the wrong location can produce an unexpected result. Use geo when the policy needs a variable-driven decision, but keep the source list centrally managed.
If a CDN or reverse proxy sits in front, configure trusted proxy addresses before using forwarded client headers for access decisions. Trusting arbitrary X-Forwarded-For values lets a requester manufacture the apparent source address.
Apache follows the same model
Apache's current authorization syntax uses directives such as:
Require ip 203.0.113.7
Require all denied
You can place these in a directory block or suitable access configuration. Older Order, Allow, and Deny examples still appear in legacy documentation, but newer deployments should use the authorization framework supported by the installed version.
Origin safeguard: Restrict direct origin traffic to the trusted proxy path, then enforce user authentication and application authorization after the network check.
Authenticated origin pulls or mutual TLS add a separate proof between the edge and origin. That matters because an IP address identifies network origin, not a user, device, or permission. Keep the CDN rule, origin firewall, reverse-proxy policy, and application logs aligned so a change at one layer doesn't bypass another.
Whitelisting for Mail Servers and SaaS Admin Panels
A mail relay can work on the day an allowlist rule is added, then stop accepting traffic after a provider changes its egress path. The same failure appears in SaaS administration panels when a remote employee changes networks or an integration starts leaving through a different gateway. Treat allowlisting as an operating process, not a one-time entry in a configuration screen.
Mail systems commonly define trusted relay sources through network lists, ACLs, or receive connectors. Pair those controls with SPF, DKIM, and DMARC. An IP rule identifies an expected network, but it cannot prove that the domain owner authorized a message or that a person has permission to send. Sender authentication and application authorization cover those separate questions.
Give every entry an owner
SaaS administration panels usually place network restrictions under security or network access settings. Enterprise plans may accept CIDR ranges alongside enforced SSO, although each service has its own interface and update process. Verify the published range rather than assuming it remains complete, current, or available across IPv4 and IPv6.
Record these details for every rule:
- Business purpose: State the workflow, such as finance administration, partner API access, or mail relay.
- Responsible owner: Assign a team, not a single employee who may leave.
- Source scope: Record the exact address or CIDR and the path that produces it.
- Review date: Schedule recurring review and set an expiration for temporary access.
- Recovery method: Document how an administrator regains access after an address changes.
Vendor ranges may be spread across documentation, support notices, and APIs. Some providers publish address lists without machine-readable endpoints or change notifications, which makes automated validation difficult. RFC 4632 explains CIDR notation, but it does not provide vendor governance or reliable change detection.
Dynamic cloud egress makes this harder. Remote staff move between carriers and ISPs, while a workload may exit through a gateway separate from its hosting environment. Review provider ranges on a defined cadence, test mail flow after updates, remove stale entries, and log each change before it becomes an access or compliance incident. For rotating proxy IPs, use a controlled, documented pool or another identity-based control rather than chasing individual addresses.
Whitelisting Mobile Proxy IPs the Right Way
Mobile proxies complicate static allowlists because a 4G or 5G carrier address often represents a shared egress point rather than one device. Carrier-Grade NAT, or CGNAT, places many subscribers behind public addresses, and RFC 6598 defines the shared 100.64.0.0/10 space used for this purpose. Technical guidance on mobile, residential, and datacenter proxy behavior notes that thousands of users may share one carrier IP at the same time.
That sharing makes mobile ranges harder to block without affecting legitimate users. Anti-bot systems often treat carrier IPs more leniently than hosting-provider addresses because blocking an entire carrier range creates collateral damage. This is one reason mobile connectivity suits legitimate ad verification, regional QA, social media workflows, and public market research where a natural mobile network path matters. A comparison of proxy categories explains this trade-off without making mobile IPs a replacement for authentication or platform compliance.
Build the rule around the session
Start with the source address the target service sees. Capture a sample from the proxy dashboard or session log, identify the carrier and ASN, then verify the relevant allocation through a regional Internet registry or WHOIS service. Don't automatically submit a large carrier block. The range must be broad enough to cover the provider's documented egress pool while remaining narrow enough for the target's security policy.
A practical workflow looks like this:
- Capture the observed egress: Record the public address presented by the active session.
- Identify the network: Check the ASN and carrier allocation rather than trusting a label in an application log.
- Choose the scope: Use the smallest documented CIDR that includes the approved pool. A single
/32is usually too fragile for a rotating mobile service. - Select session behavior: Use a sticky session when login state, cookies, or a long QA flow must remain on one address. Use rotation when the legitimate workflow requires separate network observations.
- Test and monitor: Confirm the target accepts the source, then watch denied-access logs and provider change notices.
Rotation and stickiness solve different problems. Proxy session guidance describes rotation as changing the exit address on a schedule or trigger, while sticky sessions preserve one address longer to reduce session churn. Neither mode makes an IP an identity. HTTP and SOCKS5 are transport methods, while geo-targeting selects a location or carrier path. ASN awareness tells you which network owns the apparent source, but it doesn't establish that the user is authorized.
Residential connectivity can fit research that needs household ISP characteristics, while datacenter addresses may be appropriate for controlled infrastructure testing where the network identity isn't part of the test. Mobile 4G or 5G is more suitable when you're validating carrier-dependent behavior, checking regional ad delivery, or testing a mobile-facing experience. Use automation only within applicable laws, platform rules, and permission boundaries.
Evoproxy provides mobile proxy access with personal and shared ports, configurable rotation, and source-IP approval for workflows that need controlled access to a changing mobile egress path. For implementation details, review the guide to mobile proxy IP management before choosing a CIDR scope or session mode.
Evoproxy offers 4G/LTE mobile proxy connectivity with personal or shared ports, configurable rotation, and approved-source IP access for legitimate social media management, ad verification, market research, and geo-dependent QA. Visit Evoproxy to review the available mobile sessions and choose a setup that matches your allowlist and session requirements.
