Hello colleagues! Got confused with a simple case with IPsec on the first view. The situation:
We have a 3rd party partner who is not smart enough unfortunately. We have to establish an IPsec tunnel via 2 different link , but with policy base only(don't ask why). The partner has the only single IP for IPsec tunnels where I have to connect , the route for this IP I receive from BGP from both "outside" links (with \30 link's subnets) , one as a main and another as a backup. We have a subnet on a vlan-interface that we announce into the BGP and we have to establish the IPsec Phase1 with the source IP from the subnet. So the problem is that the subnet that we have to use as IPsec source is different from the Outside's interfaces. In my opinion in theory it's possible, looks like a simple routing , an IP packet from my FG will be NAT-ed (SrcNat) with one of IP's from the announced subnet , there is a route toward the partner's IP, the backward packet will get the outside interface with the subnet's Dst IP, the FG has the route to this IP as connected , so should work. Are there any platform dependences in this case ? I attached a simple schema just in case.
The model is FG201E, image 7.4.7.
Thanks!
Solved! Go to Solution.
Hi @Ivan90 ,
BGP runs between the FortiGate and the upstream router over both /30 links, advertising 10.25.48.0/24. Normal BGP best-path selection chooses the superior route—via ISP1 or ISP2—while the other link remains on standby. The partner uses a single public IP address (10.0.3.13) for the IPsec tunnel.
Assumptions:
WAN 1 = 10.25.3.1/30 → ISP1 router 10.25.3.2
WAN 2 = 10.25.3.13/30 → ISP2 router 10.25.3.14
DMZ/inside = 10.25.48.0/24 (FortiGate owns 10.25.48.1)
Partner IPsec peer = 10.0.3.13
We will tunnel any-to-any (0/0) traffic per partner’s spec.
1- (Optional) Add a loopback* with the source address (skip if 10.25.48.1 is already a primary/secondary IP on the FortiGate)
config system interface
edit loop0
set ip 10.25.48.1/32
set type loopback
next
end
2- Phase-1 interfaces (one per link): local-gw tells IKE to use 10.25.48.1 as the packet source even though the packets exit WAN1/WAN2.
config vpn ipsec phase1-interface
edit p1_wan1
set interface wan1
set remote-gw 10.0.3.13
set local-gw 10.25.48.1 # ‹— key line
set ike-version 2
set proposal aes256-sha256
set psksecret ENC <key>
next
edit p1_wan2
set interface wan2
set remote-gw 10.0.3.13
set local-gw 10.25.48.1 # ‹— key line
set ike-version 2
set proposal aes256-sha256
set psksecret ENC <key>
next
end
3- Phase-2 selectors (permit everything)
config vpn ipsec phase2-interface
edit p2_wan1
set phase1name p1_wan1
set src-subnet 0.0.0.0/0
set dst-subnet 0.0.0.0/0
set proposal aes256-sha256
next
edit p2_wan2
set phase1name p1_wan2
set src-subnet 0.0.0.0/0
set dst-subnet 0.0.0.0/0
set proposal aes256-sha256
next
end
4- Routing / fail-over: Primary BGP route to 10.0.3.13 makes to-partner-wan1 come up; if the route flips to WAN2, the same source IP keeps working and to-partner-wan2 becomes active.
5- Policies (policy-based IPsec): Create two identical policies—one per interface—matching the partner’s requirement.
6- Verification process
get vpn ipsec tunnel summary
execute ping-options source 10.25.48.1
execute ping 10.0.3.13
That setting 10.25.48.1 as the local-gw—whether on the DMZ interface or a loopback—is the supported way to originate the tunnel from that subnet, even though the traffic physically exits through WAN1 or WAN2. The FortiGate advertises 10.25.48.0/24 on both WAN links, and whichever path BGP prefers keeps Phase 1 active. No extra routing is required; the same local-gw works over either interface.
Caveat: Policy-based IPsec lacks built-in redundancy, so the standby tunnel stays idle until BGP switches routes. For faster, smoother failover, consider migrating to route-based IPsec with SD-WAN.
BR.
If my answer provided a solution for you, please mark the reply as solved it so that others can get it easily while searching for similar scenarios.
CCIE #68781
Hi @Ivan90 ,
BGP runs between the FortiGate and the upstream router over both /30 links, advertising 10.25.48.0/24. Normal BGP best-path selection chooses the superior route—via ISP1 or ISP2—while the other link remains on standby. The partner uses a single public IP address (10.0.3.13) for the IPsec tunnel.
Assumptions:
WAN 1 = 10.25.3.1/30 → ISP1 router 10.25.3.2
WAN 2 = 10.25.3.13/30 → ISP2 router 10.25.3.14
DMZ/inside = 10.25.48.0/24 (FortiGate owns 10.25.48.1)
Partner IPsec peer = 10.0.3.13
We will tunnel any-to-any (0/0) traffic per partner’s spec.
1- (Optional) Add a loopback* with the source address (skip if 10.25.48.1 is already a primary/secondary IP on the FortiGate)
config system interface
edit loop0
set ip 10.25.48.1/32
set type loopback
next
end
2- Phase-1 interfaces (one per link): local-gw tells IKE to use 10.25.48.1 as the packet source even though the packets exit WAN1/WAN2.
config vpn ipsec phase1-interface
edit p1_wan1
set interface wan1
set remote-gw 10.0.3.13
set local-gw 10.25.48.1 # ‹— key line
set ike-version 2
set proposal aes256-sha256
set psksecret ENC <key>
next
edit p1_wan2
set interface wan2
set remote-gw 10.0.3.13
set local-gw 10.25.48.1 # ‹— key line
set ike-version 2
set proposal aes256-sha256
set psksecret ENC <key>
next
end
3- Phase-2 selectors (permit everything)
config vpn ipsec phase2-interface
edit p2_wan1
set phase1name p1_wan1
set src-subnet 0.0.0.0/0
set dst-subnet 0.0.0.0/0
set proposal aes256-sha256
next
edit p2_wan2
set phase1name p1_wan2
set src-subnet 0.0.0.0/0
set dst-subnet 0.0.0.0/0
set proposal aes256-sha256
next
end
4- Routing / fail-over: Primary BGP route to 10.0.3.13 makes to-partner-wan1 come up; if the route flips to WAN2, the same source IP keeps working and to-partner-wan2 becomes active.
5- Policies (policy-based IPsec): Create two identical policies—one per interface—matching the partner’s requirement.
6- Verification process
get vpn ipsec tunnel summary
execute ping-options source 10.25.48.1
execute ping 10.0.3.13
That setting 10.25.48.1 as the local-gw—whether on the DMZ interface or a loopback—is the supported way to originate the tunnel from that subnet, even though the traffic physically exits through WAN1 or WAN2. The FortiGate advertises 10.25.48.0/24 on both WAN links, and whichever path BGP prefers keeps Phase 1 active. No extra routing is required; the same local-gw works over either interface.
Caveat: Policy-based IPsec lacks built-in redundancy, so the standby tunnel stays idle until BGP switches routes. For faster, smoother failover, consider migrating to route-based IPsec with SD-WAN.
BR.
If my answer provided a solution for you, please mark the reply as solved it so that others can get it easily while searching for similar scenarios.
CCIE #68781
Holly cow ! Mate , it's the most clear and detailed answer I've ever got. Yes you got the question absolutely right. I had the same thoughts except that I set up the inside or lo FG's interface as the interface of Phase1. And I expected that in this case it would be possible to configure only one phase1. So according to your example I can use IP different of Wan1,2 direct addresses, ok, will try.
Of course the policy based ipsec is obsolete, unfortunately our partner doesn't understand it , it's a government's company with "standards".
Thanks mates, appreciate it!
User | Count |
---|---|
2517 | |
1347 | |
794 | |
639 | |
455 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.