| Table of Contents. Â Background.
In a route-based IPsec tunnel, each protected subnet pair is commonly represented by a Phase 2 selector.
When a new local or remote subnet must traverse the tunnel, the peer devices must agree on the new selector parameters. The related firewall policies, routes, and NAT behavior must also allow the new traffic.
If only one side is updated, or if the selector definition does not match exactly, the new traffic may not pass even though the tunnel appears up for the existing selectors.
 Confirm the tunnel design before making changes.
Identify whether the tunnel is route-based or policy-based.
Confirm the local subnet, remote subnet, and whether one or multiple new subnet pairs must be added.
Confirm whether the remote peer is another FortiGate or a third-party device.
Confirm whether proxy IDs, traffic selectors, dynamic routing, or static routing are in use.
 Add matching Phase 2 selectors on both peers.
The new Phase 2 selector must be configured on both tunnel endpoints.
The local subnet on one side must match the remote subnet on the other side, and the remote subnet on one side must match the local subnet on the other side.
Encryption and authentication settings for the new selector must also match, including proposals, Diffie-Hellman group, and lifetime if those values are defined per selector.
Mismatch between peers is one of the most common causes of negotiation failure for newly added subnets.
Use a naming format that identifies the local and remote subnet relationship.
Example naming patterns include the following.
-
BranchA_to_HQ_10.10.10.0_24_to_10.20.20.0_24. -
p2_HQ_ServerNet_to_Branch_ClientNet.
Clear naming makes future troubleshooting easier and reduces the chance of editing the wrong Phase 2 entry.
 Verify firewall policies and routing.
Adding the Phase 2 selector alone is not sufficient.
Make sure that firewall policies allow traffic from the new source subnet to the new destination subnet across the IPsec interface.
Review the following items.
-
Source interface. -
Destination interface. -
Source address object. -
Destination address object. -
Service. -
Schedule. -
Security profiles, if applicable. -
NAT setting.
For site-to-site IPsec traffic, NAT is usually disabled unless the design explicitly requires it.
Confirm that traffic for the new remote subnet points to the correct IPsec interface.
If static routing is used, verify that the route exists for the new remote subnet.
If dynamic routing is used, verify that the new subnet is being advertised and learned as expected.
If SD-WAN is involved, confirm that the IPsec member, rules, and route selection still match the intended path.
 Review overlap, address objects, and selector scope.
Make sure the new local or remote subnet does not overlap with existing local networks, remote VPN networks, or NAT-translated ranges.
Overlapping addressing can cause incorrect route selection, selector mismatch, or asymmetric traffic flow.
If overlap exists, redesign or translate the subnet before implementing the change.
If firewall policies use address groups, update the related groups to include the new subnet.
If central SNAT, VIP, or local-in related logic is used in the design, verify that those objects do not interfere with the new traffic.
A common issue is that the new subnet is added in Phase 2, but not added to the address group used in the firewall policy.
Use subnet definitions that match the intended protected networks.
Avoid adding overly broad selectors unless the tunnel design specifically requires summary networks and both peers support that approach.
More specific selectors usually make troubleshooting easier and reduce unintended traffic matching.
 Coordinate the change and renegotiate as needed.
The new selector should be added on both ends during the same change window whenever possible.
If one peer is updated before the other, traffic for the new subnet may fail until the remote side is updated.
This is especially important when the remote peer is managed by another team or third-party provider.
After adding the new Phase 2 entry, it may be necessary to trigger fresh negotiation for the new selector.
If negotiation does not start automatically, generate traffic that matches the new subnet pair.
If stale negotiation state exists, clear the IPsec tunnel or Phase 2 security associations carefully during the maintenance window.
Use caution in production environments, because clearing the tunnel may interrupt existing traffic.
 Validate with tunnel and debug commands.
After the change, confirm that the new selector is installed and negotiated correctly.
 diagnose vpn tunnel list
get vpn ipsec tunnel summary
If traffic does not pass, review IKE and IPsec debug output.
 diagnose debug reset
diagnose vpn ike log-filter clear
diagnose debug application ike -1
diagnose debug enable
Stop debug after testing.
 diagnose debug disable
diagnose debug reset
Review whether the new selector appears, whether proxy IDs match, and whether the peer rejects the new subnet pair.
 Test both directions and review NAT exemption.
Test traffic from the local new subnet to the remote new subnet, and also from the remote side back to the local side.
A one-way test may miss firewall policy, routing, or return-path issues.
Confirm that sessions establish correctly and that reply traffic returns through the tunnel.
If the environment uses NAT policies, central SNAT, or third-party peer NAT rules, verify that the new subnet is excluded from unwanted source NAT before entering the IPsec tunnel.
Unexpected NAT can cause selector mismatch or traffic failure.
Document the following items after the change.
-
New local subnet. -
New remote subnet. -
Phase 2 object name. -
Related firewall policies. -
Related routes. -
NAT expectations. -
Peer device and ownership.
This makes future expansion and troubleshooting easier. Â Recommended validation workflow. -
Add the new address objects. -
Add the new Phase 2 selector on both peers. -
Update firewall policies and address groups. -
Update static or dynamic routing if needed. -
Verify NAT behavior. -
Generate test traffic for the new subnet pair. -
Confirm negotiation and traffic flow. -
Review logs and debug if traffic fails.
 Common symptoms and expected result.
Common symptoms when the new subnet is not added correctly include the following.
-
Existing VPN subnets continue to work, but the new subnet does not pass traffic. -
Tunnel shows up, but only old selectors pass traffic. -
IKE negotiation logs show selector or proxy ID mismatch. -
Traffic hits policy, but no reply returns. -
Traffic is routed outside the tunnel instead of through the IPsec interface. -
Traffic is NATed unexpectedly before reaching the tunnel.
After the new subnet is added correctly on both peers, and the firewall policy, route, and NAT conditions are updated consistently, traffic for the new subnet should negotiate successfully and pass through the existing site-to-site IPsec tunnel. Â Related articles: General IPsec VPN configuration. Adding or modifying Phase 2 selectors. Dynamic routing and advertisement of new subnets. | 
