8 hours ago8 hr Site-to-site IPsec is easy when you control both ends and they're the same vendor. It's a lot less fun when the other end belongs to a different team, runs a different vendor's gear from a different decade, and you're trading screenshots over email. Most of the failures we see aren't exotic. They come down to overlapping subnets, mismatched proposals, a missing NAT exemption or an MTU problem. Here's the planning sheet we send out, and the order I troubleshoot in when the tunnel shows "up" and nothing passes. Before anyone touches config Admin access to both firewalls or routers, or a contact on the other side who can read their config to you. Public IPs for both peers (for example 192.0.2.10 and 198.51.100.20). The local and remote subnets that need to talk. A test host on each side that will answer a ping. Agree on the worksheet first Before anybody configures anything, we send the remote admin a short worksheet and both sides fill in the same values. It feels like paperwork, but it saves a lot of back-and-forth calls later. Peer public IP (A / B): 192.0.2.10 / 198.51.100.20 IKE version: IKEv2 Authentication: PSK (exchanged out of band) or certificate Phase 1 encryption/integrity: AES-256 / SHA-256 Phase 1 DH group: 14 (or 19/20) Phase 1 lifetime: 28800 s Phase 2 protocol: ESP Phase 2 encryption/integrity: AES-256 / SHA-256 (or AES-GCM) PFS group: 14 (or none, but both must agree) Phase 2 lifetime: 3600 s Local subnets (A): 10.10.20.0/24 Remote subnets (B): 10.40.0.0/24 NAT-T: enabled (UDP 4500) DPD / keepalive: enabled Subnets can't overlap If both offices use 192.168.1.0/24, routing has no way to tell which side a packet belongs to. You can re-address one side, which is the best long-term answer, or NAT inside the tunnel, which works but makes every future rule harder. Also check for overlap with everything else you route, like other tunnels, SD-WAN and remote-access VPN pools. Overlapping a remote-access or mesh VPN range is a classic way to break a site for just one group of users, and those tickets are confusing because it works fine for everyone else. Proposals have to match exactly Phase 1 (the IKE SA) and phase 2 (the IPsec or child SA) are negotiated separately. A phase 1 mismatch means nothing comes up. A phase 2 mismatch means phase 1 is up and phase 2 never establishes, and some GUIs still show that as a green tunnel. Stay away from legacy options (DES, 3DES, MD5, DH groups 1, 2 and 5) unless the other side truly can't do better, and if you have to use them, write it down. PSK or certificates A long random pre-shared key is fine for a handful of tunnels. Send it over a different channel than the rest of the config. Certificates scale better, avoid shared secrets, and are the right answer when one peer has a dynamic IP. The catch is that you now own a CA and certificate expiry, so put the expiry date on your calendar. NAT-T If either peer sits behind NAT, like an ISP modem or a cloud NAT gateway, IKE moves from UDP 500 to UDP 4500 and ESP gets encapsulated in UDP 4500. Allow UDP 500, UDP 4500 and IP protocol 50 (ESP) from the peer's address. Behind NAT, the peer's IKE identity is often its private IP, so you may need to set the local and remote ID explicitly. Bring it up with real traffic Policy-based tunnels often won't negotiate phase 2 until interesting traffic shows up. Start a continuous ping from a host on one side to a host on the other and watch the logs while it runs. Ping a host, not the remote firewall's inside interface, unless you know that firewall answers pings sourced from the tunnel. Up but no traffic, in the order I check it Each of these rules out a whole layer, so I go in order even when I think I already know the answer. Start with the SA counters. Look at the phase 2 SA and its encrypt and decrypt (encaps/decaps) counters. On Cisco IOS that's show crypto ipsec sa, and most firewalls have an IPsec monitor page. If encrypts are climbing and decrypts sit at zero, your packets are leaving and nothing is coming back, so the problem is on the far side. If neither is moving, traffic isn't reaching the tunnel on your side. Check the proxy IDs, also called traffic selectors. For policy-based VPNs, the local and remote subnets have to be mirror images on both ends. If side A says 10.10.20.0/24 to 10.40.0.0/24, side B must say 10.40.0.0/24 to 10.10.20.0/24. A /16 on one side and a /24 on the other is a mismatch for many vendors. When a route-based device (VTI) talks to a policy-based one, set explicit proxy IDs on the route-based side instead of leaving 0.0.0.0/0. Look at routing. On route-based tunnels you need a route for the remote subnet pointing at the tunnel interface. Then check the return path. The remote host's default gateway has to be the device that terminates the tunnel. If the remote server's gateway is a different router, its replies head out to the internet instead. Confirm the NAT exemption. If outbound NAT translates your source before IPsec sees it, the traffic no longer matches the selectors. Add a no-NAT or identity NAT rule for local-to-remote subnets above your general outbound NAT rule. Check firewall policy. A tunnel being up doesn't mean traffic is allowed. Most firewalls need explicit rules for traffic entering from the VPN zone or interface, in both directions. Check host firewalls too, because Windows will happily block ICMP from a "foreign" subnet. Last, suspect MTU and MSS. If ping works but SMB, RDP or web pages hang, it's probably fragmentation. IPsec overhead, plus NAT-T and PPPoE, shrinks the usable MTU. Clamp TCP MSS on the tunnel. Around 1360 is a safe place to start. ! Cisco IOS on a tunnel interface (route-based VTI) interface Tunnel10 ip mtu 1400 ip tcp adjust-mss 1360 To test the path MTU, ping with the don't-fragment bit set and walk the size down until it passes. # Windows: 1372 bytes of payload + 28 bytes of headers = 1400 ping 10.40.0.10 -f -l 1372 # Linux ping -M do -s 1372 10.40.0.10 What working looks like Phase 1 and phase 2 SAs are both established, and the encrypt and decrypt counters are climbing on both ends. Ping works in both directions, started from each side. A real application test holds up, like an SMB file copy or an RDP session that stays connected for several minutes. That catches MTU problems that ping misses. The tunnel survives a rekey. Wait out the phase 2 lifetime or force a rekey, and confirm traffic keeps flowing. I don't call a tunnel done until the rekey test passes. Otherwise it tends to come back as a ticket the next morning. Failures we keep running into It works for an hour, then dies. That's a lifetime or PFS mismatch. The first negotiation succeeds and the rekey fails, so match lifetimes and PFS exactly. Only one side can start the tunnel. One peer is set to respond-only or has a dynamic IP. That's fine if it's intended, but write it down so the next person doesn't chase it. Only the first subnet works when there are several behind one side. Some vendors build one child SA per subnet pair and others want them combined, so look at how each side is building SAs. One tunnel worked for everyone except staff connected from home. Their remote-access VPN pool used the same range as the remote office. The counters tell you which side to look at, and that usually settles the "your end or mine" conversation before it gets awkward.
Create an account or sign in to comment