Skip to content

SealedTunnel Advanced Features

Local Domain Name Routing

TIP

Routes such as those described below can be set globally at the DNS level, making local changes to hosts files unnecessary and simplifying configuration across your organization.
Follow these instructions to map addresses to domain names at the local level only.

WARNING

Users may see a warning in their browsers that their connection may be insecure if the local domain name does not match the configured certificate.

Connecting to a loopback address in a browser (or through other GUI-based applications) to access a web portal (or service) through the SealedTunnel is not an intuitive or effective user experience.

To make SealedTunnel use easier, you can configure your hosts file to locally map addresses to domain names (URLs).

There are two ways to configure local domain name routing for client machines:

TIP

hosts files can easily be configured via group policies on Windows domains.

Loopback Address Variation

Loopback Address Variation is the simplest way to configure local domain name routing.

When configuring Entrypoints for your end users, map web portals to unique loopback addresses and specify port 443 as the port on all of them.

For example, if you have three web portals (i.e., an HR Portal, a Sales Portal, and a Code Repository Portal) all wrapped in the SealedTunnel, use a different address for each under the 127.*.*.* range with HTTPS port 443 so that browsers (by default) will execute an HTTPS request.

For example:

PortalMapping
HR127.0.0.1:443
Sales127.0.0.2:443
Code Repository127.1.0.1:443

Next, edit your hosts file and add the mappings for each portal to a domain name.

The hosts file can be found at the following locations:

console
C:\Windows\System32\drivers\etc\hosts
console
/etc/hosts
console
/private/etc/hosts

For example:

...
# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost
127.0.0.1 hr.example.com
127.0.0.2 sales.example.com
127.1.0.1 gitlab.example.com

From now on, end users can simply use these URLs in their browser and their connections will be secured through the SealedTunnel behind the scenes.

Local Port Listening

Local Port Listening is an alternative method for configuring local domain name routing.

If you need to use a static loopback address for all of your Entrypoints, then use this paradigm.

First, it helps to construct a table of ports, hostnames, and listen addresses. The listen address is any unique address in the 127.*.*.* range.

For example:

PortalMappingHostnameListen Address
HR127.0.0.1:45hr.example.com127.65.43.21:443
Sales127.0.0.1:886sales.example.com127.64.43.21:443
Code Repository127.0.0.1:1329gitlab.example.com127.63.43.21:443

Next, edit your hosts file, mapping the listen address to the host name (domain name). The hosts file can be found at the following locations:

console
C:\Windows\System32\drivers\etc\hosts
console
/etc/hosts
console
/private/etc/hosts

For example:

...
# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost
127.65.43.21 hr.example.com
127.64.43.21 sales.example.com
127.63.43.21 gitlab.example.com

Finally, route the traffic listened to on the listen address to the ST Mapping.

Below are examples for different operating systems.

TIP

macOS and Linux instructions are coming soon – stay tuned!

For the HR Portal:

batch
netsh interface portproxy add v4tov4 listenport=443 listenaddress=127.65.43.21 connectport=45 connectaddress=127.0.0.1

For the Sales Portal:

batch
netsh interface portproxy add v4tov4 listenport=443 listenaddress=127.64.43.21 connectport=886 connectaddress=127.0.0.1

For the Code Repository:

batch
netsh interface portproxy add v4tov4 listenport=443 listenaddress=127.63.43.21 connectport=1329 connectaddress=127.0.0.1

This will route the HTTPS traffic sent to the domain name (e.g., sales.example.com) to port 443 on the listen address which routes the traffic to SealedTunnel mapping (e.g., 127.0.0.1:45).

DNS A Record Routing

Rather than configuring host files individually for Entrypoint users, it's usually much easier to update your organization's DNS records to enable hassle-free use of the SealedTunnel.

Pointing DNS A Records to mapped loopback addresses for resource access, such as web services, will allow all users with appropriate SealedTunnel access to use those resources directly without requiring changes to local host files on each Entrypoint.

WARNING

All Entrypoints wishing to access resources via a DNS A Record must have the same loopback address and port configured on their individual Entrypoint configurations.

Simply add A Records to your DNS configuration that correspond to the loopback address configured on all Entrypoints that wish to leverage the domain name.

DNS A Records also work well for SealedTunnel Application Cards in the SSO Portal.

At Xiid, we use this ourselves to access our internal resources: here is a real example!

Units

Units are tags that can be used to organize your SealedTunnel Entrypoints and Exitpoints to easily locate them.

Click the purple pencil icon to edit the description of the Unit.

Click the lock icon to display only the Entrypoints and Exitpoints with the selected Unit assigned. For instance, if you had a Gitlab SealedTunnel Server, you could assign the server Exitpoint and all Entrypoints connecting to that server to a Gitlab Unit, making it easy to find them later. Use the red Unlock Unit button to remove the Unit filter.