Create an IPsec tunneler and publish a service

This guide walks you through creating an IPsec tunneler (a managed bridge that connects a remote site to your network over IPsec) and then publishing a service across it. For the concepts behind the bridge, the security model, and the console tabs, see IPsec tunnelers overview.

Prerequisites

Before creating a tunneler, gather these from the remote site:

• Public IPv4 address: The address the remote site's IPsec device presents to the internet.
• Peer CIDRs: The internal subnets behind the remote device that your services need to reach (for example, 172.31.0.0/16).
• Crypto requirements (optional): Only if the site mandates specific IKE/ESP algorithms.

Part 1: Create the tunneler

1. From the console, make sure the network you want is selected in the dropdown at the top of the left-hand menu.

2. Click IPsec Tunnelers from the menu, then the + icon to create a new tunneler.

3. Fill in the tunneler fields:

   • Name: Enter a unique, recognizable name (for example, acme-dc-east).
   • Customer Public IP: Enter the remote site's public IPv4 address.
   • Customer Peer CIDRs: Enter the internal subnets behind the remote device. Add as many as needed.

   (Optional) Toggle Show more options to ON to configure the encryption proposals:

   • IKE Proposals (Phase 1): Leave the default set for a strong modern configuration, or narrow it to the site's required algorithms.
   • ESP Proposals: Same as above, for Phase 2.
   note

   You don't set a pre-shared key or configure the OpenZiti side. NetFoundry generates the key and provisions the bridge's edge router automatically.

4. Click Create.

   The tunneler moves through NEW → PROVISIONING → PROVISIONED. Provisioning launches the bridge VM, enrolls its edge router, and configures the IPsec Responder. Wait for PROVISIONED before continuing.

5. On the IPsec Tunnelers page, find your tunneler in the list and click Config at the end of its row to download the generated connection configuration.

   The configuration contains the bridge's public IP, the pre-shared key, the selected IKE/ESP proposals, the traffic selectors, and a ready-to-use example configuration. Deliver it to the remote site over a secure channel and have them bring up their IPsec device against it.

   warning

   The configuration contains the pre-shared key. Treat it like a password. Deliver it over a secure channel and never paste it into tickets, email, or chat.

Part 2: Publish a service across the tunneler

Once the tunneler is provisioned, it appears on your network as an identity (for example, acme-dc-east-tunneler). You can use that identity as a service endpoint, the same way you'd use a router or host. Publishing a service across the tunnel follows the same flow as Create a simple service. The only difference is the endpoint and target you choose.

To let your network reach a host at the remote site, create a simple service where:

• the hosting (bind) endpoint is the tunneler's identity, and
• the target is the host and port behind the remote device (an address within one of the peer CIDRs you configured).

To let the remote site reach a service on your network, publish the service as usual; the remote site reaches it through the bridge's DNS resolver and the 100.64.0.0/10 intercept range, as described in the generated configuration.

After saving, the service and its policies appear under Associated Services and Associated Service Policies on the tunneler's Overview tab.

Part 3: Configure DNS on your network

The tunnel carries traffic, but it doesn't tell your endpoints which destinations belong on the NetFoundry side. So that endpoints can reach OpenZiti services by name, configure the following on your network. Your downloaded configuration lists the exact addresses in its On your side: routes and DNS section. For the concepts behind this, see the IPsec tunnelers overview.

• Route the OpenZiti intercept range 100.64.0.0/10 into the tunnel. The bridge resolves every reachable service to a virtual IP in this range.
• Route the bridge's resolver address (UDP 53) into the tunnel. It's the bridge's own interface IP, listed in your configuration, and the /32 remote traffic selector already covers it.
• Point DNS at the bridge resolver so OpenZiti service hostnames resolve through it. Either add the resolver address as an upstream resolver on your internal DNS server, or set up conditional forwarding for the domains your services are published under.

Without DNS routed in and pointed at the bridge resolver, your endpoints can't resolve OpenZiti service names to their intercept addresses.

Part 4: Verify the connection

1. On the tunneler's IPsec tab, confirm the IKE state (Phase 1) is up and a Child SA (Phase 2) is present.

2. From a remote-site endpoint, resolve a published service hostname and connect to the returned address. The lookup should return an address inside 100.64.0.0/10.

   If the lookup fails, your endpoints aren't reaching the bridge resolver yet. Confirm resolution by querying the resolver directly with dig, using the bridge resolver address from the On your side: routes and DNS section of your downloaded configuration:

   dig @<bridge-resolver-ip> <service-hostname>

3. For the reverse direction, confirm a host on your network can reach the intended host behind the remote device.

If traffic won't flow, check the IPsec tab's bridge logs (charon for IKE, ziti-edge-tunnel for the overlay side) and confirm the remote site applied the routes and DNS from the generated configuration.

Default connection parameters

These are the typical defaults NetFoundry applies. They're a starting point only. The configuration generated for your tunneler always wins where it differs.

Parameter	Default
IKE version	IKEv2
Authentication	Pre-shared key
Local / remote ID	%any
IKE SA lifetime / rekey	86400s / 21600s
Child SA lifetime / rekey	3600s / 2700s
DPD delay	30s
OpenZiti service intercept range	100.64.0.0/10
Remote (your) traffic selector	The bridge's /32 and 100.64.0.0/10
Local (remote-site) selector	The peer CIDRs behind the remote device

note

NetFoundry defaults to modern AEAD ciphers (AES-GCM). If your IKE/ESP UI lists encryption and integrity separately, pick aes256gcm16 and leave the integrity algorithm blank. AEAD ciphers carry integrity internally and must not be paired with a separate HMAC. Set the remote traffic selector to the bridge's /32 and 100.64.0.0/10 so IKE establishes one Child SA covering both ranges without narrowing.