Lan to Lan on same subnet

Discussion in 'Cisco' started by jspr, Apr 11, 2005.

  1. jspr

    jspr Guest

    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

    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
    jspr, Apr 11, 2005
    1. Advertisements

  2. miwiley

    miwiley Guest

    1. Advertisements

  3. 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.
    "Mathematics? I speak it like a native." -- Spike Milligan
    Walter Roberson, Apr 11, 2005
  4. 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

    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.
    This signature intentionally left... Oh, darn!
    Walter Roberson, Apr 12, 2005
  5. jspr

    jspr Guest

    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
    jspr, Apr 12, 2005
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. This Old Man
    This Old Man
    Oct 20, 2003
  2. Vass

    Subnet a subnet mask?

    Vass, Aug 26, 2005, in forum: Computer Support
  3. Replies:
  4. Replies:
    Walter Roberson
    Jan 18, 2007
  5. Amadej

    Cisco 1812 subnet to subnet NAT

    Amadej, Sep 3, 2007, in forum: Cisco

Share This Page