- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cannot add the aggregate vpn member
Hi There,
I tried to create a aggregate VPN between two fortigate node. FOS 7.0.14.
https://docs.fortinet.com/document/fortigate/6.2.16/cookbook/779544/ipsec-aggregate-for-redundancy-a...
there are two VPN tunnel established already. and I added one tunnel to the aggregate vpn successfully. But I cannot add another member into the group.
according to the guidance, I have to set aggregate-member enable. But I cannot do it, check the error message below.
# next
Please enable phase2 auto-negotiate if ipsec-aggregate uses redundant algorithm.
This interface is currently in use.
object set operator error, -23, roll back the setting
Command fail. Return code 1
I tried to enable the phase 2 autonegotiation and delete the vpn tunnel and create a new one. the result is same.
I tried to disable the virtual interface but the result is same. Since there is traffic on the physical interface already. I cannot disable it. I don't want to break the service.
Appreciate your advice on how I can achieve it? TIA :)
Solved! Go to Solution.
- Labels:
-
FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"Please enable phase2 auto-negotiate if ipsec-aggregate uses redundant algorithm."
-- this will be displayed even when "set auto-negotiate enable" is set
"This interface is currently in use."
-- this is probably the source of the problem - you need to make sure the interface is removed from all policies before adding it to aggregate
- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"Please enable phase2 auto-negotiate if ipsec-aggregate uses redundant algorithm."
-- this will be displayed even when "set auto-negotiate enable" is set
"This interface is currently in use."
-- this is probably the source of the problem - you need to make sure the interface is removed from all policies before adding it to aggregate
- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @AlexC-FTNT ,
Thanks for your reply, I delete all the policy and create the new tunnel again. it works. Now I can see the aggregate VPN is working.
But it seems the routing table choose one member only rather than the aggregate VPN IP X.X.X.X
# get router info routing-table de x.x.x.x
Routing table for VRF=0
Routing entry for x.x.x.x/16
Known via "static", distance 10, metric 0, best
* via TAL_IND_Aggress tunnel x.x.x.x vrf 0, tun_id
I check the OSPF status and it is not up.
get rou info ospf neighbor
OSPF process 0, VRF 0:
Neighbor ID Pri State Dead Time Address Interface
does the OSPF work here?
In addition, I add the policy to allow SSLVPN user to access the aggregate VPN tunnel, but the policy lookup always failed due to the route lookup failure. Is it related to this?
Thank you :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm not so sure I can give an exact answer, but for your case, the SDWAN solution seems to apply better. Maybe post a separate topic for this to troubleshoot, if you want to use aggregate ipsec instead of sdwan
- Toss a 'Like' to your fixxer, oh Valley of Plenty! and chose the solution, too00oo -