Adding more subnets to existing tunnel

[rickards]

Hi 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 111.222.222.222:0->222.111.111.111: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 src: 0:10.10.10.0/255.255.255.192:0 dst: 0:10.2.0.0/255.255.255.0:0 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" next firewall group edit " mgmt-destinations" set member " 10.2.0.0/24" " 10.3.1.0/25" next Tunnel is interface based but it does not matter which mode i use.

[AndreaSoliva]

Hi 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 have fun Andrea

[rickards]

Hi Andrea Thanks for your reply, so you mean is should use 0.0.0.0/0 in source and destination in the quick mode selector ?

[llteane]

that will only work if the default gateway of the Firewall in the IPsec tunnel as well, otherwise you will have dual default gateway which will mess up your internet connection.

[ede_pfau]

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.

[rickards]

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.