IPsec source IP

Question

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!

atakannatak · Accepted Answer

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

Ivan90 · Answer

Well, I have to rise the topic again. There are 2 issues (on 7.4.11)

1)When I choose a loop0 or any other vlan interface (except of directed interfaces) like from the example the status of the tunnel (Ph1 and 2) is up and everything is green, but I see 0 Rx traffic.

2)When I do exactly like in the example (2 separated IPsec tunnels) , with the same src IP , but from different interfaces - I get both tunnels down (red).

looks like something platform depended.
Does anyone have this kind of experience ? Thanks!

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded