I have an IPSec tunnel between my FortiGate (7.0.8 0418) and a SonicWall firewall (version: old).
After much hammering I have it working, but only for clients in part of my network. I'm running using 192.168.8.0/21 as my network and netmask. In my IPSec settings I have this entire range listed as an address group and in my Local Address list. For some reason 192.168.12.1 through 192.168.13.254 can all communicate with the target addresses. 192.168.10.1 through 192.168.10.254 cannot. They are all using the same gateway.
I can get the .10.0 network to communicate if I toggle the "Local Gateway" in the IPSec Tunnel to "ON" and enter my public IP address. This kills the .12.0 and .13.0 tunnel connection. These are both from the same tunnel, running a single Address Group.
The firewall policy is set up so that internal interfaces with the associated internal source can go to the Outgoing interface (tunnel interface) with the destination IP address range. I do see traffic on this policy.
The .10.0 network can communicate with the .12.0 one without issue.
As a note, when I use .10.0 or .12.0 these networks are not subnetted or vlanned out. It is all part of the same IP range (which just adds to my confusion). There are reasons it is the way it is but it is an inherited mess, not a planned one.
What I did that worked (which was probably the right way to do it from the get-go) was to take my single VPN that would connect and I broke it down into the actually used subnets (.12.0/23 and .10.0/24).
In the phase 2 negotiation both of these networks were connecting to the remote network independently (this is what the SonicWall was expecting).
The "click toggle, other one works" was more likely just a lucky or unlucky roll of the dice. I certainly didn't approach it scientifically to verify that pattern.
After fixing my firewall settings (messed them up while trying everything I could think of) things were working properly.
I see you fixed it by breaking out the /21 in your P2 selector. But that's odd if the other side was also using /21 it should still work. Unless it wasn't the same and sonicwall was using individual /24's?
The SonicWall side was using a /24 (.10.0) and a /23 (.12.0). I was hoping that just using the /21 would encompass all of that in a single connection.
What happened was one of the two subnets would work, the other wouldn't, and my toggling of a setting randomly made one of them work. That toggle seemed to make the other one work but it was most likely entirely random.
This also made the 8-hour tunnel timeout fun since it would still show as active and working but connections would be lost.
Once I set up two p2 connectors (one for each subnet) it was working with both subnets.
Sounds like it was annoying (and it was) but my old firewall I couldn't do anything myself and needed the other company's support (which kept normal business hours) to make changes. I learned more in this implementation and setup than I did in 8 years with the old device.
Yep so the Phase2 selectors were not the same. This is exactly why you need to ensure both sides have identical configurations or you will have issues like this. Glad you got it sorted out. Would be nice if you can mark my post as solution as I asked if the phase2 selectors were the same there. Cheers.
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.