Exit Nodes
An Exit Node is the default target for all traffic that is not destined for an Asset, Virtual Asset, Subnet, or a local network of the client. Clients using it reach the internet from the Exit Node's connection rather than their own.
An Exit Node requires a Linux or Windows asset running the XTNA-agent as the gateway asset to route traffic.

Access to services located on an Exit Node is granted based on policies.
You configure an Exit Node much like a Subnet, with one
difference: its range is every destination rather than one network, so the
Network / Mask field is fixed at 0.0.0.0/0 and cannot be edited.
Two Subnet options are not available as a result:
- Hosts map an IP to a DNS name for a known device on the network. An Exit Node's range is the whole internet, so there are no such devices to name.
- No NAT turns off address translation for a Subnet, which works only when the router behind the gateway asset sends replies back to the tunnel network. Arbitrary internet hosts cannot do that, so traffic leaving through an Exit Node is always translated to the gateway asset's own address.
An Exit Node also carries IPv6. Where the gateway asset has IPv6 and the client has an
IPv6 default route of its own, the Exit Node becomes the default for ::/0 as
well, and the client's IPv6 traffic egresses from it exactly as its IPv4 traffic
does. Clients with no IPv6 are unaffected — only their IPv4 default route is
redirected.
Configuration
General tab
- Enabled/Disabled — toggle to enable or disable the exit node
- Gateway Asset — the Linux or Windows asset that routes the traffic
- Name — a descriptive name for the exit node
- Description — optional description
- Network / Mask — always
0.0.0.0/0, shown for reference only. IPv6 is covered as well where both ends have it; there is nothing to configure - Tags — optional tags for organizing and filtering
Access tab
- Policy Assignments — assign policies that grant access to this exit node
Exceptions tab
Destinations listed here are not routed through the exit node. Traffic to them leaves through the client's own internet connection instead, while all other traffic keeps using the exit node. See Exceptions for what this is for.
- Enable exceptions — toggle the whole list on or off. Switching it off keeps the entries, so you can turn them back on without entering them again
- Presets — ready-made ranges for common vendors, kept up to date automatically
- Custom networks — additional networks to except, in CIDR notation
(e.g.
203.0.113.0/24or2001:db8:1::/48)
Presets
| Preset | Covers |
|---|---|
| Microsoft 365 (all) | Everything in the three entries below |
| Exchange Online | Outlook and Exchange Online: mail, calendar and contacts |
| SharePoint & OneDrive | SharePoint and OneDrive, including file sync |
| Microsoft Teams | Teams calls and meetings: audio, video and screen sharing |
| Google Meet | Google Meet calls and meetings |
| Zoom | Zoom meetings: audio, video and screen sharing |
| Cisco Webex | Webex meetings: audio, video and screen sharing |
Microsoft 365 (all) is the same as selecting the three Microsoft entries individually; selecting it alongside any of them is harmless.
The Microsoft ranges are refreshed automatically, so those presets keep covering the right addresses without you editing anything. The Google, Zoom and Webex ranges are maintained with each release instead, because those vendors do not publish them in a form that can be collected automatically.
One thing worth knowing: Cisco Webex covers the media traffic only, which is both the latency-sensitive part and the only part Cisco publishes stable addresses for.
Custom networks
A custom network may not be broader than /8 (IPv4) or /16 (IPv6). An
over-broad exception would send far more traffic direct than intended — for
example excepting a cloud provider's entire range would quietly take your own
cloud-hosted traffic off the exit node as well.
Both IPv4 and IPv6 are supported, and on a dual-stack network you need both. Because the Exit Node takes over the IPv6 default route too, excepting only a service's IPv4 range leaves its IPv6 traffic still going through the Exit Node — easy to miss, because the connection keeps working and only the routing is wrong. The vendor presets already cover both families.
Presets are only offered on an Exit Node. A vendor's servers are spread across the internet, so their ranges cannot sit inside any single Subnet; a Subnet can still have custom network exceptions of its own.