Learn OpenVPN - Site-to-Site & Point-to-Point VPN

#Introduction

So far we've always imagined one VPN server serving many remote clients. But there's a different need: connecting two offices so both networks can see each other, or drawing a straight line between two machines without a central server. This is the realm of site-to-site and point-to-point VPNs.

Episode 15 covers both. You will learn to connect two office networks with static routing and client-config-dir, meet server-bridge for sites that need layer 2, and build a simple 2-node point-to-point topology with --dev tun, --ifconfig, and --route.

After this episode, you can connect office networks at low cost, replacing expensive leased lines or connecting locations that have no direct link.

#Site-to-Site with Server-Client Mode

#The Two-Office Architecture

The most common site-to-site pattern: one office acts as the server, the other acts as a permanently connected client. The headquarters with a public IP becomes the meeting point, while the branch office behind NAT simply makes outbound connections.

The headquarters uses subnet 10.10.0.0/24 and the branch uses 10.20.0.0/24. Both must reach each other through the tunnel. This is achieved with the combination of iroute and push "route ..." already known from episode 9.

#Server Configuration at Headquarters

The server uses a standard server with the addition of client-config-dir:

port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
topology subnet
client-config-dir /etc/openvpn/server/ccd
push "route 10.10.0.0 255.255.255.0"

push "route 10.10.0.0 255.255.255.0" tells all clients that the headquarters subnet is reached via the tunnel. With this line, the branch knows how to reach headquarters.

#CCD File for the Branch Office

In the CCD directory, create a file named after the branch router certificate's CN:

iroute 10.20.0.0 255.255.255.0

iroute 10.20.0.0 255.255.255.0 tells the server that the 10.20.0.0/24 subnet is reached through that branch router. With iroute in one direction and push in the other, two-way traffic between headquarters and branch flows.

#The Router on the Branch Side

The branch side is simply an ordinary OpenVPN client run continuously on the router:

client
dev tun
proto udp
remote vpn.example.com 1194
ca ca.crt
cert branch.crt
key branch.key
remote-cert-tls server

The branch router must also enable IP forwarding so hosts in 10.20.0.0/24 can use the tunnel. This configuration connects the entire branch LAN without installing OpenVPN on every machine.

#Site-to-Site with server-bridge

#When Layer 2 Is Needed

When offices need to share broadcasts or layer 2 protocols — for example legacy applications or Windows authentication that depends on NetBIOS — routed mode isn't enough. This is where the server-bridge from episode 6 comes back into play.

Server-bridge joins both offices into one layer 2 network, as if they were connected to the same switch:

dev tap
server-bridge 192.168.1.10 255.255.255.0 192.168.1.100 192.168.1.200

server-bridge 192.168.1.10 255.255.255.0 192.168.1.100 192.168.1.200 makes 192.168.1.10 the bridge IP and pools addresses 192.168.1.100 through 200 for clients.

#The Bridge Trade-off

Layer 2 convenience is paid for in performance: broadcasts enter the tunnel and scale is limited. For the majority of modern site-to-site needs, routed mode with iroute is more than enough. Save bridging for cases that truly require layer 2.

#Point-to-Point VPN

#The Two-Node Topology Without a Server

To connect two machines directly without a central server, OpenVPN provides point-to-point mode. There's no server directive — only ifconfig on both sides determining the address pair:

dev tun
ifconfig 10.9.0.1 10.9.0.2
remote 198.51.100.5 1194

Node A uses 10.9.0.1, node B uses 10.9.0.2. ifconfig 10.9.0.1 10.9.0.2 means local address 10.9.0.1 and peer address 10.9.0.2.

#Node B Configuration

Node B is the mirror image — only one side needs remote, the other can passively wait:

dev tun
ifconfig 10.9.0.2 10.9.0.1

With ifconfig 10.9.0.2 10.9.0.1, node B takes the local address 10.9.0.2 and sees 10.9.0.1 as its peer. Once both sides run, ping 10.9.0.1 from node B will succeed.

#Adding Routes for Networks Behind

To reach networks behind each node, add route:

route 192.168.2.0 255.255.255.0

route 192.168.2.0 255.255.255.0 on node A tells it that the 192.168.2.0/24 network behind node B is reached through the tunnel. Don't forget both nodes must enable IP forwarding for the LANs behind them.

#Conclusion

Key takeaways:

• Routed site-to-site uses iroute and push "route ..." in both directions.
• client-config-dir maps each branch office's subnet.
• server-bridge is needed only for layer 2 requirements.
• Point-to-point mode uses ifconfig on both sides without a server.
• route connects networks behind point-to-point nodes.
• Enable IP forwarding on both sides so LANs are connected too.

In the next episode, episode 16, we will discuss network policy and split tunneling — choosing which routes enter the tunnel with push and redirect-gateway, the allow-pull-fqdn option for selective routing, and DNS configuration with dhcp-option and DNS leak prevention. After this episode, you can control exactly which traffic goes through the VPN.