I am connecting my office to a client's network via IPSec. The need is for me to connect directly to internal IPs on their network; there is no need for them to connect to any services on my internal network. I would prefer to not reveal my office network to the other side, suggesting NAT. (All IPs fake.)
-----------
--/ \-- +--------------+
/ \ /---+ |
( 11.11.11.0/16 )---- | 11.11.11.1 |
\ / +------==------+
--\ /-- ===
----------- === MY OFFICE
CLIENT Internet == -----------
=== --/ \--
=== / \
+------==-------+ /--( 10.1.1.0/24 )
| | /--- \ /
| 22.22.22.1/30 +-- NAT --\ /--
+---------------+ -----------
For this, it seems that I could connect from (say) 10.1.1.23 to 11.11.11.45, and yet the "11." network sees all connections from 22.22.22.1. I have a single-address static subnet (22.22.22.1/30), so I believe I can set my encryption domain to 22.22.22.0/30 and use NAT on my end. (The remote end is not using NAT.)
My understanding from https://networkengineering.stackexchange.com/a/45107/43748 is that NAT has a slight penalty to it (not a surprise), but it does not say that it cannot be done. https://networkengineering.stackexchange.com/a/41503 suggests NAT can be used to solve problems with overlapping subnet ranges. Both (and others) tell me that NAT in a site-to-site configuration can be fine.
But the remote side admins "insist" that they must know my office internal subnet to properly function. I think all they need to know for my encryption domain is 22.22.22.0/30, encryption gateway 22.22.22.1, with no internal network defined.
What is my misunderstanding wrt this network topology?
(The specific models, if it matters: my end CheckPoint-790; remote ends are either Cisco ASA or SonicWall, depending on the client.)
11.*/16
to10.*/24
. Great point, actually. Though I still don't feel they need to know anything about my internal network, including the subnet: security-by-obscurity should never be relied on, but it still has a net-positive effect as a layer on top of other (strong) security techniques.