Dial-up IPsec tunnels with same source subnet - unexpected server routing

[themanyandonlyglenn]

I have a FortiGate configured with two tunnels on two Ethernet ports with the intention to do load balancing or traffic steering on them. They go through a router to converge onto one port/IP at another FortiGate (a.k.a. server). The server is configured with one dynamic tunnel, and I left the dst-subnet in phase2 empty.

I can connect to the server fine, and the server "spawns" logical tunnel interfaces _0 and _1 for each dial-up. However when I ping from client to server or initiate any TCP connections, the responses all come back on _1 even if the origin is from tunnel _0. When I look at the FortiView Sessions list in GUI it just shows the session from the parent tunnel name. The Debug Flow shows the origin point of the session was from the right tunnel but it chooses to output on the other tunnel. It is as if it is using the routing table to pick the interface, not the origin tunnel, and I don't know what makes it pick _1 all the time either.

Is this a misconfiguration on my part or FG is not designed to handle dial-ups from the same source? I had to "set allow-overlap allow" to even allow both tunnels to be up or FG server deletes the old tunnel in favor of new one.

[themanyandonlyglenn]

Both server side and client should be set to weight based according to my config. I have observed however that once a session starts on an interface it stays on it, at least at originating side. Perhaps I am unclear how it works at the responding side, I thought it would also follow the session established by the arriving packet regardless of ECMP mode. The debug flow shows it is not creating a new session for the response.

[themanyandonlyglenn]

Also on server I tried every v4-ecmp-mode and it just seems random which path it chooses. I did a TCP connect and the response debug flow was

enter IPSec interface con1,tun_id=192.168.11.1

output to IPSec tunnel con1_1, tun_id=192.168.12.1, vrf 0

This is the part I am struggling to understand, something in its routing logic can determine the tunnel ID of the session correctly (192.168.11.1) but it chooses to output on the other tunnel anyway, again randomly because I have ping traffic going also and "coincidentally" it responds on the expected tunnel. This last test was v4-ecmp-mode source-dst-ip-based but again this doesn't seem to have any effect.

[mpatel · Accepted solution]

Intrigued!!

Can you configure "set netdevice enable" on the server end FGT IPSEC tunnel Con1. This will cause the fortigate to create a virtual interface for all incoming IPSEC connections. Keep ecmp mode as source-dst-ip-based and test.

[themanyandonlyglenn]

Thanks! So far so good! Now the debug flow says enter interface con1_1 and output con1_1, and enter con1_0 and output con1_0. This fix seems to make sense too.

[mpatel]

Awesome!!

I am glad to hear that this resolved your issue.

Hope you are now confident in implementing this in Production.

[themanyandonlyglenn]

I have another problem related to this configuration. I added a second src-subnet at client and the server is ignoring it.

This is from diag debug application ike -1:

client side:

IPsec SA selectors #src=2 #dst=1

src 0 4 0:192.168.2.0/255.255.255.0:0

src 1 4 0:192.168.6.0/255.255.255.0:0

dst 0 4 0:192.168.4.0/255.255.255.0:0

Server side log:

IPsec SA selectors #src=1 #dst=1

src 0 7 0:192.168.4.0-192.168.4.255:0

dst 0 7 0:192.168.2.0-192.168.2.255:0

add dynamic IPsec SA selectors 282

added dynamic IPsec SA proxyids new 1 282

add route 192.168.2.0/255.255.255.0 gw 192.168.11.1 oif con1_0(37) metric 15 priority 1

etc...

[themanyandonlyglenn]

I should have googled first - I found I need to make two separate phase2-interface for each local subnet in a dialup tunnel as it only advertises one to the server. I don't get why, but oh well.

[Toshi_Esumi]

It's not that advertise or not advertise. They just need to match on both sides.
But, yes, you have to create separate phase2 config for each src-dst pair.
1) 192.168.6.0/24<->192.168.4.0/24
2) 192.168.2.0/24<->192.168.4.0/24

Toshi