In article , jspr wrote: :Question: is it possible to bring up a lan to lan vpn between a PIX :and a concentrator if they are on the same ip scheme and subnet on the :inside?
Yes -- if the path between the two of them is also on the inside of them.
For example, you can wirte PIX and VPN concentrator "back to back" or otherwise connect the two inside interfaces together, and the two will be able to use IPSec with each other.
It took me a few readings of your message to catch on, but that's not what you are after: you want the inside LAN of the PIX to be tunneled through the outside to the outside of the VPN concentrator and decapsulated there into the same LAN as for the PIX, having passed through the outside of the PIX inbetween.
The difficulty with this is that the PIX only tunnels data that crosses interfaces, and when you have the same subnet on both sides of the tunnel, the PIX thinks the destination for the remote IP ought to have been in the inside, and promptly drops the packet. If you examine the syslog in this case, you will find messages in there about there being no route from src inside:SOMEIP to dst inside:SOMEOTHERIP -- with 'inside' being shown as the interface for both parts.
What you want is a "transparent" or "layer 2" firewall. The PIX 501 is a L2TP -server- (can accept incoming L2TP), but not a L2TP -client- (cannot initiate L2TP.) The PIX L2TP is also documented as being compatable -only- with Windows 2000/XP L2TP -- i.e., it's there to terminate calls from Windows hosts, not as a general L2TP mechanism.
Layer 2 firewalling is supported in PIX 7.0, but the 515/515E is the smallest PIX that supports PIX 7 at this time.
I reviewed the documentation on setting the transform set to "mode transport", thinking that might be the trick, but it was not a usable approach because it is tied in to the L2TP.
The only thing you can do with the PIX 501 with 6.2/6.3 software is set up an IPSec connection to a "management interface". This allows you to remotely reach the inside interface of the 501, and I believe that in theory you could do that reaching while being in the same subnet as the inside interface. But when I say "inside interface" I mean -just- as far as the interface -- as in you can configure the PIX but you can't get traffic further on through that connection.
The point is not clearly documented, but my analysis suggests to me that when you create a "management interface" VPN that the tunnel that gets created is in IPSec "transport" mode rather than "tunnel" mode. IPSec "transport" mode allows the same IP range on both sides, but it is defined as being strictly to reach a host (i.e., in this case to reach the PIX itself from outside), and IPSec says that transport mode "shall not" be used to connect to a device to use that remote device as a "security gateway" (i.e., to allow packets to pass through the security gateway to devices beyond.) And tunnel mode requires different IP subnets on both sides for it to work.
You mention that you have some critical devices going to co-lo that you don't want to have to renumber. Does that not wanting to have to renumber apply only to their internals? Is it acceptable if the corp LAN has to access them through different IPs (transparently if access is by hostname) than they know themselves by? For example, if corp addressed them by 192.168.3.x and that got translated to 192.168.2.x by the time it reached the co-lo ? And vice versas, is it acceptable if the moved equipment has to refer to the corp servers by IP addresses other than what the servers know themselves as?
If so, if you can play this game of nicknumbers, then you can use one of the standard approaches applicable to overlapping networks.