Every device running the EagleSafe ZTB agent joins a single private encrypted overlay network. However, not every device can run the agent — printers, IoT sensors, databases, and appliances typically cannot. A Network solves this: one or more devices inside a private network act as routing peers, making entire subnets, individual hosts, or internal domains reachable through the overlay network, with nothing accessible until an access policy explicitly allows it.
The typical use case is VPN-to-Site: your laptop reaches into a remote office or cloud network and communicates with machines that have no agent installed.
The four building blocks
Network
A Network is a configuration container that maps one environment (an office LAN, a cloud VPC, a data center segment) into a logical set of routing peers and resources. Create one Network per environment.
Resource
A resource is a destination inside the private network. It can be:
- A single host:
10.10.0.5/32 - An IP range:
10.10.0.0/16 - A domain:
grafana.office.internal - A wildcard domain:
*.office.internal
For Zero Trust least privilege, prefer single-host /32 resources over broad ranges — a policy then grants access to exactly one host instead of an entire subnet.
Resources can be organized into resource groups. When an access policy's destination is a group, it applies to every resource in that group.
Note on wildcard domains: *.office.internal matches subdomains only, not the base domain itself. To allow office.internal too, add it as a separate resource and assign it to the same group.
Access policy
An access policy is the rule that makes a resource reachable. It grants access from a source group to a destination (a resource, resource group, or peer), for the specified protocols and ports. Nothing is reachable until a policy allows it — this is Zero Trust by default.
Unlike peers, resources are not automatically included in the built-in All group. A resource with no policy is reachable by no one.
Routing peer
A routing peer is a device running the ZTB agent inside the private network. It forwards traffic from the overlay network to devices that do not run the agent. Any supported OS can act as a routing peer (Linux, Windows, macOS); what matters is its network position, not its OS.
A routing peer grants access to resources behind it, not to itself. To reach a service running directly on the routing peer (e.g. SSH, a dashboard), create a separate peer-to-peer access policy with the routing peer's group as the destination.
For headless routing peers (servers, VMs), register them using a setup key — this avoids interactive login and keeps the peer connected without periodic re-authentication.
How traffic flows
- The client encrypts the packet and sends it through the tunnel to the routing peer.
- The routing peer forwards it onto the local network toward the resource.
- By default, the routing peer masquerades the traffic (rewrites the source to its own LAN IP), so the destination network requires no awareness of ZTB.
- Return traffic follows the reverse path automatically — no additional policy is needed for replies.
Walkthrough: access two internal apps
A remote user in the IT group needs to reach two internal apps: a wiki at 10.10.0.5 and a dashboard at grafana.office.internal. One machine inside the office acts as the routing peer.
- Install the routing peer. On a host inside the office network, install the ZTB agent and register it with a setup key.
- Create the Network. Go to Networks and add a Network named Office.
- Add the wiki as a resource. Add a resource named Internal Wiki with address
10.10.0.5/32, assigned to an Internal Apps resource group. - Create the access policy. Source:
ITgroup. Destination:Internal Appsgroup. Protocol: TCP, port 443. - Add the dashboard as a domain resource. Add
grafana.office.internaland assign it to the same Internal Apps group — it will be covered by the policy already created. - Add the routing peer. Assign the office host to the Office Network as its routing peer.
- Verify. On the user's device, check that the Network is active and that both apps are reachable.
The IT group can now reach exactly the wiki and the dashboard, and nothing else. All other groups remain denied by default.
Production checklist
- High availability. Add multiple routing peers to the same Network. Peers with different metrics act as primary and failover; peers with equal metrics load-balance by latency. Keep routing peers in different failure domains.
- Monitoring. Enable the Routing Peer Disconnected event in Settings → Notifications to receive alerts by email or webhook when a routing peer goes offline.
- Masquerade. Enabled by default. Disable only when source-IP visibility is required, and only on Linux routing peers. Disabling it also disables high availability and requires a return route on the destination network.
- Internal DNS. Domain resources are resolved by the routing peer. If the routing peer cannot already resolve the internal name, configure a nameserver distribution to its group.
- Access to the routing peer itself. If users need to reach services running on the routing peer host (SSH, monitoring), create a separate peer-to-peer access policy with the routing peer's group as destination.
