VPN addressing issue (NAT?)

exactiv

Hi,

My company's LAN is on a range of 172.17.10.0/24
We have over 450 clients which we now need to create IPSEC VPN tunnels to. We don't need to VPN to the whole client LAN, just to a Linux server inside their LAN.
We will probably install a Cisco ASA 5520 to enable us to create all of these tunnels.

My question is this:
Example, If Client A has an internal IP range of 172.17.10.0/24 (which is the same as our LAN IP range), and we try to create an IPSEC VPN Tunnel to them, I presume we will get IP confilts and it will not work.

So, to resolve this, I am proposing that we put an additional network card in the client server, assign it a 192.1.1.0/24 address, and VPN to that.

1) Is my presumption of the conflict correct?
2) Would my proposed solution work?
3) Is there another option available to me (such as some kind of NAT)?

Any help would be very much appreciated.

Thanks!

seamus

Ideal situation would be to create a DMZ on your side where any necessary services run. You can then give this DMZ a different subnet.

In the interests of client security, it would make sense to also have a DMZ on the client side, in which your linux server resides.

This ensures that an attack on your side is unlikely to affect a client's network and vice-versa.

FruitLover

If you can do what Seamus suggests, this is best.

You could also, depending on the VPN endpoints involved, get around it with NAT (I've had to do this in the past, with a VPN between a Juniper and a Cisco).

_CreeD_

No offense but I think you need to look at your details again as the information you've provided is not enough for a workable solution. First up a /24 mask means 254 clients (well IPs), so if there really are 450 clients at the end site you need to get them to check the details they are giving you as they can't be correct. Also you mention 'if' they have the same subnet, a very obscure one at that, which again points to a problem with the details you've been handed. You cannot plan something like this unless you absolutely know what you'll be dealing with. I think the most important thing you need to do right now is get definites on subnets to be used and the real amount of client IPs you'll be tunneling. trying to plan a VPN implementation before then is pointless. If it was me and if for some reason they were using the same subnet I'd use NAT on both sides, pick some arbitrary subnets like 10.1.0.0/16 and 10.2.0.0/16 and have each box translate your local addresses to these before tunneling - ie. your users would see their 172.17.10.200 machine as 10.2.0.100,they'd see your 172.17.10.100 as 10.1.0.100 etc. . If (and again a big IF) they are on the same subnet putting another NIC in one of your servers won't help at all without NAT as your clients will always believe 172.17.10.0/24 is local and never go near your Routers/VPN box, they won't have any way to know that the 172.17.10.x client they're trying to communicate with is in fact across the WAN since your addressing tells them otherwise. Even if all they will access is that server without NAT the server will simply send it's packets out the local 172.17.10.0/24 interface and you have asymetric routing that essentially black holes any replies.

Lastly you mention that the tunnel will be to a Linux box which means you don't have to worry about individual tunnels (unless you change the default rules to per-connection), normally IPSec lan-lan will use one tunnel for all clients on either side of the endpoints but you can set it to create individual tunnels for each if absolutely needed - that should only be in extreme cases where isolation is absolutely necessary and should be avoided otherwise. You do still have to worry about addressing if your subnets overlap regardless just clarifying a bit since "create all of these tunnels." is not necessary from what you described just before.