Is IPSEC possible in this scenario (Internal and external subnet conflict)

Norsak

Hi,

I have figured out how to setup IPSEC between 2 PFsense when one is behind a 3rd party NAT device.
I thought I was good to go…then I discovered I have one more problem and I don't know if it can be solved without re-configuring one subnet.

Background

I inherited a network (S1) which uses 192.168.10.0/24 as it's subnet. It has maybe 20 devices with static IPs.
We now have 8 branch offices, but they are not ordinary branch offices; we have a few desks in government offices.
We still have our own firewalled network, but we get internet access via a DSL connection which we do not control.
I am in the process of configuring site-to-site vpn between the branch offices S2,S3…S9 and main office S1

What Works
I can get IPSEC working between S1 and S2, by asking the IT department managing DSL2 for some port forwarding

The problem
As you can see, my main subnet S1 happens to overlap S3a, a subnet which I do not control.
So now PF3 sees two 192.168.10.0/24 subnets, so PF3 can't route traffic to S1

NAT before IPSEC?
I read about NAT before IPSEC (haven't tried it yet)
But in this scenario I think I would need to apply NAT before IPSEC to PF1.
That would be problematic as S1 contains all our servers, and I would need to add port-forwarding for all services in S1

Do I understand NAT before IPSEC? correctly?
Is there another way to add site-to-site VPN to the scenario I have drawn?

jimp

In cases when there is a subnet conflict on both sides with a VPN, both sides must perform NAT+IPsec, but this is different since it's the LAN on one side and WAN on the other. Unless S1 needs to talk to S3A you only need NAT on the S1 side.

You don't need to setup port forwards and other things, just on that particular IPsec Phase 2 you need to setup a NAT subnet.

S1 would NAT its 192.168.10.0/24 to, say, 10.10.1.0/24. On S1 in the IPsec Phase 2 settings for the tunnel to S3, just put that in the NAT/BINAT option.

To reach 192.168.10.1 at S1, a client at S3 would instead contact 10.10.1.1 for example.

Unless there is some other quirk I'm forgetting with the WAN side at S3 that should be OK