I have some issues when i add subnets to an existing vpn tunnel.
For example i have in phase2 address groups with only one source
and one destionation subnet.
Tunnel is up and running with these and the i add on both side another subnet.
I can see in VPN/Monitor that the new subnet is not in the source or destionation on the other side only the original subnet.
I can take down the tunnel and the bring it up but is does not help.
I have tried cli commands:
diagnose vpn tunnel flush/reset/dumpsa etc nothing clears out the old config.
Only way to be 100% sure is to remove old and paste it back into cli with
the new subnet, or reboot the fortigate.
I have this issue on multiple versions, FortiOS 4 branch, 5 branch...
Does anyone else have this issue and does someone know a better way to resolve it ?
Example of running tunnel with this issue
name=MGMT ver=1 serial=42 220.127.116.11:0->18.104.22.168:0 lgwy=dyn tun=intf mode=auto bound_if=16
proxyid_num=1 child_num=0 refcnt=5 ilast=90 olast=90
stat: rxp=52851 txp=61272 rxb=24854888 txb=5249462
dpd: mode=active on=0 idle=5000ms retry=3 count=0 seqno=80939
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=MGMT-2 proto=0 sa=1 ref=2 auto_negotiate=0 serial=1
SA: ref=3 options=0000000e type=00 soft=0 mtu=1436 expire=1740 replaywin=1024 seqno=1
life: type=01 bytes=0/0 timeout=1747/1800
dec: spi=fd2887b0 esp=3des key=24 41f8e32f3502ce3619c8e858f6d2cf64dca029d30498a68b
ah=sha1 key=20 5dcb309a77a4f040c52dc99de21a4de61ef84857
enc: spi=f464468b esp=3des key=24 c9848deada3c3620d3c4e8f89bf690906b250e4feafa2ac5
ah=sha1 key=20 b8e2c4ed2e035315a0071150ff39684bd2f83edc
config phase 2
edit " MGMT-2"
set dst-addr-type name
set phase1name " MGMT"
set proposal 3des-sha1 aes128-sha1
set src-addr-type name
set dst-name " mgmt-destinations"
set src-name " mgmt-network"
edit " mgmt-destinations"
set member " 10.2.0.0/24" " 10.3.1.0/25"
Tunnel is interface based but it does not matter which mode i use.
the only thing I can say is following:
- As you define destination within Phase2 I' m thinking you are using Quick Mode which is actually not needed this means if I do VPN I do it in the classic way for interface mode never using Quick Mode (only for interobability device):
- Create Phase1/2 nothing special not using Quick Mode in Phase2. Using keep alive etc. if you like that tunnel is always up and running
- After creating Phas1/2 route subnet from other site static within Routing (use Phase1 Interface in routing)
- After that create normal Address Policy with destination and/or source Phase1 interface.
That' s it....you can route as many subent as you want (do not forgett to use always a static route to the corresponding phase1 interface). Wihtin the policy you can add as many subent as you want no poblem.
Follow always the rule:
That what is in the rule as destination to the other site has to be routet within static route to the corresponding phas1 interface.
If you have mesh topology do exact the same...it is a little bit complecater to not loose overview but actually exact the same.
If you follow this you can do whatever you want. Keep in mind that you don' t have somewhere overlapping subnets (overlapping enc domains). If so do the same and use Central Nat table to translate as VIP for incoming requests. Keep also in mind first NAT and after Route and not Route for NAT.
hope this helps
I object to using wildcard QM selectors (' 0.0.0.0/0' ).
The QM selector determines which traffic is allowed to start a tunnel negotiation, and which traffic to transfer through it. With wildcards any traffic will bring the tunnel up so you lose a bit of control here.
Besides, seeing the subnets in phase2 documents which traffic you intend to send over the tunnel. This is easily matched with the static route(s) necessary.
Remember that you need these routes on both sides of the tunnel.
AFAIK wildcard QM selectors only work for FGT-to-FGT tunnels. As soon as you have to link to a Cisco or Juniper gateway you need to specify exact subnets.
BTW, Cisco doesn' t understand address groups in QM - use one numeric subnet per phase2, use multiple phase2' s for multiple subnets behind the tunnel.
That' s what I would try in your case as well - get rid of the address group and create multiple phase2' s. This doesn' t determine why your setup didn' t run but most probably fixes the issue.
Yes that is a good suggestion and would probably work well.
I have seen this issue on vpn tunnels with FGT in one end and Cisco ASA in the other end, that time i had three subnets and the Cisco used only two no matter
what, and it was random so it may be something that ipsec vpn is not designed to do.
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.