I'm stuck in a little bit of a problem here, maybe someone can help me.
I have on central office network with a PIX515E, this firewall acts as an Easy VPN Server.
on the other side I have multiple ASA5505 acting as Easy VPN Clients in NEM Mode which are dialing in.
Behind all these ASA's there are one or two server appliances.
The goal here is that we can roll out all these server appliances each with one ASA's onto the internet and they are automatically calling home and establishing a VPN, so we can manage them from our office.
So far it's not that complicated, but the tricky thing is that all the server appliances we want to mange have exactly the same IP on their management interface.
Is there the possibility to mask or NAT the IP on the mgmt interface of the server towards the easyVPN connection per username?
Maybe it doesn't have to match with the username, if it would be possible to do this hardcoded in the ASA5505 it already would help a lot.
I've attached a quick visio picture of the layout.
thanks for your answers
As far as I know it will not work if 5505 will work as hardware clients.
I also see a big problem of what happens if you have multiple NEM subnets with same IP addressing
I think your best option is L2L and NAT traffic before encryption. (Landing on dynamic crypto map when coming in, and probably certificate authentication...)
I don't think you can automate this ...
But my HW client knowledge is from ASA 7.2 :-)
Thanks a lot for your fast answer.
I know it is a big problem having multiple sites with the same subnet around,
because of this the idea to use nat on the client-side ASA to mask the remote site onto another subnet which is unique,
so the central pix will only see the "masked" IP's.
But here my knowledge of EasyVPN ends.
So you say it's not possible to force the ASA to tell it's VPN counterpart only the nat-ed adresses from their clients?
ASA 5505 as HW client will only tell one, inside subnet as the one used in IPsec SAs (local identity of course).
I've revisited conf guide and don't see much chnage in it:
That's why I think in your case you need to use L2L (dynamic peer+ certificates) you will have some more flexibility but quite a bit more configuration.