Journalist
Ubiquiti edgerouter site to site vpn setup and optimization guide: configure site-to-site VPN on EdgeRouter for remote offices
Ubiquiti edgerouter site to site vpn is a method to securely connect two networks over the internet using EdgeRouter devices. In this guide, you’ll get a practical, step-by-step plan to design, configure, and maintain a robust site-to-site VPN setup on EdgeRouter gear. We’ll cover CLI and GUI methods, common pitfalls, performance tips, and troubleshooting. Plus, you’ll find handy checklists and real-world examples you can copy-paste into your own network. To help you stay secure beyond the tunnel, have a look at NordVPN’s current promo image below as an easy add-on layer of protection when you’re out on public networks.
Useful URLs and Resources un clickable text
– EdgeRouter official documentation – help.ubnt.com
– Ubiquiti Community forums – community.ui.com
– IPsec basics – en.wikipedia.org/wiki/IPsec
– Site-to-site VPN concepts – en.wikipedia.org/wiki/VPN
– EdgeRouter hardware overview – ubnt.com/products/edgerouter
– Basic firewall concepts for VPNs – kb.ubnt.com
Introduction: What you’ll learn
– A clear, end-to-end walkthrough for setting up a site-to-site VPN between two EdgeRouter devices
– How to choose and align topologies, subnets, and firewall rules
– Two hands-on setup paths: CLI EdgeRouter OS and GUI EdgeOS web UI
– Troubleshooting tips for the most common VPN hiccups
– Extra tips to optimize performance, reliability, and security
– A practical FAQ to cover questions you’re likely to have
Body
What is a site-to-site VPN on EdgeRouter and when to use it
A site-to-site VPN on EdgeRouter connects two or more separate networks as if they were on the same private network, using the public internet as the carrier. This is ideal for linking a head office to a branch, a data center to an office, or multiple remote sites that need secure, private communication. The two ends of the tunnel typically reside on EdgeRouter devices, each with its own public IP and its own internal network ranges. Once the tunnel is up and running, traffic destined for the remote subnet travels through the VPN tunnel instead of the public internet.
Key advantages:
– Encrypted, private traffic between sites
– Centralized connectivity for remote workers or devices at branch offices
– Scalable with more sites by adding additional VPN peers
– Works over dynamic IPs with some extra configuration DPD, keepalives, or dynamic DNS
Common pitfalls to avoid:
– Mismatched Phase 1/Phase 2 proposals between peers
– Incorrect local/remote subnet definitions or overlapping networks
– Firewall rules that block VPN traffic or the subnets behind each EdgeRouter
– NATing that interferes with internal subnets across the tunnel
Prerequisites and design decisions
Before you touch the console, lock in a few basics:
– Two EdgeRouter devices or more for multiple sites with public IPs or stable dynamic IPs
– A known, non-overlapping pair of subnets for each site for example, 192.168.10.0/24 at Site A and 192.168.20.0/24 at Site B
– A strong pre-shared key PSK or, if you’re comfortable, certificates for an IKEv2 deployment
– Basic firewall rules allowing VPN-related traffic UDP 500/IKE, UDP 4500 NAT-T, and ESP protocol if you’re using IPsec transport mode
– A plan for routing: static routes or dynamic routing like BGP if you’re running more complex networks
Topology options you might choose:
– Full-mesh: every site connected to every other site
– Hub-and-spoke: all remote sites connect to a central hub site
– Redundant VPN pairs: two tunnels per link for high availability
IP addressing sanity check:
– Ensure subnets do not collide with each other or with VPN IPsec internal addressing
– Prefer private RFC1918 space that won’t conflict with VPN devices
– Plan for future growth to avoid renumbering later
Performance considerations:
– EdgeRouter models vary in CPU and RAM. heavier encryption reduces throughput. If you’re seeing dropped tunnels or high CPU load, you may need a higher-end model or tune for AES-NI support if available.
– Enable hardware offloading where supported check your model to improve throughput.
– If you’re using dynamic IPs, plan for a robust keepalive/DPD strategy and consider a dynamic DNS option to keep peers aligned.
Quick reference: what you’ll configure overview
– Phase 1 IKE settings: encryption, hash, DH group, lifetime
– Phase 2 IPsec settings: encryption, hash, lifetime
– Peer definition: remote peer IP, authentication method PSK or cert
– Local and remote subnets: what networks are on each side of the tunnel
– NAT exemption: route traffic between the two subnets without double NAT
– Firewall rules: permit VPN traffic, then permit inter-site traffic
– Monitoring: verify with show vpn ipsec sa, ping tests, traceroute, and log checks
If you’re more comfortable with a guided UI, EdgeOS provides a friendly interface for adding a Site-to-Site VPN. If you prefer the command line, EdgeRouter’s CLI is straightforward once you’ve mapped out your subnets and peer IPs.
Step-by-step setup: CLI method EdgeRouter OS
Note: Replace placeholders with your actual values. The example below shows a typical IPsec site-to-site VPN between Site A 192.168.10.0/24 and Site B 192.168.20.0/24. Public IPs are hypothetical: 203.0.113.1 Site A and 198.51.100.2 Site B. Pre-shared key is your secret string.
1 Enter configuration mode
configure
2 Define IKE Phase 1 group
set vpn ipsec ike-count 1
set vpn ipsec ike-group IKE-1 proposal 1 encryption aes256
set vpn ipsec ike-group IKE-1 proposal 1 hash sha256
set vpn ipsec ike-group IKE-1 proposal 1 dh-group 14
set vpn ipsec ike-group IKE-1 lifetime 3600
3 Define IPsec Phase 2 group
set vpn ipsec esp-group ESP-1 proposal 1 encryption aes256
set vpn ipsec esp-group ESP-1 proposal 1 hash sha256
set vpn ipsec esp-group ESP-1 lifetime 3600
4 Configure the site-to-site peer
set vpn ipsec site-to-site peer 203.0.113.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 203.0.113.1 authentication pre-shared-secret ‘YOURSECRETKEY’
set vpn ipsec site-to-site peer 203.0.113.1 ike-group IKE-1
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 local-subnet 192.168.10.0/24
set vpn ipsec site-to-site peer 203.0.113.1 tunnel 1 remote-subnet 192.168.20.0/24
set vpn ipsec site-to-site peer 203.0.113.1 local-address 203.0.113.1
set vpn ipsec site-to-site peer 203.0.113.1 remote-address 198.51.100.2
5 Configure NAT exemption do not NAT traffic between subnets
set firewall group address-group VPN_SUBNETS include 192.168.10.0/24
set firewall group address-group VPN_SUBNETS include 192.168.20.0/24
set firewall name WAN_LOCAL default-action drop
set vpn ipsec sa-policy 1 tunnel 1
6 Commit and save
commit
save
7 Verify
show vpn ipsec sa
ping 192.168.20.1 source 192.168.10.10
If anything looks off, check Phase 1 and Phase 2 parameters, verify IPs, and ensure both sides have matching lifetimes and encryption settings.
Step-by-step setup: GUI method EdgeOS Web UI
1 Log into EdgeRouter’s web UI at http://
2 Create a new Site-to-Site VPN peer
– Remote IP: the public IP of the peer site
– Authentication: Pre-Shared Key PSK
– IKE Phase 1 settings: encryption AES256, hash SHA256, DH group 14
– Phase 2 settings: encryption AES256, hash SHA256
3 Define local and remote subnets for the tunnel
– Local subnet: your site’s internal network e.g., 192.168.10.0/24
– Remote subnet: the other site’s internal network e.g., 192.168.20.0/24
4 Enable NAT exemption
– Create a firewall rule to allow traffic between the two subnets and disable NAT between them
– Example: Rule allowing IPsec traffic between VPN_SUBNETS and VPN_SUBNETS across the VPN
5 Add firewall rules to permit VPN traffic
– Allow ESP, UDP 500 IKE, UDP 4500 NAT-T
6 Apply and test
– Use the Web UI to test the tunnel status. you should see the tunnel marked as “up”
– Test connectivity by pinging a host on the remote subnet
7 Verify and monitor
– Check Status -> IPsec or VPN status page in EdgeOS
– Review logs if the tunnel doesn’t come up
Firewall rules and routing: getting the traffic flowing
A VPN tunnel won’t help if the traffic never gets through your routers. Here’s a sane, practical approach:
– Create a VPN-specific firewall zone or group e.g., VPN_SUBNETS that includes the remote subnet
– Permit inter-subnet traffic: allow traffic from 192.168.10.0/24 to 192.168.20.0/24 and vice versa
– Exempt VPN traffic from NAT: ensure NAT is not applied to traffic between the two VPN subnets
– Allow essential management traffic to your EdgeRouter from your admin network
– If you’re using DHCP clients on either side, reserve static routes for the VPN-connected devices that need to reach the remote site
Routing decisions:
– Static routes: Add a route on Site A pointing to the remote subnet via the VPN tunnel interface
– Dynamic routing: If you have multiple sites, consider dynamic routing e.g., OSPF or BGP to exchange routes automatically
– For small shops, static routes are simpler and less error-prone
Testing after configuration:
– Ping from a device on Site A to a device on Site B e.g., 192.168.10.x to 192.168.20.y
– Use traceroute/tracert to confirm traffic is taking the VPN path
– Check VPN status and SA Security Association entries in EdgeRouter
– Review firewall logs for denied traffic that should be allowed
Troubleshooting common issues
– Phase 1/Phase 2 mismatch: Double-check encryption, hash, and DH group on both sides. Even a small mismatch will prevent the tunnel from forming.
– Overlapping subnets: Ensure the local and remote subnets don’t overlap with each other or any other connected networks.
– NAT issues: If both sites are behind NAT, ensure NAT-T UDP 4500 is enabled and ESP is permitted. Some older devices need extra configuration to support NAT-T properly.
– Firewall blocks: A firewall that blocks IKE UDP 500/4500 or IPsec ESP will stop the tunnel from establishing. Confirm both ends permit this traffic.
– Dynamic IPs: If a site uses a dynamic IP, ensure a reliable dynamic DNS setup and keepalive/DPD configured. Without this, the tunnel can drop when the peer’s IP changes.
– ACL and routing errors: If you can connect but traffic isn’t reaching the remote network, re-check ACLs and static routes. Ensure the VPN interface is the next hop for the remote network.
– Logs and diagnostics: Look at /var/log/messages Linux-based or the EdgeOS VPN status page. Logs can reveal exact misconfigurations or negotiation problems.
Performance tips:
– Use strong algorithms that your hardware can handle efficiently AES-256, SHA-256 and monitor CPU load
– If your EdgeRouter model supports hardware offloading for VPN, enable it
– Keep MTU in mind. sometimes fragmentation can break VPN connectivity. Adjust MTU/MSS if you see odd packet drops
– For remote sites with unstable connections, enable aggressive dead peer detection DPD and reduce negotiation timeouts to recover quickly
Security considerations:
– Use a robust pre-shared key and rotate it periodically
– If possible, use certificate-based authentication IKEv2 with certs for a stronger security posture
– Limit VPN access by configuring firewall rules to only allow necessary subnets
– Document the VPN topology and keep the configuration under versioned control if possible
Advanced topics worth exploring optional
– Redundancy: configure a second tunnel to the same peer or multiple peers for high availability
– Load balancing: if you’re running multiple VPNs, distribute traffic across tunnels
– Dynamic routing integration: run OSPF or BGP over VPN to automatically learn routes to remote networks
– Remote access vs site-to-site: distinguish between employees connecting to a single site and devices at a site needing access to another site
NordVPN promo and security layering
The NordVPN promo in the introduction is a practical reminder that you can add layers of security beyond a site-to-site VPN, especially for devices or users that roam beyond the corporate network. A VPN client on endpoints, a reliable password manager, and routine security audits help keep your network safer when mobility is a factor.
FAQ Section
Frequently Asked Questions
# What is the difference between IPsec and OpenVPN for EdgeRouter site-to-site VPN?
IPsec is the native, standardized VPN solution typically used for site-to-site connections, offering strong encryption and efficient performance on many devices. OpenVPN is another option, often used for client-to-site setups rather than site-to-site on EdgeRouter. IPsec generally provides better performance and tighter integration with EdgeRouter’s firewall and routing capabilities.
# Can I use dynamic IPs at both sites for site-to-site VPN?
Yes, with appropriate configuration. You’ll need to ensure that dynamic IP handling is enabled DPD/keepalive and consider using dynamic DNS so peers can resolve each other’s changing IPs. Some setups benefit from a static IP at one or both ends for reliability.
# How do I test a newly created VPN tunnel?
After you save and apply the configuration, verify tunnel status in EdgeRouter’s VPN status page or via CLI with show vpn ipsec sa. Then perform a simple ping test from a host in Site A to a host in Site B and vice versa. Traceroute can help identify routing issues if traffic isn’t taking the VPN path.
# What if the tunnel shows as down but I configured everything correctly?
Common culprits are mismatched Phase 1/Phase 2 settings, mismatched subnets, or firewall blocks. Double-check the local/remote subnets, ensure the PSK matches, and review firewall rules allowing IKE UDP 500, 4500 and ESP. Logs will point to the exact problem.
# How do I ensure traffic between sites doesn’t get NATed?
Set NAT exemption rules that exclude traffic between the two VPN subnets from being NATed. This ensures traffic between 192.168.10.0/24 and 192.168.20.0/24 passes through unmodified.
# Can I run multiple VPN tunnels with EdgeRouter?
Yes. You can have multiple IPsec site-to-site peers, and you can use multiple tunnels per site for redundancy. Each tunnel will have its own peer configuration, local/remote subnets, and firewall rules.
# How do I monitor VPN health and performance?
Use the EdgeRouter’s VPN status pages and the CLI to inspect SA entries. Regularly check pings to remote hosts, monitor CPU usage during encryption, and review logs for dropped connections or negotiation failures. Consider alerting if a tunnel remains down for a defined period.
# Should I use IKEv1 or IKEv2 for EdgeRouter VPNs?
IKEv2 is generally preferred for new deployments due to its better performance, resilience to network changes, and simpler configuration for many scenarios. If you’re upgrading an older site, you might still encounter IKEv1 in legacy setups.
# How can I add a second site for a hub-and-spoke topology?
Add a second VPN peer on the hub site and define a tunnel for each spoke with its own local/remote subnets. Ensure firewall rules and routes reflect the new topology, and consider a dynamic routing protocol to simplify route management across multiple sites.
# What if I need to support remote devices in addition to site-to-site VPN?
Use a separate VPN often a VPN client/server setup or a different VPN type like OpenVPN for remote users, while keeping your site-to-site VPN dedicated to inter-site traffic. Maintain strict separation of user VPNs and site-to-site tunnels for better security and management.
Resources for deeper dives
- EdgeRouter site-to-site VPN guide EdgeOS CLI and GUI references
- IPsec configuration best practices and troubleshooting
- Ubiquiti community discussions on EdgeRouter VPN deployments
- General VPN concepts, including IPsec and NAT-T behavior
- Network design planning templates for small offices and remote sites
If you’re building out a multi-site network, start with a hub-and-spoke layout and add more spokes as needed. Also, remember to document every change you make. a well-documented VPN topology saves you hours of debugging later.
Now it’s your turn: set up the EdgeRouter site-to-site VPN between your sites, verify the tunnel, and optimize the rules and routes to keep traffic flowing smoothly. If you want to explore more security options, consider the NordVPN promo in the introduction, and keep your network coverage strong with best practices and ongoing monitoring.