Bypassing ingoing-outgoing limit interface.

Discussion in 'Cisco' started by AM, Mar 16, 2005.

  1. AM

    AM Guest

    Hi all,

    I would permit traffic incoming from a VPN towards another IPsec tunnel. It' quite vital the traffic between those 2
    remote sites. So I thought to add use another interface where to terminate one of the tunnels. My doubts are about the
    two interfaces will have 2 different IP address of the same subnet our provider supplied to us.

    Do you think is there any kinf of implication of problem doing that?

    Thanks,

    Alex.
     
    AM, Mar 16, 2005
    #1
    1. Advertising

  2. In article <7PRZd.16081$>, AM <> wrote:
    :I would permit traffic incoming from a VPN towards another IPsec tunnel.

    :So I thought to add use another interface where to terminate one of the tunnels.

    Which platform is this for? 3/4 of your questions are about PIX, but
    the other quarter are about your routers, so we cannot make any assumptions
    about your needs when you do not say the devices involved.
    --
    "[...] it's all part of one's right to be publicly stupid." -- Dave Smey
     
    Walter Roberson, Mar 16, 2005
    #2
    1. Advertising

  3. AM

    AM Guest

    Walter Roberson wrote:
    > In article <7PRZd.16081$>, AM <> wrote:
    > :I would permit traffic incoming from a VPN towards another IPsec tunnel.
    >
    > :So I thought to add use another interface where to terminate one of the tunnels.
    >
    > Which platform is this for? 3/4 of your questions are about PIX, but
    > the other quarter are about your routers, so we cannot make any assumptions
    > about your needs when you do not say the devices involved.


    Sorry Walter :),
    you are correct. The question is about PIX which has this limit.
    We want the traffic between two remotes sites connected via VPNs (terminated to our PIX) to flow without any problem.
    so my idea was,k and is, to use another physical interface but giving it an IP of the same subnet of IP range which the
    other IP (where we terminated all the VPN) belongs to.

    Do you think there will be problems doing this?
    Consider we want to "attach" to our network as an extension of our one and PC of that network ought to be able to go any
    place we go, remote sites through VPNs as well.

    Thanks,
    Alex.
     
    AM, Mar 16, 2005
    #3
  4. In article <MAVZd.15258$>, AM <> wrote:
    :The question is about PIX which has this limit.
    :We want the traffic between two remotes sites connected via VPNs (terminated to our PIX) to flow without any problem.
    :so my idea was,k and is, to use another physical interface but giving it an IP of the same subnet of IP range which the
    :eek:ther IP (where we terminated all the VPN) belongs to.

    :Do you think there will be problems doing this?

    In PIX 6, this cannot be done -- each [logical] interface must be in a different subnet.
    PIX 7.0, for the 515/515E, 525, and 535 might remove this limit -- it introduces
    major changes in the handling of interfaces. 7.0 will be available any day/week
    now (but wasn't available for download as of late last week.)

    [Note: I would hesitate to trust "highly important" data flows to the -first-
    edition of any major rewrite of software!]


    Perhaps due to the long hours I've been putting in lately, I have not grasped why
    you are considering two interfaces. Could you expand on (or re-explain) that part?
    --
    "This was a Golden Age, a time of high adventure, rich living and
    hard dying... but nobody thought so." -- Alfred Bester, TSMD
     
    Walter Roberson, Mar 16, 2005
    #4
  5. AM

    AM Guest

    Walter Roberson wrote:
    > In article <MAVZd.15258$>, AM <> wrote:
    > :The question is about PIX which has this limit.
    > :We want the traffic between two remotes sites connected via VPNs (terminated to our PIX) to flow without any problem.
    > :so my idea was,k and is, to use another physical interface but giving it an IP of the same subnet of IP range which the
    > :eek:ther IP (where we terminated all the VPN) belongs to.
    >
    > :Do you think there will be problems doing this?
    >
    > In PIX 6, this cannot be done -- each [logical] interface must be in a different subnet.
    > PIX 7.0, for the 515/515E, 525, and 535 might remove this limit -- it introduces
    > major changes in the handling of interfaces. 7.0 will be available any day/week
    > now (but wasn't available for download as of late last week.)
    >
    > [Note: I would hesitate to trust "highly important" data flows to the -first-
    > edition of any major rewrite of software!]
    >
    >
    > Perhaps due to the long hours I've been putting in lately, I have not grasped why
    > you are considering two interfaces. Could you expand on (or re-explain) that part?


    As the version 7.0 is not still available and my boss won't allow me (if not really needed) to
    upgrade th IOS (Finesse) as it's working fine and as we have 2 unused interfaces I posted my
    question to allow traffic between two VPN tunnels using the existing one used as VPN points and the
    new one for the other half of company network. I would wait for the latest version of the Finesse
    just to be sure there aren't bugs or announced caveauts.

    Alex.
     
    AM, Mar 16, 2005
    #5
  6. In article <qv1_d.664652$>, AM <> wrote:
    :As the version 7.0 is not still available and my boss won't allow me (if not really needed) to
    :upgrade th IOS (Finesse) as it's working fine and as we have 2 unused interfaces I posted my
    :question to allow traffic between two VPN tunnels using the existing one used as VPN points and the
    :new one for the other half of company network.

    Ah, do I understand correctly then that this is a hub/spoke issue?
    That you want to relay between two VPN spokes using a single PIX
    at the hub?

    If so, and if you are not able to beg, borrow, or steal an IP in
    a different public IP subnet, then you can work it like this:

    ____
    {internet} ------> main outside IP-->|PIX|inside IP ----> switch ---> LAN
    ^ | | v
    {internet} ----> another public IP-^ | |dmz IP <-------<
    -----

    The second tunnel is directed to one of the public IPs that is
    static'd through to the outside interface (easier if it's the same
    subnet as the main outside IP, but it doesn't have to be.) The PIX
    is set to static that public IP to become the internal IP of the
    DMZ interface. The packet is transfered in via the inside interface
    to a switch, which forwards the packet back to the PIX, except to
    a DMZ interface. The packet will be returning to the PIX by a
    -different- interface than it exitted the PIX, so the PIX will accept
    the packet rather than dropping it. The packet gets decapsulated
    at the DMZ interface, and the interior packet gets routed --
    finding that it is the outside interface that is the destination.
    That's a different interface (outside) than the encapsulated packet
    entered on (DMZ), so the transition is permitted, and the interior
    packet will be duely encapsulated and transmitted to the other VPN
    endpoint.

    In the reverse direction, the packet from the first VPN hits the
    outside interface, is decapsulated, the routing for the
    interior packet destination points through the DMZ interface so
    the packet heads out there, getting encapsulated as it goes.
    {mumble here about mechanisms about getting the packet to head
    from the DMZ interface back through the inside interface -- it's
    easy if the device I show as a switch is a router instead; I would
    need to think more about how to get the right routing if it really
    is a switch.}
    --
    Are we *there* yet??
     
    Walter Roberson, Mar 16, 2005
    #6
  7. AM

    AM Guest

    Walter Roberson wrote:
    > In article <qv1_d.664652$>, AM <> wrote:
    > :As the version 7.0 is not still available and my boss won't allow me (if not really needed) to
    > :upgrade th IOS (Finesse) as it's working fine and as we have 2 unused interfaces I posted my
    > :question to allow traffic between two VPN tunnels using the existing one used as VPN points and the
    > :new one for the other half of company network.
    >
    > Ah, do I understand correctly then that this is a hub/spoke issue?
    > That you want to relay between two VPN spokes using a single PIX
    > at the hub?
    >
    > If so, and if you are not able to beg, borrow, or steal an IP in
    > a different public IP subnet, then you can work it like this:
    >
    > ____
    > {internet} ------> main outside IP-->|PIX|inside IP ----> switch ---> LAN
    > ^ | | v
    > {internet} ----> another public IP-^ | |dmz IP <-------<
    > -----
    >
    > The second tunnel is directed to one of the public IPs that is
    > static'd through to the outside interface (easier if it's the same
    > subnet as the main outside IP, but it doesn't have to be.) The PIX
    > is set to static that public IP to become the internal IP of the
    > DMZ interface. The packet is transfered in via the inside interface
    > to a switch, which forwards the packet back to the PIX, except to
    > a DMZ interface. The packet will be returning to the PIX by a
    > -different- interface than it exitted the PIX, so the PIX will accept
    > the packet rather than dropping it. The packet gets decapsulated
    > at the DMZ interface, and the interior packet gets routed --
    > finding that it is the outside interface that is the destination.
    > That's a different interface (outside) than the encapsulated packet
    > entered on (DMZ), so the transition is permitted, and the interior
    > packet will be duely encapsulated and transmitted to the other VPN
    > endpoint.
    >
    > In the reverse direction, the packet from the first VPN hits the
    > outside interface, is decapsulated, the routing for the
    > interior packet destination points through the DMZ interface so
    > the packet heads out there, getting encapsulated as it goes.
    > {mumble here about mechanisms about getting the packet to head
    > from the DMZ interface back through the inside interface -- it's
    > easy if the device I show as a switch is a router instead; I would
    > need to think more about how to get the right routing if it really
    > is a switch.}


    I'm not sure to understand what you mean, but anyway this is the correct scenario.


    ------outside---- 1st provider --------------|-----|-----inside
    | |
    | |
    --official VPN endpoint 4 our customers 1)--| |--- DMZ1
    | |
    | |--- DMZ2
    -VPN coming from 2nd half of company net 2)--| |
    -------

    outside has an IP from 1 provider.
    Don't care about outside and named DMZ interfaces.
    Interface 1) and 2) will have 2 IP of the same IP range from a provider different from the outside one.

    As PIX doesn't permit traffic coming from and going to the same interface, regarding only VPN, it is
    expected to work fine, but my doubts were about using IP belonging to the same I pool but applied to
    different interfaces. Perhaps my doubts should be cut off by the imperative "Are the traffic flowing
    through different interface? - Y... es - OK Don't worry, it will work!".
    I only want to be sure all aspects be considered without leaving off nothing.

    Thanks,

    Alex.
     
    AM, Mar 16, 2005
    #7
    1. Advertising

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. =?Utf-8?B?S2V0YW4u?=

    How to read data from WLAN card directly and bypassing the TCP/IP

    =?Utf-8?B?S2V0YW4u?=, May 2, 2005, in forum: Wireless Networking
    Replies:
    1
    Views:
    1,617
    Carl DaVault [MSFT]
    May 2, 2005
  2. Jeremy McMasters

    bypassing directly connected network

    Jeremy McMasters, Nov 10, 2003, in forum: Cisco
    Replies:
    5
    Views:
    1,670
    Vincent C Jones
    Nov 11, 2003
  3. Joan Arc
    Replies:
    1
    Views:
    583
    Miggsee
    Aug 25, 2003
  4. anthony crowder
    Replies:
    20
    Views:
    2,928
    hhtest
    Jan 16, 2007
  5. ktstzo
    Replies:
    0
    Views:
    580
    ktstzo
    Oct 13, 2009
Loading...

Share This Page