Branch with Dynamic IP Needs OSPF over an IPsec Tunnel
A manufacturer has a headquarters firewall with a static public address 198.51.100.10 and a branch firewall that receives a dynamic PPPoE address and sits behind a carrier NAT. HQ LAN is 10.1.0.0/16; branch LAN is 10.2.0.0/16. The branch also translates its users to 192.168.100.0/24 for general Internet access. The company wants dynamic routing between sites so that new subnets added at either side are learned automatically, and it wants multicast support for a video wall application. The current attempt uses a direct IPsec tunnel with IKEv2 and a pre-shared key, traffic selectors 10.1.0.0/16 and 10.2.0.0/16, and static routes. Phase 1 and Phase 2 come up only when the branch initiates, and OSPF neighbors never form. When engineers add a static route on HQ pointing to the tunnel, some traffic loops or is dropped, and multicast does not cross.
1. Recommend the tunneling approach and justify it against the requirements, including why plain IPsec is insufficient here.
Read the worked answer
Plain IPsec in tunnel mode can carry unicast IP packets matching the traffic selectors, but it cannot natively carry multicast or broadcast traffic, and it does not present a routable point-to-point interface to the routing process. OSPF uses multicast hello packets (224.0.0.5) and relies on interface-level neighbor discovery; those packets do not match a unicast IPsec traffic selector, so no adjacency forms. Static routes over IPsec also require the traffic selectors to include every subnet pair, which breaks the goal of automatic learning.
The appropriate design is GRE over IPsec: a GRE tunnel interface on each firewall with private tunnel addresses, for example 172.31.1.1/30 and 172.31.1.2/30. OSPF runs on the GRE interfaces, and the GRE packets are encrypted and authenticated by IPsec. GRE carries multicast and broadcast, so OSPF and the video wall multicast work. The IPsec traffic selectors should match the GRE endpoints (host-to-host), not the LAN subnets, which simplifies policy and routing. Alternatively, a vendor-supported VTI-style tunnel can provide similar behavior, but GRE over IPsec is the standard interoperable answer. This also separates routing from encryption and reduces the number of IPsec SAs needed when subnets change.
2. Given the branch's dynamic address and carrier NAT, what IKE and IPsec settings must be planned, and how should tunnel initiation work?
Read the worked answer
HQ must accept a dynamic peer: configure the IKE peer with remote address as dynamic and rely on the branch to initiate. Use IKEv2 with a strong pre-shared key or certificates; if certificates are used, the branch must present an identity HQ can verify. Enable NAT traversal detection so that the branch behind carrier NAT is discovered and UDP encapsulation is used. The branch should be configured with the HQ static address as remote peer, and its local address can be the PPPoE interface or a loopback if the carrier permits it. Dead peer detection should be enabled so both sides detect failures.
Because the branch initiates, HQ cannot bring up the tunnel on its own; HQ should have a route to the branch networks pointing to the GRE tunnel, and the GRE tunnel should be kept up by OSPF hellos or a keepalive. If the branch's dynamic address changes, the IKE SA must be re-established; use aggressive DPD timers and a short enough IKE SA lifetime, but avoid so many rekeys that the tunnel flaps. For NAT exemption, ensure branch traffic to HQ is not translated by the general 192.168.100.0/24 outbound NAT rule; the GRE/IPsec traffic must bypass that NAT or be sourced from the tunnel address. Verify with display ike sa, display ipsec sa, and display interface brief for the GRE interface.
3. Explain the NAT and routing interactions that could cause the reported loops or drops, and how to correct them.
Read the worked answer
The branch's general NAT rule translating to 192.168.100.0/24 can capture traffic that should go through the tunnel. If the tunnel traffic is translated before encryption, HQ sees 192.168.100.0/24 rather than 10.2.0.0/16, so the IPsec traffic selectors and OSPF routes no longer match. The result is dropped packets or asymmetric routing. Similarly, on HQ a static route pointing to the tunnel for 10.2.0.0/16 can conflict with a more specific connected route or with a default route, causing loops if the tunnel's own endpoint addresses are routed through the tunnel.
The correction is to make NAT and routing deterministic. On the branch, add a NAT exemption or a policy that excludes traffic from 10.2.0.0/16 to 10.1.0.0/16 and traffic to the GRE peer address from the outbound NAT rule. Route the GRE peer address via the ISP gateway, not via the tunnel. Use OSPF on the GRE interfaces rather than static routes; advertise 10.1.0.0/16 at HQ and 10.2.0.0/16 at the branch, and set the tunnel interface as an OSPF interface with the correct network type. If static routes are retained temporarily, point them to the GRE tunnel interface, not to the physical WAN interface. Check with display ip routing-table and traceroute from each LAN.