PIX VPN-VPN thru same interface

Discussion in 'Cisco' started by Odhammar, Nov 4, 2003.

  1. Odhammar

    Odhammar Guest

    We have a lot branchoffices connected to our headquarter with VPN thru
    PIX'es, now are there people that want's to have access to their home office
    when they are visiting another office.

    All branchoffices are connected to the same PIX (515 with v6.1) at our
    headquarter, so the traffic should go in and out in the same interface on
    the 515, is this possible?
    Odhammar, Nov 4, 2003
    1. Advertisements

  2. Odhammar

    Ivan Ostres Guest

    I'm not sure, but I think that I red somewhere that same traffic on PIX
    can't go both ways on single interface.

    Ivan Ostres, Nov 4, 2003
    1. Advertisements

  3. Odhammar

    Odhammar Guest

    I found this in another question, so maybe it doesn't work:
    How about VLAN's in a PIX I saw something about that on CISCO.com?
    Odhammar, Nov 4, 2003
  4. Odhammar

    Ivan Ostres Guest

    Nice, I was right... :)

    VLAN's are assumed as logical interfaces, so it could work...

    Ivan Ostres, Nov 4, 2003
  5. you need to configure fully meshed VPN tunnels, inorder to accomplish what
    you what to do.

    Martin Bilgrav
    Martin Bilgrav, Nov 4, 2003
  6. Just like that... No. PIX doesn't allow same traffic coming in and
    going out through same interface. If access to home office is like
    web or something, then maybe setting proxy behind PIX would solve
    this problem. Otherwise, I think it would work with VLAN's (PIX 6.3 if
    I remember right), but I didn't have much time lately to try something
    like that so I'm not sure. But even with VLANs, PIX supports usually
    6 interfaces, which is all well, if you have 2 or 3 offices around,
    but if you have 50 offices around then you can forget about it.
    Support - IP/VoIP Connectivity & Routing
    Primoz Jeroncic tel: +386 1 562 31 40 |
    Borovec 2 fax: +386 1 562 18 55 | 1 + 1 = 3
    1236 Trzin | for larger values of 1
    Slovenija http://www.softnet.si/primoz
    Primoz Jeroncic, Nov 4, 2003
  7. :> PIX is designed so that when a packet comes in one [logical] interface,
    :> then the packet can never go out the same [logical] interface, even if
    :> the original packet was encapsulated.

    Yup, that applies to this situation as well.

    :How about VLAN's in a PIX I saw something about that on CISCO.com?

    Effectively the VLANs give you more interfaces. That's not aways
    enough. Each interface has to be in different subnet. If you have
    enough address space that you can subnet it, then you could use
    one logical interface as the peer point for the site-to-site VPNs,
    and a different logical interface as the peer point for the
    VPN clients. [Assuming you aren't using a PIX 501, 506, or 506e,
    none of which support VLANs.]
    Walter Roberson, Nov 4, 2003
  8. Odhammar

    Bob Watson Guest

    Yes you can do this the pix isnt recieving the same traffic in and out
    of the interface. Remember same principle applies to HUB and SPoke VPN
    design on the PIX FW.
    Bob Watson, Nov 5, 2003
  9. Odhammar

    Bob Watson Guest

    Bob Watson, Nov 5, 2003
  10. :To expand remember that the pix will strip the IPSEC header and decrypt
    :the packet before deciding what to do with it once it sees the
    :destination is another IPSEC peer it will rewrap the packet thereby
    :bypassing the law of packets will nopt reroute in and out of the same

    I'm sure you are wrong.

    I haven't nailed down the entire sequence of events, but it
    starts pretty close to this:

    PIX will receive the IPSec packet, and will immediately attach an
    internal flag indicating the source interface. It will then decapsulate
    leaving the flag intact [0], and setting a flag indicating IPSec source. [1]
    The result is a packet marked with an interface and an IPSec source
    flag. The next step is to look at the destination IP to determine the
    destination interface, and record that with the packet. If the source
    and destination interfaces are the same, it drops the packet with no
    syslog [2]. If the source and destination interfaces are different, it
    notes the relative security levels, and then examines the translation
    tables and makes note of the applicable translation [3]. If no valid
    translation is found, it drops the packet with a log message. Then
    more processing takes place.

    [0] packets that can't be decapsulated generate log messages
    no matter what their inner contents are

    [1] The IPSec-source flag will later be checked in conjunction
    with sysopt connection permit-ipsec to determine whether to skip
    ACL checking.

    [2] We know this happens before the translation is checked because
    there can never be a valid translation from an interface to itself,
    and we know the same-interface packets generate no message instead
    of a translation-failure message.

    [3] I have to work more on the exact processing order near here for
    the case that the destination is IPSec encapsulated.

    The problem with the processing you propose is that IPSec can be NAT'd,
    but NAT depends on the source and destination interface security
    levels. In the case where the source and destination levels are the same,
    the PIX documentation says the packet will be discarded. In order
    for a packet to be rewrapped such as you propose, a new security level
    would have to be lent to the packet so as not to invoke the
    rule about always discarding if the security levels are the same. But
    *what* new level should be lent? If you lend a higher security level
    then you nat one one; if you lend a lower security level then you
    nat a different way [you nat source when going to a lower level,
    and you nat destination when going to a higher level.] Your proposed
    ordering is thus inconsistant with known PIX behaviour.
    Walter Roberson, Nov 6, 2003
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.