VPN Question

[biskit]

Hi everyone.

I have a VPN "Tunnel 1" with an enc domain of 172.30.0.0/16

I have a VPN "Tunnel 2" to a different peer, and now I need to add 172.30.50.0/24 to it.

I've added 172.30.50.0/24 to the tunnel 2 enc domain, but traffic to 172.30.50.x still goes down Tunnel 1 and obviously fails.

I assumed the /24 subnet would take priority over the /16 subnet and therefore go down the correct tunnel, but this isn't happening.

Should this work?

Or is my only option here to use a different subnet and get the other side to NAT?

[HeikoAnkenbrand]

There are three basic types of overlapping VPN Domains:

• Full Overlap (Supported)

  Check Point Security Gateway supports fully overlapping VPN Domains. In a full overlap, the VPN Domains are identical. 

• Partial Overlap (Not Supported)

  In certain instances, there may be a partial overlap between the VPN Domains of Security Gateways. In a partial overlap, there is at least one host in both VPN Domains, but there are other hosts that are not in both VPN Domains. Check Point Security Gateway does not support partially overlapping VPN Domains.

• Proper Subset (Supported for Remote Access)

  If one Security Gateway’s VPN Domain is fully contained in another Security Gateway’s VPN Domain, the contained VPN Domain is a proper subset.
  For example, when:

  • The encryption domain of Gateway B is fully contained in the encryption domain of Gateway A,
  • But Gateway A also has additional hosts that are not in Gateway B,
  
  Then Gateway B is a proper subset of Gateway A

More read here:
sk106837

[the_rock]

Hey Matt,

Sounds like you may need to disable supernetting from guidbedit, as CP has always been known (ever since even before R55) to ALWAYS try and present largest possible subnet. Another option is to modify crypt.def file to exclude certain subnets from the community...not sure 100% right way to do that, but there is an sk about it.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Andy

[HeikoAnkenbrand]

Hi @biskit,

I think this it is  not a suppernetting issue. Suppernetting is almost merging two adjacent networks into one network. For example 192.168.0.0/25 and 192.168.0.128/25 to 192.168.0.0/24. It has to do with the operlapped encdom's! You may need to define the routing of the overlapped encdom's in user.def.

172.30.50.0/24 (Tunnel 2) is part of the domain 172.30.0.0/16 (Tunnel 1) -> Therefore an overlapped encryption domain.

Overlapped encdom's are displayed with the following command:

vpn overlap_encdom          

Add the following to user.def and it should work:

$FWDIR/lib/user.def

#ifndef __user_def__
#define __user_def__

//
// User defined INSPECT code
//
subnet_for_range_and_peer = {
<<vpn gateway ip>, 172.30.50.1, 172.30.50.254; 255.255.255.0>
};

#endif /* __user_def__ */

[the_rock]

Not always, yes and no...supernetting with cp usually means presenting largest subnet, regardless whats configured in reality. But, you do have a good suggestion, Im pretty sure it might solve the issue!

[HeikoAnkenbrand]

Hi @the_rock,

I had described supernetting above.

CUT>>>

Supernetting is almost merging two adjacent networks into one network. For example 192.168.0.0/25 and 192.168.0.128/25 to 192.168.0.0/24.

<<<CUT

But as said, the entry  "subnet_for_range_and_peer" in the user.def should help.

[biskit]

Thanks @HeikoAnkenbrand, I'm curious to test this method, but need approval from the customer first as it's a production system.  In the meantime, I'm also trying to arrange NAT with the other side as this is a safer bet.

[PhoneBoy]

Having the same address space going to two different VPN domains is no bueno, regardless of the issues with subnetting that may also occur.
NAT, renumbering, VSX, or some combination thereof will be required.

[abihsot__]

Just an idea, would it work if for 1st tunnel you create group with exclusion (net1 with exclusion for net2), and for 2nd tunnel use only net2 object in encryption domain?

[biskit]

I did think of that but it was too risky to test it out in production.  However, TAC thinks it will work providing the Tunnel Management is set to "One VPN tunnel per each pair of hosts", which could add unwelcomed overhead to the tunnel.  

[Timothy_Hall]

The "pair of hosts" setting will cause new IPSec/P2 tunnels to be formed for every combination of hosts that try to use the VPN; if you are going to move forward with this be sure your rulebase is as locked down as possible to limit the number of tunneling combinations; you may also want to disable PFS to avoid a computationally expensive Diffie-Hellman calculation every time a new IPSec/P2 tunnel starts.