Skip to main content
BCIT
Visitor III
December 29, 2022
Solved

IPSec Tunnel "Works," but doesn't

  • December 29, 2022
  • 2 replies
  • 6975 views

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!

Best answer by gfleming

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? 

 

 

2 replies

gfleming
Staff
gflemingAnswer
Staff
December 30, 2022

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? 

 

 

BCIT
BCITAuthor
Visitor III
December 30, 2022

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.

BCIT
BCITAuthor
Visitor III
December 30, 2022

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!

sw2090
SuperUser
SuperUser
December 30, 2022

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.

BCIT
BCITAuthor
Visitor III
December 30, 2022

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.