Skip to main content

IPsec tunnelers overview

An IPsec tunneler is a managed bridge that lets a remote site reach services on your network — and lets your services reach back into the remote site — over a standard IPsec tunnel, without installing any NetFoundry software at the remote site. The site's existing firewall, router, or VPN appliance peers with the bridge exactly like any other site-to-site VPN.

NetFoundry provisions and operates the bridge for you. It speaks two protocols at once: standard IPsec (IKEv2) toward the remote site, and OpenZiti toward your network, where a managed edge router carries traffic across the overlay. You configure only the IPsec side; the OpenZiti side is fully managed.

How it works​

Each tunneler is a dedicated bridge VM (deployed in us-east-1) running strongSwan for the IPsec side and an OpenZiti edge router for the overlay side. Forwarding between the two is fixed: IPsec traffic can only reach the edge router, and the edge router can only reach the IPsec side. The remote site connects over IPsec, and traffic crosses the OpenZiti overlay to and from your network.

Bidirectional traffic​

The key difference from an ingress-only connection is that traffic flows both ways:

  • Remote site → your services: Endpoints at the remote site reach services on your network as if they were local.
  • Your services → remote site: Services on your network reach hosts behind the remote site's IPsec device.

To reach OpenZiti services, the remote site resolves service hostnames through the bridge's DNS resolver to virtual IPs in the 100.64.0.0/10 intercept range and routes that range into the tunnel. The exact values are in the configuration NetFoundry generates for each tunneler — see Create an IPsec tunneler.

Security model​

  • Constrained entry point: Each tunneler gets its own security group that accepts inbound traffic only from the remote site's public IP, and only on the IPsec ports (UDP 500 and 4500).
  • Zero trust on the overlay: The IPsec entry point itself is a conventional VPN, so it isn't zero trust. But once traffic is on the OpenZiti network, the zero-trust model applies — the bridge is just another identity, and it can't reach anything until you authorize a service to it. With no service defined, it reaches nothing. This is the same model as zero-trust host access.
  • Pre-shared key: NetFoundry generates the pre-shared key (PSK) that authenticates the tunnel. Treat it like a password and deliver it to the remote site over a secure channel.

Status​

A tunneler's status reflects whether the IPsec connection has come up:

  • Green: The tunnel is up.
  • Orange: The tunnel was up but is currently offline.
  • Gray: The tunnel has never connected.

During rekey events the connection briefly re-establishes, which can leave short gaps in the metrics graphs.

Console reference​

IPsec Tunnelers table​

The IPsec Tunnelers section lists the tunnelers on your network.

ColumnDescription
NameThe user-defined name for the tunneler.
Customer IPThe public IPv4 address of the remote site's IPsec device.
RegionThe region where the bridge is deployed (for example, us-east-1).
StatusThe provisioning state of the bridge (for example, PROVISIONED).
ConfigDownloads the generated connection configuration for the remote site's IPsec device.

Tunneler detail tabs​

Open a tunneler to see three tabs:

  • Overview: NetFoundry hosting details (status, region, bridge IP, the tunneler's identity), tunnel info (customer public IP, customer peer CIDRs, last heartbeat), and the services and service policies associated with the tunneler.
  • IPsec: An IPsec snapshot (IKE Phase 1 state, IKEs connected, when IKE was established, bridge CPU and memory, last seen), the Child SAs (Phase 2), and bridge logs filterable by window and by kind (charon for the strongSwan IKE daemon, or ziti-edge-tunnel).
  • Metrics: Time-series graphs for throughput (rx/tx), liveness, and bridge CPU/memory. Red bands mark IKE_SA (Phase 1) outages and amber dashed lines mark CHILD_SA (Phase 2) rekey moments.

More info​