PIX pickle

Discussion in 'Cisco' started by John Caruso, Dec 12, 2003.

  1. John Caruso

    John Caruso Guest

    I have a multi-interface PIX (running 6.3(3)) controlling a production site.
    The inside interface connects to trusted internal hosts, the web interface
    connects to the frontend network of some web servers, and the mgmt interface
    connects to a backend management network on those same web servers.

    What I want to do is fairly simple:

    1) For all connections from inside to web, use a global pool
    2) For all connections from inside to mgmt, disable translation of the inside
    source addresses (either via nat 0 or NAT exemption)
    3) Allow hosts on the mgmt interface to connect to a static PAT on the PIX's
    interface address that maps to an inside host

    The idea is that accesses to the frontend web addresses need to come back
    through the PIX's web interface, but for connections on the management
    network I'd like to be able to see the actual source addresses.

    Unfortunately there doesn't seem to be any way to accomodate all of these
    requirements. First off, I can't see how to use nat 0 between inside and
    mgmt when I want to also use a numbered NAT (nat 10 in this case) between
    inside and web. The problem is that nat 0 is only based on source address,
    and doesn't require an association with a destination interface (via a global
    pool)...so nat 0 ends up being applied to *all* destination interfaces,
    whereas nat 10 applies between a pair of interfaces (and different interface
    pairings can use different global pools). So there doesn't seem to be any
    way to say "use a global pool from inside to web, but use nat 0 from inside
    to mgmt" using standard nat 0.

    What I really need, then, is a nat 0 that allows specification of destination
    addresses or interface(s). That suggests using NAT exemption, and in fact
    that does most of what I want. BUT, it means that it's now impossible to
    use static PAT to allow hosts on the mgmt network to access hosts on the
    inside network (because NAT exemption is matched prior to static PAT).
    Instead, they have to use the actual IP of the destination system. Which
    is undesirable in this case.

    I could get around this by leaving the one system that needs to be accessed
    via static PAT out of the NAT exemption range, and having it use a global
    to access the mgmt network. But because Cisco decided not to allow (or
    honor) deny statements in NAT exemption access lists, it's very difficult
    to build in an exception for a single IP address. And this is a pretty
    ugly solution in any case, sinc it will require constant maintenance in
    the future as other inside machines need to be accessed from the mgmt network.

    I'm stuck. If there were a way to have regular nat 0 (not NAT exemption)
    apply only between a pair of interfaces rather than to all destinations, I'd
    be home free, and that's really the ideal solution. Is there some way to
    do that that I'm missing? Or if the PIX honored static PAT even when NAT
    exemption is in place (perhaps by virtue of prioritizing static NAT/PAT
    above NAT exemption, which seems to me to make more sense than the current
    design), I'd also be home free. Of course, that's not going to happen.
    Or if the PIX just allowed deny statements in NAT exemption ACLs, I'd at
    least have an only moderately ugly workaround...but no go.

    Any other suggestions for how to do everything I'm trying to do?

    - John
    John Caruso, Dec 12, 2003
    #1
    1. Advertising

  2. John Caruso

    joe Guest

    jesus christ.. talking about shaken' not stirred.. this looks like
    a disaster from the get go (no offense please sir, these dam pixies drive
    me crazy too)

    I would do this.. put your web servers in a security50 interface (this
    is a dmz to the unitiated )...

    Forget NAT 0 statements... use

    static (inside, dmz) 10.0.0.0 255.255.255.0 10.0.0.0 255.255.255.0

    notice the static nat statement keeps the IP the same, this effectively
    turns off nat for the "translation"

    (i'm assuming your using 10.0.0.0 255.255.255.0 on your INSIDE interface)
    if I read you wrong and i'm backwards, just do this..


    static (dmz, inside) 10.0.0.0 255.255.255.0 10.0.0.0 255.255.255.0

    this is the opposite, your now assumed to be using 10.0.0.0 255.255.255.0
    on your dmz interface (for the real ip's of the webservers)..

    now all your one-to-one static nats (for web server dns entries, etc)
    should be based on a LOCAL subnet to the outside (security0) interface.

    The servers in the dmz, will see connections from all the global ip's of the
    internet, the server and inside stuff will also see each other via their
    "real" ip's (without nat happening).. BTW forget the NAT 0 statements,
    ALWAYS, unless your doing VPN with your pixes...

    Let us know what your trying to accomplish.. cut and dry


    John Caruso <> wrote in message news:<>...
    > I have a multi-interface PIX (running 6.3(3)) controlling a production site.
    > The inside interface connects to trusted internal hosts, the web interface
    > connects to the frontend network of some web servers, and the mgmt interface
    > connects to a backend management network on those same web servers.
    >
    > What I want to do is fairly simple:
    >
    > 1) For all connections from inside to web, use a global pool
    > 2) For all connections from inside to mgmt, disable translation of the inside
    > source addresses (either via nat 0 or NAT exemption)
    > 3) Allow hosts on the mgmt interface to connect to a static PAT on the PIX's
    > interface address that maps to an inside host
    >
    > The idea is that accesses to the frontend web addresses need to come back
    > through the PIX's web interface, but for connections on the management
    > network I'd like to be able to see the actual source addresses.
    >
    > Unfortunately there doesn't seem to be any way to accomodate all of these
    > requirements. First off, I can't see how to use nat 0 between inside and
    > mgmt when I want to also use a numbered NAT (nat 10 in this case) between
    > inside and web. The problem is that nat 0 is only based on source address,
    > and doesn't require an association with a destination interface (via a global
    > pool)...so nat 0 ends up being applied to *all* destination interfaces,
    > whereas nat 10 applies between a pair of interfaces (and different interface
    > pairings can use different global pools). So there doesn't seem to be any
    > way to say "use a global pool from inside to web, but use nat 0 from inside
    > to mgmt" using standard nat 0.
    >
    > What I really need, then, is a nat 0 that allows specification of destination
    > addresses or interface(s). That suggests using NAT exemption, and in fact
    > that does most of what I want. BUT, it means that it's now impossible to
    > use static PAT to allow hosts on the mgmt network to access hosts on the
    > inside network (because NAT exemption is matched prior to static PAT).
    > Instead, they have to use the actual IP of the destination system. Which
    > is undesirable in this case.
    >
    > I could get around this by leaving the one system that needs to be accessed
    > via static PAT out of the NAT exemption range, and having it use a global
    > to access the mgmt network. But because Cisco decided not to allow (or
    > honor) deny statements in NAT exemption access lists, it's very difficult
    > to build in an exception for a single IP address. And this is a pretty
    > ugly solution in any case, sinc it will require constant maintenance in
    > the future as other inside machines need to be accessed from the mgmt network.
    >
    > I'm stuck. If there were a way to have regular nat 0 (not NAT exemption)
    > apply only between a pair of interfaces rather than to all destinations, I'd
    > be home free, and that's really the ideal solution. Is there some way to
    > do that that I'm missing? Or if the PIX honored static PAT even when NAT
    > exemption is in place (perhaps by virtue of prioritizing static NAT/PAT
    > above NAT exemption, which seems to me to make more sense than the current
    > design), I'd also be home free. Of course, that's not going to happen.
    > Or if the PIX just allowed deny statements in NAT exemption ACLs, I'd at
    > least have an only moderately ugly workaround...but no go.
    >
    > Any other suggestions for how to do everything I'm trying to do?
    >
    > - John
    joe, Dec 13, 2003
    #2
    1. Advertising

  3. John Caruso

    John Caruso Guest

    In article <>, joe wrote:
    > jesus christ.. talking about shaken' not stirred.. this looks like
    > a disaster from the get go


    Why? The point is just to use a multi-interface PIX as several logical
    firewalls, more or less. Works like a charm. The same config can easily
    be implemented with separate PIXes, but there's no point to it as long as
    the single PIX can handle the load.

    > Forget NAT 0 statements... use
    >
    > static (inside, dmz) 10.0.0.0 255.255.255.0 10.0.0.0 255.255.255.0


    Yes, I ended up settling on a network-wide static like this shortly after
    I posted my email. It does appear to be doing the job, despite the fact
    that the PIX gives warnings for the static PAT entries (because they
    overlap with the static NAT entries), and despite the fact that the PIX
    docs imply that it won't work (they say that static NAT is matched before
    static PAT--which is apparently not the case, since the static PAT entries
    are taking precedence over the static NAT entries in the config I'm using
    now). But if reality and the docs have to conflict, at least they're
    conflicting in my favor, so I'm not going to complain about it.

    > BTW forget the NAT 0 statements,
    > ALWAYS, unless your doing VPN with your pixes...


    Actually the NAT exemption form of nat 0 was very close to what I needed,
    other than the fact that it's prioritized above static PAT.

    > Let us know what your trying to accomplish.. cut and dry


    Just what I said in the original posting; I'm not sure how I could have
    been more specific, short of posting configs. But thanks for the response--
    it does at least verify what I'd settled on.

    - John
    John Caruso, Dec 13, 2003
    #3
    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. Richard

    PIX to PIX to PIX meshed VPN

    Richard, Nov 13, 2003, in forum: Cisco
    Replies:
    1
    Views:
    583
    Richard
    Nov 15, 2003
  2. Remco Bressers
    Replies:
    1
    Views:
    492
    Jyri Korhonen
    Nov 21, 2003
  3. Bill F
    Replies:
    1
    Views:
    417
    Walter Roberson
    Nov 25, 2003
  4. GVB
    Replies:
    1
    Views:
    2,749
    Martin Bilgrav
    Feb 6, 2004
  5. AlanP
    Replies:
    3
    Views:
    915
    Mirek
    Apr 7, 2004
Loading...

Share This Page