As an overlay network, Bowtie utilizes one or more network ranges for its clients that aren’t attached to any single physical network location. By default, Bowtie egresses traffic from the nearest controller using that controller’s local underlay address — the fastest configuration to deploy and the easiest to reason about.
Most ZTNA solutions operate this way by default. But this default has tradeoffs. The upstream network sees the controller as the source of all client traffic, creating a blind spot for your existing monitoring, IDS, and flow analysis tools. Operators can correlate sessions through Bowtie’s own traffic logs, but that’s an additional step outside existing patterns. During controller failover, client traffic is redirected to a new origin address, causing connections to renegotiate and workflows to be interrupted.
Routing the Overlay with BGP
Each Bowtie controller can exchange routing information with routers in its deployed network using BGP. When enabled, controllers advertise client IP address pools directly to your network infrastructure, so traffic reaches its destination with the actual client address intact. These addresses are cryptographically bound to the client device, providing high assurance of their accuracy.
This isn’t a novel concept; it’s how routed networks are supposed to work. We’re applying BGP’s native reachability advertisement to the overlay so that your existing infrastructure — firewalls, load balancers, SIEMs, rate limiters — can operate on real client addresses without additional integration.
Resilient Failover
With BGP configured, the overlay address space is sharded across controllers at a given site, with each shard independently advertised to the parent network. If a controller goes down, Bowtie redistributes those shards to the remaining controllers, which advertise the reassigned routes. Because source and destination addresses remain stable, client traffic resumes without reconnection or significant disruption. No session tables to replicate, no sticky sessions to renegotiate. The routing layer handles reachability, which is exactly what it was built to do.
From Addresses to Names
End-to-end client address visibility enables a second capability: Bowtie serves reverse DNS records for client IPs to the upstream network. Anywhere you’d otherwise see a raw overlay address, you can instead resolve it to the client’s device name. During an incident, seeing “jdoe-macbook” instead of “10.99.4.137” compresses mean time to attribution from minutes to seconds. For compliance teams reviewing access logs, the same visibility eliminates a manual lookup step.
Built on a Partition-Tolerant Foundation
This design builds on Bowtie’s CRDT-backed control plane. Every controller maintains a fully independent, synchronized copy of policy and routing state with no central coordinator. BGP peering extends this principle to the network layer. Route information propagates the way policy changes do, with convergence handled by the protocol itself. Controllers operate independently during network partitions and reconverge correctly when connectivity returns. Failures stay isolated rather than cascading.
BGP also means fewer address translations per controller, improving connection throughput and resource utilization.
Enabling BGP on Bowtie
BGP integration is available to Bowtie customers as a configurable option. For organizations with existing routing infrastructure, enabling it means your network sees Bowtie clients as proper routed endpoints rather than traffic behind a NAT boundary. If you’re evaluating your access architecture, it’s worth asking whether your tooling should require workarounds for visibility that the network could provide natively.
