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.
Any help would be appreciated. Thank you!
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
That's odd about Local Gateway creating the opposite effect. Do you have multiple IP addresses on your WAN interface?
Are you confirming 100% that the phase2 selectors are the same on both Firewalls?
Is the SonicWall configured the same way in terms of tunnel set up?
Are you confirming IPSec traffic is encrypted for outgoing connection from the 192.168.10.X network?
On a Site to Site I achieved that either by setting up one p2 selector for each subnet on that ipsec or setting the p2 selector to 0.0.0.0/0.0.0.0.
In the second case traffic has to be limited by policies then.
Also in any case static routing might be is needed on the ends of the tunnel.
On a dial up IPSec split tunneling does the trick.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
That's odd about Local Gateway creating the opposite effect. Do you have multiple IP addresses on your WAN interface?
Are you confirming 100% that the phase2 selectors are the same on both Firewalls?
Is the SonicWall configured the same way in terms of tunnel set up?
Are you confirming IPSec traffic is encrypted for outgoing connection from the 192.168.10.X network?
Single assigned IP address on the WAN interface.
Phase 2 selectors are the same and do connect properly.
The only difference is that the SonicWall has two connections from my IP address to theirs. One for each used range of my network. That's the only thing that I can figure that is different.
I've tried creating a 2nd IPSec tunnel but it isn't connecting.
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.
Thank you!
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?
Created on 12-30-2022 09:43 AM Edited on 12-30-2022 09:44 AM
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.
On a Site to Site I achieved that either by setting up one p2 selector for each subnet on that ipsec or setting the p2 selector to 0.0.0.0/0.0.0.0.
In the second case traffic has to be limited by policies then.
Also in any case static routing might be is needed on the ends of the tunnel.
On a dial up IPSec split tunneling does the trick.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
The P2 selector is what I added to make it work (one for each subnet). This matched the expectations of the other end of the tunnel.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1641 | |
1069 | |
751 | |
443 | |
210 |
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.
Copyright 2024 Fortinet, Inc. All Rights Reserved.