Lan to Lan on same subnet

Good Afternoon all,

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?

Right now I got a PIX 501 on inside ip There is nothing plugged into the inside of this pix

On my concentrator side I have the inside and a corp lan behind it

When I change the inside ip of my pix, access lists, and conctrator settings to a different LAN IP I can bring the tunnel up but if I make it the same ip it won't come up. I am allowing the whole subnet through on both acls on the concetrator and pix access-list lanvpn permit ip Is this right? I would change the inside IP but I have to move some critical equip to my co-lo and want to keep the same ip on it All other settings are right to bring it up. Can't seem to find any cisco docs on this... Thanks
Reply to
Loading thread data ...

Here is a good link!

formatting link

Reply to

In article , miwiley wrote: :Here is a good link!

The link you provided shows setting up an VPN 3000 to PIX VPN -- but it uses *different* IP address ranges for the two,

10.13.1.* and 10.31.1.* . The OP is hoping to have the -same- IP address range on both devices.
Reply to
Walter Roberson

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.

Reply to
Walter Roberson

Thanks for the reply Walter that sheds some light on the situation. I think we are going to try resolving by hostname. Thanks again for your help

Reply to
jspr Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.