VPN S2S with same network on local and remote domain

[Marco_Dcr_]

Good morning,
We have a VSX 15400 cluster, R81.10, with a virtual system acting as a site-to-site vpn terminator.
Prior to porting to R81.10, we were using a single "vpn domain local" associated with the gateway. Now we have started to use a dedicated "vpn domain" for each community, so we have a hybrid configuration, where some vpn use the "according to the gateway" vpn domain group, while others use the "user defined" group, defined for each community.

We have this situation:
In the "vpn local domain" associated with the gateway, a network 10.106.0.0/16 is defined.

The need arose to use for a vpn, the network 10.106.24.0/24, as a remote domain. Therefore, a dedicated community "X" was created, defining as vpn domain remote "user defined" this network.

This configuration turns out to work for community "X", but for other vpn, with community "Y", where network 10.106.24.0/24 is defined in the group vpn domain local (according to the gateway), it does not work and the traffic is dropped (clean up rule).

is it possible that the remote VPN domain, used in community "X" as user definded, overrides community "Y" domain local "according to the gateway"? this would explain

I hope that you can help us.

Thank you.

[PhoneBoy]

How would users on the “local” 10.106.24.0/24 know when they need to talk to something on the “remote” 10.106.24.0/24?
This won’t work without address translation on both ends.

[Marco_Dcr_]

Hello PhoneBoy,  thank you for the quick reply.

For the VPN with community "X" the enabled destination network is a NAT network, 10.97.24.0, with which we do Destination NAT on 10.106.24.0/24. Both are declared in the "user defined" remote domain.
For VPN with community "X", The source networks of the clients are different from network 10.106.24.0/24, and the traffic works properly.

While for the VPN with community "Y" with network 10.106.0.0/16 declared in the local domain "according to the gateway", only network 10.106.24.0/24, when called by the remote peer, does not work and our VS drops calls by clean up rule. All other networks in 10.106.0.0/16, when called, work.

[PhoneBoy]

Do you see key installs from the relevant remote gateway?
i.e. do you know 100% that the traffic is actually encrypted?
Again, I would ask the same question of the remote site: how does it know when it's talking to your 10.106.24.0/24 or theirs?

[Marco_Dcr_]

The remote gateway is an SMB 1470 and unfortunately has some problems with logs. Anyway, whatever network is pointed to of major 10.106.0.0/16 works (ex. 10.106.50.10, 10.106.100.10), except for 10.106.24.0/24, where we do not see decrypt on the local gateway (15400), but only drop by blade firewall.

For the remote site, network 10.106.0.0/16 is defined as the "remote domain" of the vpn, no nat is carried out.

[PhoneBoy]

The fact you're not getting traffic to 10.106.24.0/24 encrypted means the remote gateway (1470) is not encrypting the traffic.
Does this network exist behind the 1470 at all?
What code revision is this appliance running?

[Marco_Dcr_]

there might be some problem with 1470 since it is at a very old version, 77.20.
In any case, we wanted to understand if this kind of configuration can also be used in other vpn with other terminators, or it may not work. So having a network 10.106.0.0/16 as Domain Local "according to the gateway," and then using other minor networks (ex. 10.106.24.0/24) of this major as remote domain "user defined " on other vpn (doing d-nat with another network on our fw). Can this work or is the configuration wrong and can it give problems?

[PhoneBoy]

I can’t speak to how other vendors handle this.
I can say because 10.106.24.0/24 is included in the specified encryption 10.106.0.0/16, the 1470 will not encrypt traffic sent to it.
This will need to be addressed through NAT as in the first case.

[Marco_Dcr_]

Leaving aside the issue of remote peer SMB 1470, we would like to understand if on the gateway under our management, a virtual system on vsx 15400 cluster, it is possible to use this configuration or it may lead to problems. So having a local network "according to the gateway" 10.106.0.0/16, and a remote network "user defined" on another community, having addressing 10.106.24.0/24, pointing a nat network to reach it.

[PhoneBoy]

From a management perspective, there's no issue here as the local encryption domain always needs to include hosts that will ultimately communicate over the VPN.
If there is overlap between the two gateways (because they use the same address space), then NAT will be required for segments that use the same IP on both sides to talk to each other.