spoke to spoke communication not working

[clwolf]

Hi all. I have a hub/spoke config connected via dialup hub route based ipsec vpn. The spokes can communicate with the hub, and the hub can communicate with the spokes, but spoke to spoke cannot communicate. Here I think is all the necessary config. (I have two clients who have this setup, this one with only 2 branches, and another one with 8 branches. Both display the same thing, so it must be something in my configuration that is not right). Sorry if it is too much info, but just in case anyone looks on this forum for how to set it up, they can (albeit if they do my config it won' t work all the way) Admin: -wan 1 ip: 70.12.232.154 -lan ip: 192.168.254.1 (Class C) -phase1: --name:toSpokes --DialupUser --wan 1/ Main/ Preshared Key --accept any peer ID --Enable IPSec Interface --IKE 1 / Main --3DES/SHA1 --DHGroup 5 --keylife 28800 --XAUTH off --NAT T enabled --DPD enabled -phase2: --name: toSpokesPh2 --selected toSpokes --3DES/SHA1 --enable replay detection --enable PFS --DH Group 5 --keylife 1800 seconds --autokeepalive off --dhcp ipsec off --no quick mode selector (0.0.0.0/0) -zone: --places toSpokes into zone called Spoke_Zone. Unchecked " Block intra-zone traffic" -addresses: --Main_Lan: 192.168.254.0/24 --Branch1_Lan: 10.1.1.0/24 --Branch2_Lan: 10.1.2.0/24 ---Group: Spokes_Net (Branch1_Lan and Branch2_Lan) -firewall policy: --Spoke_Zone/Spokes_Net --> internal/Main_Lan always/any/accept No NAT -route: 0.0.0.0/0 wan1 70.12.232.153 distance 10 10.1.1.0/24 toSpokes distance 5 10.1.2.0/24 to Spokes distance 5 Spokes -Branch1 (Branch 2 is identical except for wan, and branch 1 and branch 2 and associated addresses are swapped) --wan ip 80.7.9.154 --lan ip 10.1.1.1 (Class C) -vpn phase 1: --Name: toHub --Static: 70.12.232.154 --wan 1/ main/ preshared key --accept any peer ID --Enable IPSec Interface --IKE 1 / Main --3DES/SHA1 --DHGroup 5 --keylife 28800 --XAUTH off --NAT T enabled --DPD enabled --vpn phase 2: --toHubPh2 --selected toHub --3DES/SHA1 --enable replay detection --enable PFS --DH Group 5 --keylife 1800 seconds --autokeepalive on --quick mode selector ---src: 10.1.1.0/24 / dst: 192.168.254.0/24 -addresses: --Main_Lan: 192.168.254.0/24 --Branch1_Lan: 10.1.1.0/24 --Branch2_Lan: 10.1.2.0/24 -- Company_Net (Main_Lan and Branch2_Lan) -firewall policy --toHub/Company_Net --> internal/Branch1_Lan always/any/accept No NAT --Internal/Branch1_Lan--> toHub/Company_Net always/any/accept No NAT -route: 0.0.0.0/0 wan1 70.12.232.153 distance 10 10.1.2.0/24 toSpokes distance 5 192.168.254.0/24 to Spokes distance 5 Thanks everyone

[ede_pfau]

Hi, well in the Branch1 phase2 quick selector you specify that only the 192.168.254.0 subnet is behind the ' toHub' tunnel. One of the reasons why the FortiOS Handbook example for a hub-and-spokes setup uses a 10.1.1.0/16 subnet for the quick selector and /24-subnets included in this range for the hub as well as each spoke. If you can' t change the hub subnet then you have to build the phase2 qm selector using an address group. You can only do that using the CLI. Include both the hub subnet and the Branch2 subnet. That should get packets for Branch2 onto the tunnel - at the moment they leave via the default route to wan1. Again, get the FortiOS Handbook for 4.00MR2 (2200+ pages!) and have a look at the examples. They' ve been written with the help of Fortinet SEs and aren' t far away from real world setups.

[clwolf]

Funny you should mention that. I put down the 2 spoke/ 1 hub thinking it would be easier to help out. Here is the scoop. The real client has 9 spokes, and 1 hub. All subnets fit into the 192.168.x.x/16 subnet. Main is 192.168.11.0/24. Hubs very from 192.168.x.0/24. This is the perfect plan and I followed the IPSec 4.0 MR2 vpn book from pages 50 to 60 (or so...at another client right now, but that is what I printed out I believe). Everything works except communication between spokes. I had another client that is mentioned above. I had them as a mesh network, but in order to see if I could duplicate the issue I did the above to them. I have since moved them back to the mesh and they are working fine. Should I create another topic with the real client? Sorry, don' t want to do the wrong protocol. I also have been in contact with Fortinet support, and they seemed to be stumped as well.

[ede_pfau]

Well, frankly I were you I' d stick with the h+s setup in order not to get too confused. It' s quite a different setup in all and you' re there halfways. What you can do to permit spoke-to-spoke traffic in addition to the " intra-zone" setting is the following: Firewall>Policy src int: VPNzone src net: 192..../16 /* comprising all spoke and the hub subnets */ dst int: VPNzone dst net: 192..../16 service: all This looked quite redundant to me the first time I saw it in the Fortinet documentation (can' t remember the exact place now) but it makes sense. You could give it a try. And about the QM selectors, you are sure that they fit all subnets?

[clwolf]

so, I had unchecked " block intrazone communication" but that still didn' t work. I created the rule that ede_pfau suggested, but the trick was to make sure enable nat IS NOT selected. Once that was set, all is well. This really is a slick setup. When you add another site, you just have to configure the branch site, and add the route into the main router. Very cool.