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.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
Hi,
The two tunnels you have on the client FGT are they both WAN ports with different ISP circuits? (I assume not). The below link explain the behavior you are seeing.
You will have to use peer ID in the dial up tunnel config.
Configure 2 tunnels using the above KB.
Then add these tunnels into SDWAN and you will be able to steer traffic or perform load balancing.
The allow-overlap config is used when both ends of tunnel have overlapping subnets that need to communicate with each other.
Hope you find this helpful.
Are you saying it looks like this? To me it's almost impossible unless you enabled asymmetric routing on the server_FGT. Did you confirm it by sniffing at server_FGT or client_FGT? You must have two separate phase1/phase2 config sets on the client_FGT side.
Toshi
Yes that looks about right. Each tunnel from client has the same phase2 subnets.
Sorry but this doesn't work, I set peer ID etc as per instructions.
See these debug flows at server side and the connections diagram. The first set of flows is the link monitor pinging between FG's. "output to IPSec tunnel" is correct for tunnel 192.168.11.1 but not in the second case for 192.168.12.1, it outputs to 11.1 tunnel. It almost seems like a bug to me.
The second set of flows is end to end pinging between PCs but it does the same thing.
First, you need to disable asic offloading on the policies then clear the sessions or drop the tunnels to see session establishment.
But why do you need IPSec tunnel between FGT-VM and FG60F without internet? You can just route them. Or, are you just testing your theory/ideas in test environment?
Toshi
I did do what you said, and yes this is a benchtop test. I am trying to simulate a tunnel on each ISP converging on a gateway that routes to a FortiGate concentrator and then to some other private network like a main office/branch office hub/spoke like configuration but with resilient links.
Created on 04-16-2024 11:17 AM Edited on 04-16-2024 11:18 AM
If just for redundancy/load-balancing between two tunnels per location, I would suggest "IPsec Aggregate" like below. The server side doesn't have to have two circuits unlike the example in the doc. The doc is a little old but it should still work with 7.x.
https://docs.fortinet.com/document/fortigate/6.4.0/administration-guide/779544/ipsec-aggregate-for-r...
Much easier/simpler once routing part was properly set up.
Toshi
Kindly attach the IPsec configs for both tunnels on the Client FGT.
Also send the output of the command “get router info routing-table all” and get router info routing-table database” on the client FGT.
Also how are you deciding which tunnel the client will use to reach remote in case the phase 2 selectors are 0.0.0.0/0.0.0.0 on both tunnels.
Created on 04-16-2024 11:23 AM Edited on 04-16-2024 01:04 PM
This is the client side IPsec config
config vpn ipsec phase1-interface
edit "dialup1"
set interface "port9"
set mode aggressive
set peertype any
set net-device disable
set proposal aes128-sha256 etc...
set localid "abc"
set remote-gw 192.168.5.2
set psksecret redacted
next
edit "dialup2"
set interface "port12"
set mode aggressive
set peertype any
set net-device disable
set proposal aes128-sha256 etc...
set localid "abc"
set remote-gw 192.168.5.2
set psksecret redacted
next
end
config vpn ipsec phase2-interface
edit "dialup1"
set phase1name dialup1
set proposal null-sha256
set auto-negotiate enable
set src-subnet 192.168.6.0 255.255.255.0
set dst-subnet 192.168.4.0 255.255.255.0
next
edit "dialup2"
set phase1name dialup2
set proposal null-sha256
set auto-negotiate enable
set src-subnet 192.168.6.0 255.255.255.0
set dst-subnet 192.168.4.0 255.255.255.0
end
The router table relevant rows are here, I have to hand-type it in so I'm not typing the whole thing:
S 192.168.4.0/24 [2/0] via dialup1 tunnel 192.168.5.2, [1/50]
S [2/0] via dialup2 tunnel 10.0.0.1, [1/50]
S 192.168.5.2/32 [2/0] via 192.168.11.2, port9, [1/50]
[2/0] via 192.168.12.2, port12, [1/50]
C 192.168.6.0/24 is directly connected, port8
C 192.168.11.0/24 is directly connected, port9
C 192.168.12.0/24 is directly connected, port12
I am doing ECMP with the interface weights for dialup1 and dialup2 at 50 each.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1548 | |
1032 | |
749 | |
443 | |
210 |
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 2024 Fortinet, Inc. All Rights Reserved.