The Challenges of Access Whitelisting

When it’s necessary to limit authorized access to resources on the public internet—a pre-release staging website, for example, or a SaaS application that allows source whitelisting—it can be difficult to apply access restrictions. Authorization typically relies on either source IP whitelisting or setting custom request headers. Legacy IP whitelisting configurations can be especially difficult to maintain for a number of reasons:

• Users have to provide their external IP address, which may not be static. Not only do users have to be provided with instructions on how to determine their external IP address, but any external IP address may not be static, particularly when working from home.
• Users cannot work from a new location without an admin updating their IP. Users connecting from a new location need to request an update to the IP whitelist. This makes working remotely from a new location challenging and time-consuming.
• Shared external IPs provide access that’s too broad. External IPs are often too broad, for example, representing an entire office or shared working space. This opens up access to the public resource to an unnecessarily large set of devices.
• Admins may have to maintain a large list of IPs. With more than a few users that require access, maintaining a large set of whitelisted IPs can be challenging.
• It’s difficult to know when to remove addresses from the authorized list. Without maintaining some kind of external record of IPs or monitoring inbound logs, it can be very difficult to know when a whitelisted IP should be removed.

Authorize Traffic with Twingate

You can replace any IP whitelisting scheme with Twingate by following two steps.

1. Whitelist traffic from one or more Twingate Connectors

• Define a Remote Network and assign the Connectors in the Remote Network one or more static external IP addresses. This will depend on where your Connectors are deployed but is most likely the public IP address of the NAT gateway for your private network.
• Whitelist these IP addresses with your public resource or SaaS application.

2. Restrict access to authorized users in the Twingate Admin Console

• Create a Resource in Twingate for your public Resource and associate it with the Remote Network you created in the first step. This will ensure that authorized Twingate users accessing the Resource will have their traffic routed through the whitelisted Connector hosts.
• Provide authorized users access to the Resource in Twingate by creating and associating them with a Group.

With this configuration complete, the only users that will be able to access the public resource will be those both connected to Twingate and authorized to access the resource. This provides visibility into who has been provided access to the resource—with users authenticated by your configured Identity Provider—and also allows users to access the resource from any network and location.