multiple domain per vpn community

[carl_t]

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

[Timothy_Hall]

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.

[Marcel_Gramalla]

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...

[Tobias_Moritz]

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.

[the_rock]

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.