PIX to PIX tunnel and a VPN Client

Discussion in 'Cisco' started by Kirk Goins, Nov 4, 2003.

  1. Kirk Goins

    Kirk Goins Guest

    I've got 2 pix 501's talking via a pix to pix vpn. Apps can talk across
    the tunnel just fine. see below.

    192.168.1.0/24 -PIX1- publicIP <> publicIP -PIX2- 192.168.2.0

    Now what I need to do is use the Cisco VPN Client, access say PIX1 and
    access devices on either net (1.x or 2.x). I can access PIX1 and see 1.x
    devices or I can access PIX2 and see 2.x devices but not the other net
    at the same time.

    I know I'm missing something easy... Help...

    Thanks in advance
    Kirk Goins, Nov 4, 2003
    #1
    1. Advertising

  2. In article <>,
    Kirk Goins <> wrote:
    :I've got 2 pix 501's talking via a pix to pix vpn. Apps can talk across
    :the tunnel just fine. see below.

    :192.168.1.0/24 -PIX1- publicIP <> publicIP -PIX2- 192.168.2.0

    :Now what I need to do is use the Cisco VPN Client, access say PIX1 and
    :access devices on either net (1.x or 2.x). I can access PIX1 and see 1.x
    :devices or I can access PIX2 and see 2.x devices but not the other net
    :at the same time.

    :I know I'm missing something easy... Help...

    You cannot do what you want with the PIX 501.

    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.

    Thus, if somewhere on the net, you have a PC that forms an IPSec
    tunnel to PIX1, the IPSec packets would be received by the
    outside interface of PIX1, and PIX1 would refuse to send the
    packet out over the outside interface to reach PIX2.

    There is no way to convince the PIX to violate this constraint.
    The closest that you can get is that on the PIX 515 and upwards,
    you can configure multiple VLANs on the same physical interface,
    and the PIX -will- allow you to forward between different VLANs.
    VLANs are not available on the PIX 501, PIX 506, or PIX 506E.
    --
    100% of all human deaths occur within 100 miles of Earth.
    Walter Roberson, Nov 4, 2003
    #2
    1. Advertising

  3. Kirk Goins

    Andre Beck Guest

    Kirk Goins <> writes:
    > I've got 2 pix 501's talking via a pix to pix vpn. Apps can talk
    > across the tunnel just fine. see below.
    >
    > 192.168.1.0/24 -PIX1- publicIP <> publicIP -PIX2- 192.168.2.0
    >
    > Now what I need to do is use the Cisco VPN Client, access say PIX1 and
    > access devices on either net (1.x or 2.x). I can access PIX1 and see
    > 1.x devices or I can access PIX2 and see 2.x devices but not the other
    > net at the same time.


    Welcome to that problem. You are not the first there...

    > I know I'm missing something easy... Help...


    You're missing the famous "The PIX is *not* a router" statement. What
    this is trying to say is that the PIX is a NAT engine with some
    limited abilities to take part in the usual IP forwarding decisions
    and packet forwarding, but it does this in quite a different way than
    what you would expect - especially if you know IP and routers well.

    We can argue whether this behavior is a security feature or just a
    design flaw. I tend to the latter, as this is *always* dropping onto
    your foot after deploying a PIX-based VPN...

    --
    The _S_anta _C_laus _O_peration
    or "how to turn a complete illusion into a neverending money source"

    -> Andre "ABPSoft" Beck +++ ABP-RIPE +++ Dresden, Germany, Spacetime <-
    Andre Beck, Nov 9, 2003
    #3
  4. In article <>, Andre Beck <> wrote:
    :You're missing the famous "The PIX is *not* a router" statement.

    A PIX joins Layer 2 broadcast domains at Layer 3. Therefore, it
    *is* a router, by definition.

    It just isn't very flexible in policy routing or routing protocols.
    --
    csh is bad drugs.
    Walter Roberson, Nov 9, 2003
    #4
  5. Kirk Goins

    Andre Beck Guest

    -cnrc.gc.ca (Walter Roberson) writes:
    > In article <>, Andre Beck <> wrote:
    > :You're missing the famous "The PIX is *not* a router" statement.
    >
    > A PIX joins Layer 2 broadcast domains at Layer 3. Therefore, it
    > *is* a router, by definition.


    This held true before the invention of NAT. After that, there are devices
    which do not route, but must translate. NAT can be an extension to a
    router (as in IOS), or it can be unrelated to the actual forwarding.
    The PIX uses the latter concept and the famous sentence, that probably
    should be read "Don't mix up the PIX with the routers you might know",
    was repeatedly uttered to me at Cisco trainings.

    > It just isn't very flexible in policy routing or routing protocols.


    I could excuse both, as there are tons of other routers that have the
    same problem, but still qualify as routers. The problem of the PIX is
    that it fails to *just* *route* (that means forward) according to a
    routing table. For a long time, it couldn't route at all, later that
    was partially worked around by introduction of "nat 0". But anyway,
    a device that fails to do one-armed routing to me is no router.

    --
    The _S_anta _C_laus _O_peration
    or "how to turn a complete illusion into a neverending money source"

    -> Andre "ABPSoft" Beck +++ ABP-RIPE +++ Dresden, Germany, Spacetime <-
    Andre Beck, Nov 12, 2003
    #5
  6. In article <>, Andre Beck <> wrote:
    |-cnrc.gc.ca (Walter Roberson) writes:
    |> In article <>, Andre Beck <> wrote:
    |> :You're missing the famous "The PIX is *not* a router" statement.

    |> A PIX joins Layer 2 broadcast domains at Layer 3. Therefore, it
    |> *is* a router, by definition.

    |This held true before the invention of NAT.

    |> It just isn't very flexible in policy routing or routing protocols.

    |I could excuse both, as there are tons of other routers that have the
    |same problem, but still qualify as routers. The problem of the PIX is
    |that it fails to *just* *route* (that means forward) according to a
    |routing table. For a long time, it couldn't route at all, later that
    |was partially worked around by introduction of "nat 0".

    For a long time?? "nat 0" has existed since PIX 3.0,
    http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v3/pix_ug/pixugcmd.htm#xtocid42

    That was at some point in 1996, with Cisco only having purchased
    NTI in October 1995, at which time 2.7 was the current release.
    NTI was founded in 1994, so the lack of "nat 0" was *at most* 3 years
    (probably closer to 2), and it's been more than 7 years since then.

    The oldest Usenet message that I can see with your name on it that
    mentions PIX is from 1999,
    http://groups.google.ca/groups?selm=

    When, I wonder, did you start using PIX?
    --
    'ignorandus (Latin): "deserving not to be known"'
    -- Journal of Self-Referentialism
    Walter Roberson, Nov 13, 2003
    #6
  7. Kirk Goins

    Andre Beck Guest

    -cnrc.gc.ca (Walter Roberson) writes:
    > In article <>, Andre Beck <> wrote:
    > |-cnrc.gc.ca (Walter Roberson) writes:
    > |> In article <>, Andre Beck <> wrote:
    > |> :You're missing the famous "The PIX is *not* a router" statement.
    >
    > |> A PIX joins Layer 2 broadcast domains at Layer 3. Therefore, it
    > |> *is* a router, by definition.
    >
    > |This held true before the invention of NAT.
    >
    > |> It just isn't very flexible in policy routing or routing protocols.
    >
    > |I could excuse both, as there are tons of other routers that have the
    > |same problem, but still qualify as routers. The problem of the PIX is
    > |that it fails to *just* *route* (that means forward) according to a
    > |routing table. For a long time, it couldn't route at all, later that
    > |was partially worked around by introduction of "nat 0".
    >
    > For a long time?? "nat 0" has existed since PIX 3.0,
    > http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v3/pix_ug/pixugcmd.htm#xtocid42
    >
    > That was at some point in 1996, with Cisco only having purchased
    > NTI in October 1995, at which time 2.7 was the current release.
    > NTI was founded in 1994, so the lack of "nat 0" was *at most* 3 years
    > (probably closer to 2), and it's been more than 7 years since then.


    Ok, but was "nat 0" already as flexible at this time as it is today?
    It was my impression that the original reason to introduce "nat 0" on
    the PIX was to actually allow for VPN, in allowing traffic to enter
    a tunnel without translating it somehow.

    > The oldest Usenet message that I can see with your name on it that
    > mentions PIX is from 1999,
    > http://groups.google.ca/groups?selm=


    That old? Interesting. Seemed to be mostly name dropping, though ;)

    > When, I wonder, did you start using PIX?


    IIRC approximately a year later. And I've only had partial contact, as
    there are colleagues who know these boxes better. But what I was repeatedly
    told both by others who know these boxes and by Cisco folks, and what I have
    seen myself confing some of these boxes was, they behave significantly
    different from any other FW that I had contact with before. Those others
    where either hosts with proxies on them, or they were basically routers
    with a more or less sophisticated set of filters that could prevent some
    of the packets from beeing routed. When NAT came to the arena (IIRC some
    time around '95), it was either irrelevant with proxies or was implemented
    as an extension to routing on all the other boxes. The PIX is designed the
    other way around, it lives best with a set of explicit translations and it
    is a pain (and partially impossible) to let it just forward packets as one
    would expect of a device that is named "router". You may see this different,
    and you do have an argument, but I had to find my peace with the PIX by
    not allowing myself to mix them up with routers. Thus, in a number of
    cases, I prefer an IOS based router with FW feature set - it is very close
    to the PIXes filter philosophy, but it doesn't try to force me further
    away from the router paradigm than I'd like to be dragged.

    --
    The _S_anta _C_laus _O_peration
    or "how to turn a complete illusion into a neverending money source"

    -> Andre "ABPSoft" Beck +++ ABP-RIPE +++ Dresden, Germany, Spacetime <-
    Andre Beck, Nov 13, 2003
    #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. Martin Nowles
    Replies:
    0
    Views:
    1,011
    Martin Nowles
    Nov 10, 2003
  2. a.nonny mouse
    Replies:
    2
    Views:
    1,066
  3. Tim Fortea
    Replies:
    2
    Views:
    983
  4. Trouble
    Replies:
    0
    Views:
    563
    Trouble
    Aug 4, 2006
  5. Trouble
    Replies:
    1
    Views:
    513
Loading...

Share This Page