Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
carl_t
Contributor

multiple domain per vpn community

Hi All

I remember reading a post a year or 2 ago regarding multiple domains per vpn community, so we could have a different subnet that builds the tunnel etc rather than being bound to the encryption domain for all vpn's.

What version of software did this start in? and has anyone got any screenshots to share for the configuration?

Many thanks

Carl

0 Kudos
4 Replies
Timothy_Hall
Legend Legend
Legend

This was introduced in SMS version R80.40, and seems to work with backward compatibility on gateways back into at least version R80.10.  On the Gateways screen of the VPN Community below you can override either the VPN domain definition for your gateways and/or for Externally Managed Gateways/Interoperable Devices.  In practice what I've typically seen is overrides here for a small subset of the VPN domain for your gateway (thus keeping your gateway from negotiating an overly-large subnet for itself in IKEv1 Phase 2), but leaving the definition for any external peer gateways at the default setting and defining the peer's VPN domain on the Externally Managed Gateway/Interoperable Device object itself.

VPN_Domains.png

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Marcel_Gramalla
Advisor

Hi, 

Timothy already showed the configuration but keep in mind that the subnets you want to select has to be in the main encryption domain of the gateway. So if you have a /16 subnet (10.10.0.0/16) in the main domain you cannot select a /24 subnet (10.10.10.0/24) as it will break your VPNs. See the following SK: Using "Encryption Domain Per community" feature overrides Encryption Domain for other communities (c...

0 Kudos
Tobias_Moritz
Advisor

I want repeat what was already written elsewhere is this community:
That design decision on how CP calculuates its own encryption domain for IKE phase 2 handshakes (IPsec SA) is just a mess.

It was always a mess (just remember that old implied supernet calculation "feature") and as this sk shows, it is still a mess after the improvement for R80.40 shown here was introduced.

When comparing to competitors, it is really hard to do 3rd party VPNs with this design. Not all 3rd parties are cooperative and agree to a subnet which works for you on your CP side.

You still have to hack vpn.def file to get simple thinks working like showing 10.0.0.0/24 to one 3rd party peer and 10.0.0.0/16 to another.

I guess many other people who have to handle a large amount of 3rd party Site-to-Site-VPNs on a CP gateway would agree with me, that CP R&D really should think this over again.

It should not be hard for customers, to specify exactly which encryption domains a CP gateways offers during IKE phase 2.

Our customers and we were happy when we saw the improvent for R80.40 beeing anounced 2019 (or early 2020), but the limitation now shown in the sk was a sad surprise.

(2)
the_rock
Legend
Legend

Tim gave excellent response and it is 100% correct...I also believe that started in R80.40 and you can now change it from the screenshot he attached.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events