Branch Office Networking with Pangolin

Most companies end up with the same network shape. There is a head office or a cloud VPC that holds the shared services, and a handful of branch offices, stores, or factories that need to reach them. Traffic mostly flows between a branch and the center. Branches rarely need to talk to each other directly.

Pangolin fits that shape because it is a hub and spoke system. Every client makes an outbound connection into sites, and access is granted per resource. Branch networking is the practice of joining offices into it, and backhaul is the name for carrying their traffic back to the central network.

This guide covers how to connect an office LAN to a cloud network, how to reach an office from the cloud, and how to link two offices through the center.

How Branch Traffic Flows

A mesh VPN such as Tailscale connects every node to every other node, and any device can be a peer of any other. That works well for laptops and small teams. For branch offices it means many routes to reason about, and a compromised branch has a network path to every other branch.

Pangolin does not build that mesh. A branch joins the central network and reaches only the resources you grant it.

Two pieces do the work:

• A site runs inside a network and makes it reachable. It connects outbound, so the network needs no open inbound ports.
• A subnet router is a Pangolin client that sits on a LAN and lets the other devices on it use the tunnel without installing anything themselves.

The direction of a connection follows from which of the two you put where. A site exposes a network. A subnet router consumes resources on behalf of a network. Put a site on the cloud VPC and a subnet router in the office, and office devices reach the cloud. Swap them, and the cloud reaches the office.

Subnet routing currently runs on Linux with the Pangolin CLI.

Reach a Cloud Network from a Branch Office

This is the most common setup. Staff in the office need a database, an internal app, or a build server that lives in a cloud VPC.

1. Put a site in the VPC. Deploy a site on a small instance inside the VPC. It needs outbound internet access and a route to the services you want to expose. See Install Sites.
2. Create a machine client for the office. In the dashboard, go to Clients > Machines and create one. A machine client is not tied to a person, so it keeps working when staff change. See Credentials.
3. Create a CIDR resource for the VPC. Create a CIDR resource for the VPC range, for example 10.20.0.0/16, and attach the site. If only a few services should be reachable, create host resources with IP destinations and use port restrictions to limit the ports. A subnet router needs IP or CIDR destinations, since the LAN sends traffic to the router by address. Give the machine client access to these resources.
4. Run the subnet router in the office. On a Linux machine in the office, install the CLI and start it with the subnet router flag:

curl -fsSL https://static.pangolin.net/get-cli.sh | bash

sudo pangolin up client \
--id {client_id} \
--secret {client_secret} \
--endpoint {endpoint_url} \
--subnet-router \
--attach

For a long-running deployment, run it as a service. The subnet router docs cover the firewall and Docker details.

5. Point the office at the router. Add a route on the office's default gateway that sends the VPC range to the machine running the subnet router. With the router at 192.168.18.10:

sudo ip route add 10.20.0.0/16 via 192.168.18.10

Depending on your router make and model you will need to adjust this command.

Every device on the LAN can now reach the VPC. If the subnet router is the office gateway itself, this step is not needed.

Redundancy at the Branch

A branch with one subnet router has a single point of failure. To fix that, run a second site or subnet router on another machine in the same network and attach both sites to the resource. Pangolin routes through the best available site and fails over when one goes offline, which takes a few seconds. See Multi-site Routing and High Availability. Every site attached to a resource must be able to reach the same destinations, so put both machines on the same LAN.

What to Expect

• Traffic from a device behind a subnet router is source NATed to the subnet router and to the site it is exiting. In the cloud it appears to come from the sites's address, not from the individual office device.
• Access control applies at the resource level. Permissions attach to the machine client, so everything on the office LAN shares them. If departments in one office need different access, run separate subnet routers for each.
• When a direct connection between the client and the site is possible, Pangolin sets one up through NAT traversal. Otherwise traffic relays through a point of presence.
• Subnet traffic shows up in the network connection logs, attributed to the subnet router because of the SNAT. Network connection logs are available on Enterprise Edition and Pangolin Cloud.

FAQ

Can branch offices reach each other directly?

Each branch connects to the central network and sees what it has been granted. There is no default path between branches.

Do I have to install Pangolin on every device in the office?

No. One Linux machine runs the subnet router, and the other devices reach the tunnel through a route on the office gateway.

Do I need to open inbound ports at a branch?

No. Sites and clients connect outbound.

Does this replace SD-WAN?

_For backhaul between offices and a cloud network, often yes. Pangolin adds per-resource access control on top of the connectivity.

Related Reading

• Subnet Router docs
• Pangolin vs. Tailscale
• Highly Available VPN

Learn More

Get started on Pangolin Cloud or self-host Pangolin. For a multi-site rollout, contact our team.