Journalist
Ubiquiti edge router site to site vpn guide for establishing a reliable site-to-site IPSec tunnel between remote networks using EdgeRouter
Yes, you can set up a Ubiquiti EdgeRouter for a site-to-site VPN. In this guide, you’ll get a practical, field-tested approach to planning, configuring, and validating a secure IPSec tunnel between two EdgeRouter devices. We’ll walk through topology, protocol choices, concrete CLI steps, common pitfalls, troubleshooting tips, and best practices so you can get a stable, resilient connection between two offices or data centers. Plus, you’ll find a few real-world tips to keep things running smoothly, from firewall rules to monitoring.
NordVPN deal note: If you’re testing VPN concepts or need extra privacy for remote workers, consider this limited-time offer:
Useful resources un clickable in-text list:
– EdgeRouter official documentation and help articles
– Ubiquiti Community forums for EdgeRouter
– IPSec VPN fundamentals on Wikipedia or vendor white papers
– General networking best practices and VPN topology guides
What this guide covers
– Why you’d use EdgeRouter for site-to-site VPN and what to expect
– Prerequisites: hardware, firmware, IP addresses, and subnet planning
– Protocol choices, cryptography, and tunnel settings
– Step-by-step two-site setup example with concrete CLI commands
– Verification, testing, and common troubleshooting steps
– Security hardening, monitoring, and maintenance tips
– A comprehensive FAQ to answer your most common questions
Why use Ubiquiti EdgeRouter for a site-to-site VPN?
EdgeRouter devices with EdgeOS are a solid choice when you need a budget-friendly, feature-rich platform for IPsec site-to-site VPNs. They offer:
– Flexible site-to-site VPN configuration with strong cryptography AES, SHA, PFS
– Clear CLI for repeatable, auditable deployments
– Ability to blend Internet access with VPN tunnels on a single device
– Good throughput on mid-range devices for typical SMB workloads
– Integrations with firewall rules and NAT exemptions that keep VPN traffic clean
A well-planned site-to-site VPN with EdgeRouter can replace or augment more expensive hardware, while giving you direct control over routing, tunnel failover, and monitoring. Real-world numbers vary by model and firmware, but you can typically expect reliable throughput and stable tunnels when you tune the settings and test end-to-end connectivity.
Prerequisites
Before you start configuring, gather and verify these items:
– Two EdgeRouter devices for example, EdgeRouter X, EdgeRouter 4, EdgeRouter 6P, or higher-end models running a supported EdgeOS version
– Publicly reachable IP addresses for both sites static is ideal. dynamic can work with Dynamic DNS, but you’ll need to account for it in the configuration
– Local networks to be tunneled Site A: e.g., 192.168.1.0/24. Site B: 192.168.2.0/24
– Subnets you want to route across the tunnel—these must not overlap
– A pre-shared key PSK or a certificate-based setup if you prefer, but PSK is the simplest for quick setup
– Necessary firewall allowances on each EdgeRouter IPsec, ESP, IKE, and NAT-T
– Basic networking knowledge: how to access the EdgeRouter GUI or SSH into the device
Optional but useful:
– A secondary monitoring host to ping across the tunnel for ongoing health checks
– A plan for failover or redundancy dual uplinks, dynamic DNS, or a backup VPN path
Protocol choices, cryptography, and tunnel settings
EdgeRouter supports IPSec site-to-site VPNs with two common modes: IKEv1 and IKEv2. In practice:
– IKEv2 is preferred for its faster renegotiation, better resilience to network changes, and smaller negotiation overhead.
– IKEv1 remains compatible with older devices or firmware. if you’re mixing older gear, you may need IKEv1.
– Encryption: AES-256 is the go-to for strong security. AES-128 can be used if you need lighter CPU load.
– Integrity/hashing: SHA-256 or SHA-1 in legacy setups, though SHA-256 is recommended for security.
– Perfect Forward Secrecy PFS: enable with a DH group e.g., group 14 for 2048-bit, or group 19/20 for 256-bit equivalents on newer devices.
– Perfect match: ensure the same IKE group, ESP group, and PSK are configured on both sides.
Common best-practice settings you’ll likely use:
– IKE: AES256, SHA256, DH Group 14 2048-bit
– ESP: AES256, SHA256
– PFS: enabled Group 14
– IKEv2 preferred, with IKEv1 fallback if you must connect to an older device
– NAT-T NAT Traversal enabled to handle sites behind NAT routers
Note: Always tailor proposals to the capabilities of both EdgeRouter devices and any remote VPN peers. The two sides must agree on IKE version, encryption, hash, and DH group.
Example network topology
For clarity, here’s a simple two-site example you can adapt:
– Site A
– Local network: 192.168.1.0/24
– Public IP: 203.0.113.1
– Site B
– Local network: 192.168.2.0/24
– Public IP: 203.0.113.2
The VPN will create a tunnel that allows traffic between 192.168.1.0/24 and 192.168.2.0/24, with traffic directed through the IPSec tunnel and routed normally by each EdgeRouter.
Step-by-step setup: Site A to Site B IPsec
Below is a concrete, copy-and-paste-ready sequence you can adapt. Replace IPs, PSK, and subnets with your actual values. This example assumes you’re using EdgeRouter’s EdgeOS CLI.
1 Prepare the interface and general IPSec settings
– This tells EdgeRouter which interface faces the Internet and enables the IPSec subsystem to operate.
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
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
set vpn ipsec ipsec-interfaces interface eth0
2 Define the VPN peer Site B with its public IP, PSK, and tunnel specifics
– This creates a peer definition for the remote site and ties together the local and remote networks.
set vpn ipsec site-to-site peer 203.0.113.2 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 203.0.113.2 authentication pre-shared-secret ‘YourPSKHere’
set vpn ipsec site-to-site peer 203.0.113.2 ike-group IKE-1
set vpn ipsec site-to-site peer 203.0.113.2 default-esp-group ESP-1
set vpn ipsec site-to-site peer 203.0.113.2 local-address 203.0.113.1
set vpn ipsec site-to-site peer 203.0.113.2 tunnel 1 allow-nat-outbound
set vpn ipsec site-to-site peer 203.0.113.2 local-subnet 192.168.1.0/24
set vpn ipsec site-to-site peer 203.0.113.2 remote-subnet 192.168.2.0/24
3 Optional: enable IKEv2 if available and desired
set vpn ipsec identity 1 default-policy
4 Configure firewall allowances to permit VPN traffic
– Allow ISAKMP UDP 500, NAT-T UDP 4500, ESP 50
set firewall name WAN_LOCAL rule 10 action accept
set firewall name WAN_LOCAL rule 10 description ‘Allow IPsec/IKE’
set firewall name WAN_LOCAL rule 10 protocol udp
set firewall name WAN_LOCAL rule 10 destination port 500
set firewall name WAN_LOCAL rule 20 action accept
set firewall name WAN_LOCAL rule 20 protocol udp
set firewall name WAN_LOCAL rule 20 destination port 4500
set firewall name WAN_LOCAL rule 30 action accept
set firewall name WAN_LOCAL rule 30 protocol 50
5 Apply the policy to ensure VPN traffic uses the right path
set service ssh port 22 # optional, for remote management
set service nat destination disable-nat-exceptions # you may adjust for your NAT rules
set vpn ipsec policy 1 proposal 1
6 Save and verify
commit
save
show vpn ipsec status
show vpn ipsec sa
7 Test from Site A to Site B
– Ping a host on Site B’s network, e.g., ping 192.168.2.1
– Use traceroute to verify path
– Check logs if traffic isn’t flowing
Note: On the peer side Site B, you’ll perform the mirrored configuration: assign Site A as the remote subnet and 192.168.2.0/24 as local subnet, with the corresponding public IPs and PSK. The exact local-subnet and remote-subnet values are swapped accordingly.
If you’re using IKEv2 across both sides, you may see faster negotiation and lower latency during tunnel renegotiation. If a tunnel doesn’t come up, re-check the PSK, ensure the public IPs are reachable, verify the subnets don’t overlap, and confirm firewall rules aren’t blocking UDP 500/4500 and ESP.
8 Optional: set up a persistent tunnel monitor
– You can add a simple health check by using an ICMP ping to a remote host across the VPN or by monitoring the IPsec SA status with show vpn ipsec status. If the tunnel goes down, EdgeRouter can attempt a reestablishment automatically, depending on your health settings.
Tips for success:
– Make sure both sides use non-overlapping subnets.
– Use a strong PSK random, long, and unique per peer. If possible, rotate it on a schedule and re-sync both sides.
– If you have dynamic IPs on either site, use Dynamic DNS DDNS and update the edge to remote IP as needed. some setups require more complex scripts and keepalives.
– Consider enabling Dead Peer Detection DPD in the IKE settings to quickly detect otherwise silent peers.
Fine-tuning and troubleshooting common issues
– Tunnel not coming up
– Double-check that the remote IP address and PSK match on both sides.
– Verify that public IPs are reachable try a traceroute or simple ping from each EdgeRouter to the other’s public IP.
– Ensure that the firewall on both sides allows the necessary IPsec traffic UDP 500, UDP 4500, ESP.
– Traffic not routing across the VPN
– Confirm the local and remote subnets are correct and non-overlapping.
– Check the EdgeRouter’s routing table to ensure routes for the remote subnet are in place.
– Verify NAT exemptions so VPN traffic isn’t double-NAT’d or inadvertently NAT’d to the wrong interface.
– Performance and stability
– Ensure you use encryption and hashing that match on both sides AES-256, SHA-256.
– If you’re using a low-power EdgeRouter, consider adjusting the ESP-Group to a lighter option or upgrading hardware.
– Redundant uplinks can help keep VPN up if the primary WAN link flaps.
Security best practices
– Use a unique PSK per site-to-site tunnel, avoid reusing the same key across multiple peers.
– Favor IKEv2 over IKEv1 when possible for better resilience and faster rekeying.
– Keep firmware updated to the latest EdgeOS version to reduce vulnerability exposure and gain bug fixes.
– Regularly audit firewall rules to ensure only necessary ports are open and VPN traffic is properly isolated from untrusted networks.
– Monitor tunnel status and log spikes in failed negotiations. set up alerting if you can.
– Consider enabling logging for VPN events and reviewing it periodically.
Monitoring, maintenance, and real-world tips
– Periodically verify VPN tunnel status with “show vpn ipsec status” and “show vpn ipsec sa.”
– Schedule regular reboots or automatic maintenance windows to ensure stable operation, especially on older hardware.
– Maintain a documented change log whenever you adjust tunnel parameters, PSK, or subnets.
– If you’re managing multiple sites, consider centralizing monitoring e.g., a lightweight central log host or monitoring system to spot VPN issues quickly.
– For remote workers or multiple clients, consider a remote access VPN alongside site-to-site VPNs, but don’t rely on one to replace the other.
Real-world examples and common deployment patterns
– Simple two-site SMB deployment: a small office at Site A connects to a satellite office at Site B. Both sites run EdgeRouter with a single WAN connection each, and the tunnel carries internal office subnets e.g., 192.168.1.0/24 and 192.168.2.0/24 with encryption kept to AES-256/SHA-256 for security.
– Multi-site deployment with failover: three sites share a hub-and-spoke model. Each site has a site-to-site tunnel to the hub, and the hub handles routing policy to bring all sites under a single VPN umbrella. Failover is handled by automated reconnection logic and monitoring.
– Mixed hardware environments: one site uses EdgeRouter X for cost efficiency, while another site uses EdgeRouter 4 for higher throughput. The same IPSec configuration can be adapted across devices as long as the capabilities align, and you tailor the ESP/IKE groups accordingly.
Advanced tips
– Consider splitting traffic: route only necessary traffic through the VPN and let the rest use normal Internet access. You can configure policy-based routing or routing rules to decide which traffic goes through the tunnel.
– For cloud connectivity, you can create a similar IPSec tunnel to a cloud VPN gateway e.g., AWS VPN, Azure VPN if you want to extend your site-to-site connectivity to a cloud environment.
– If you’re dealing with dynamic IPs, you may need a dynamic DNS setup on both ends to keep peers aligned, especially for initial tunnel establishment.
Frequently Asked Questions
# What is a site-to-site VPN, and how is it different from a remote access VPN?
A site-to-site VPN connects entire networks at different locations, allowing devices within each network to communicate as if they were on the same LAN. A remote access VPN lets individual users connect securely to a network from remote locations. Site-to-site is about linking networks, not users.
# Can I use IKEv2 on all EdgeRouter models?
Most mid-to-late EdgeRouter models support IKEv2, but features can vary by firmware version. Check your specific model’s EdgeOS release notes to confirm IKEv2 support.
# Do I need NAT on the VPN traffic?
Typically you disable NAT for VPN traffic between the two sites to allow proper routing of internal subnets. You may still use NAT for other traffic, but ensure VPN traffic is exempt.
# How do I test a site-to-site VPN?
From Site A, ping a host on Site B’s network e.g., 192.168.2.10. Use traceroute to confirm the path. Check the EdgeRouter’s VPN status with show vpn ipsec status or show vpn ipsec sa to verify active tunnels.
# What if the VPN tunnel drops frequently?
Check for IP address changes dynamic IPs, ensure PSK matches on both sides, confirm firewall rules, verify NAT traversal, and check for hardware performance bottlenecks. Enabling Dead Peer Detection DPD helps detect and recover from dead peers quickly.
# How do I handle dynamic IPs on either side?
Use Dynamic DNS DDNS to keep a stable hostname for the remote peer, and configure the EdgeRouter to use that hostname when establishing the tunnel. You may need more advanced scripts or a router with DDNS support for automatic updates.
# Can I run a site-to-site VPN and a separate Internet VPN at the same time?
Yes, you can run multiple tunnels and even a remote access VPN concurrently. Just ensure your firewall and routing policies are properly configured to avoid conflicts and ensure traffic separation where needed.
# What are the typical security considerations for IPSec tunnels?
Use strong encryption AES-256, strong integrity SHA-256, and a robust PSK. Enable DPD and monitor tunnels for unusual activity. Keep firmware current and restrict management access to trusted networks.
# How do I monitor VPN health long-term?
Set up periodic checks of tunnel status, log VPN events, and alert on failures or prolonged instability. A small monitoring host can run regular pings or traceroutes to ensure the remote subnet remains reachable.
# Can I extend this to a multi-site hub-and-spoke VPN?
Yes, you can scale to a hub-and-spoke topology by establishing a core hub site with IPSec tunnels to multiple spokes and routing between spokes via the hub. Ensure you manage routing and firewall policies to avoid suboptimal paths.
# What about IPv6 VPNs on EdgeRouter?
EdgeRouter devices can handle IPv6 depending on firmware and configuration. If you plan to use IPv6, ensure the tunnel and routing policies are adjusted to account for IPv6 subnets and neighbor discovery.
If you’re building a two-site VPN with EdgeRouter, remember to keep your configuration clean, document your subnets, and test thoroughly. With the steps above, you’ll have a robust site-to-site IPSec tunnel that supports reliable inter-office connectivity, improved security, and straightforward maintenance. If you want to explore even more advanced topologies or specific firmware nuances, the EdgeRouter help pages and community forums are great places to dig deeper and find real-world setups that match your exact hardware and network conditions.