Site-to-site networking is a foundational capability for any organization with more than a single network. The market has produced two broad approaches to it, and both ask customers to accept tradeoffs that are increasingly difficult to justify.
The first is the long-established stack of IPsec concentrators, GRE tunnels, and MPLS circuits. These technologies move packets reliably, but they were not designed to interoperate with identity-aware policy, and they do not compose with the access models organizations are adopting elsewhere in their environments.
The second is the centralized SD-WAN and Security Service Edge model, in which customer traffic is routed through the vendor-operated infrastructure. Operational simplicity comes at the cost of placing the vendor inside the data path, which is the same architectural trade-off we have written about previously in the context of centralized SaaS for network access. Additionally, in a world where AI agents are beginning to make up a large portion of network traffic, this model no longer makes sense.
Today we are releasing Bowtie Fabric as a better path forward.
What Fabric Does
Fabric turns the Bowtie Controllers already running in your environment into a site-to-site network. Each site (cloud VPC, datacenter, branch, or colo) hosts one or more Controllers, which form encrypted tunnels directly to each other, with traffic automatically sharded across controllers. Traffic between sites travels across infrastructure the customer controls and does not traverse systems operated by Bowtie. For customers already running Bowtie for private access, the infrastructure required to use Fabric is in place.
What Fabric Solves
Encryption and throughput are table stakes. The interesting work is in the problems site-to-site networking has historically been bad at.
- Source IP preservation. Many products perform source NAT by default, which destroys workload attribution in downstream logs and detections. Fabric preserves source addresses by default, so existing logging, monitoring, and enforcement continue to function unchanged.
- Overlapping address spaces. Mergers, multi-cloud expansion, and inherited environments produce conflicting RFC 1918 ranges. Fabric’s deconfliction engine routes overlapping ranges to the most specific match, allowing networks with conflicting addresses to participate in the same fabric without renumbering.
- Originating network as a policy signal. Bowtie’s identity-aware policy engine extends to inter-site flows, with the originating CIDR available as a first-class input. Traffic from development can reach staging but not production; traffic from an acquired network can be subject to additional inspection; workloads in an AI sandbox can reach only the destinations the customer permits.
- Dynamic routing. Fabric integrates with existing routing through BGP. Routes learned from a customer’s BGP peers propagate as site ranges automatically, so the fabric’s view of the network stays consistent with the network itself.
A Control Plane Without a Central Authority
Fabric inherits the same CRDT-based control plane the rest of Bowtie is built on. There is no centralized orchestrator and no coordinator that must remain reachable for configuration changes to take effect. Each Controller holds a complete, synchronized copy of state, and partitions resolve automatically when connectivity returns.
Most SD-WAN products rely on a central management plane operated by the vendor. The loss of that central authority is the loss of the ability to manage the network. Fabric is designed so that customers retain control of their networks under conditions in which a centralized system would not.
Scale and Compliance
Fabric scales horizontally within the customer’s own infrastructure. Each site can run multiple Controllers behind ECMP, and encrypted throughput scales with the hardware allocated to the workload. FIPS mode is optionally available for this traffic, and because the traffic is not routed through Bowtie, FedRAMP is not required. There is no per-tunnel licensing and no shared capacity to oversubscribe.
An Extension of Customer Agency
Bowtie’s core commitment is that customers should retain agency over the systems that handle their data and their traffic. Fabric applies that commitment to site-to-site networking. Customer traffic does not traverse infrastructure operated by Bowtie. Configuration is reconciled across the customer’s own Controllers without dependency on a central service. Policy is expressed through the same controls that govern the rest of the deployment. This is what we mean by Decentralized SaaS, applied to the layer of the network where the consequences of getting it wrong are the hardest to recover from.
If you’re interested in a demo or trying it out, please reach out to discuss a Fabric deployment in your environment.
