I am a self confessed newbie at this so please go easy on me
I have searched the forums for this matter, but all the issues seem to be concerning both endpoints having overlapping subnets.
Over the last couple of years the number of third party companies I need VPN access to has steadily increased, as a result I find myself with some of these companies having a DST Address (in IPsec|Policies) that overlap. However I have no control over their choice of internal Subnet, nor can I direct them to modify.
As a result I now have three IPsec policies that will only work if they are at the top of the numerical order in the Policies list. This is not something I can live with anymore, as they are often required to send and receive data at the same time.
Any guidance on this matter would be very very welcome.
What you describe is not only an issue for IPsec - even without IPsec you need to decide to which particular one out of several identical remote addresses accessible via different VPN connections a packet from your network should be sent. So the more important issue to resolve is how to choose the right tunnel towards an address depending on some other factors, and only a secondary issue is how to make this work with plain IPsec which uses policies.
Can you describe in more detail the traffic pattern? Are all the individual devices in connected customers’ networks always initiating any connection towards devices in your network, or are there cases where the first packet of a connection may be sent by one of the devices in your network (VoIP calls and FTP sessions are examples coming to my mind right off)?
This is a wellknown problem of RFC1918-style local networks assigned at random and then requiring interconnect.
It really cannot be solved. However, you can work around it by defining a 2-way 1:1 NAT (netmap) so some network range
is translated into the range used by the other party.
It is an ugly stopgap measure as of course some time later the fake range you used to translate will be the range in use by
a new client and you have to decide between changing your translation and setting up yet another translation for the new client.
So what you have is not easy to solve. You could consider implementing IPv6, but you will likely encounter practical problems.
That’s why I’m asking the OP about the traffic pattern. For a generic case what you say will inevitably happen sooner or later, for specific scenarios a long-lasting solution such as NATing the clients’ accesses using an RFC1918 or, if really critical, an RFC 6598 address range may be provided, thus separating the clients not only from each other but also from your own RFC1918 address space (if used). Use of plain IPsec further complicates that of course.
Regarding traffic patterns, the initiators can be from either end and the largest subnet that has such regular traffic that their tunnel is rarely down. The traffic itself is for DICOM images between radiology centres.
I like the idea of doing 1:1 NAT with my problem endpoints as they are used much less regularly but again, they maybe initiated by either side.
Do you talk about initiators with regard to IPsec sessions of with regard to TCP sessions between the sites delivering the actual data? Are you administering the “IPsec gateways” at both ends or the clients have their own hardware and administrators? How many servers are there at each site to which clients from other networks need to connect, and what file transfer protocol is used? Are the data transmission always between your site and one external one or are transfers between two external sites forwarded via your one?
I agree with those questions as posted by sindy, as the first thing you would try to get rid of is the usage of plain IPsec policies between te routers at the sites.
Even when you have different makes of routers not all under your control, moving to GRE/IPsec will make it much easier to achieve what you want.
(GRE tunnels over IPsec transport, where the IPsec is only used to encrypt and protect the content and the IPsec policies only cover GRE tunnel traffic without
having to match the IP addresses used at either side. then you can easily NAT the traffic, and firewalling is also much more straightforward)
