How to Cloak a Bastion Server

To realize the benefits of Twingate with no disruption to users’ workflow, it’s straightforward to cloak your bastion server from global internet access. For this example, let’s assume that:

  • Your bastion server resides on the private subnet with a private address of
  • The bastion’s public DNS address is which maps to a public IP address.
  • Users connect to the bastion via its public DNS address, eg. ssh

At the end of these steps, your configuration will reflect the following:

  • Your bastion firewall will only allow traffic originating from a private Twingate Connector that has no public IP address.
  • Users will authenticate themselves via the Twingate client application for network authorization to connect to your bastion.
  • (Optional, but recommended) You will transition from public to private DNS for your bastion host.

Deploy a Twingate Connector

  • Deploy a new Connector on the same private subnet as the bastion, which is in our example. We recommend deploying multiple Connectors within a Twingate Remote network for failover redundancy. (See: Create a new Remote network.) We’ll assume that the new Connector address is If you deploy multiple Connectors for redundancy, assume that the same steps below apply for all redundant Connectors.
  • Add an ingress allow firewall rule for the bastion host’s public IP address network interface for traffic from on port 22. (Note: in our example, users will continue to use the public DNS name to access the bastion, which will resolve to its public IP address. Make sure that routing and firewall rules take this into account. We will change this to private DNS in the last stage of transition.)

Next, we’ll add the bastion as a resource and authorize access to users.

Designate the Bastion as a Resource and Authorize Users

  • In the Twingate admin console, create a new Resource for the bastion. In our example, the Resource definition will be (See: Create a new Resource.) DNS resolution of the bastion name must be available from the Connector host.
  • Either create a new Group (eg. “Bastion Access”) or add the bastion Resource to an existing Group. (See: Create a new Group.) Add users that should have access to the bastion to this Group.

Congrats! With these steps completed, users will now be able to connect to your bastion server via Twingate. Next, we’ll block all public ingress traffic to the bastion server.

Block Global Ingress Traffic to the Bastion

Once you’ve verified that users can connect to your bastion server when connected to Twingate, you may disable all ingress traffic to your bastion except for the ingress allow rule that allows traffic from the Twingate Connector(s).

With this step completed, network connections to your bastion server can now only originate from users that you authorize via Twingate. Although your bastion server is now inaccessible from the public internet, the bastion is still being advertised via public DNS. We will modify this in the next step.

[Optional] Transition to Private DNS

Although this step is optional, it is highly recommended in order to eliminate any public trace of your bastion server.

  • Enable private DNS for the subnet. The Twingate Connector(s) and bastion server are all on the same subnet in our example so that private DNS will resolve for all hosts.
  • Create a private DNS record for that points to (the private network address of the bastion server).
  • Delete the public DNS record for
  • Release the public IP assignment for the bastion server as it will no longer be used.

With the above steps completed, your bastion is now fully cloaked! It has no public IP address or DNS records, and only authorized users can connect to the bastion server. Users will also experience no change to their workflow during these changes. They will continue to connect to and your private DNS will resolve to the bastion’s private IP address.

Last updated 2 months ago