PIX question Policy NAT - quite urgent -

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

  1. AM

    AM Guest

    I am over the same question.
    The reference is the following article

    http://www.cisco.com/en/US/products..._guide_chapter09186a0080172786.html#wp1113601

    section Policy NAT

    What does it mean that access list for policy NAT can note have DENY statements?

    I thought to create two complementary ACL for a pool of addresses and ports and for the rest of the world using DENY
    statements but the specifications don't allow me to do that.

    Perhaps do the nat ids become important, I mean, they represent the order which ACL are processed with?

    Briefly, I have built a VPN to a remote site, say VPN_remote_IP; I have 2 interface on the Internet with 2 IPs,
    4_Internet IP and VPN__IP. I have published the mail server on the outside interface (packets coming from and going to
    it pass through outside interface)

    Following the article suggestions I wish create

    access-list 2VPN-Endpoints permit tcp 192.168.4.0 255.255.255.0 VPN_remote_IP 255.255.255.255 eq 500
    access-list 2VPN-Endpoints permit tcp 192.168.4.0 255.255.255.0 VPN_remote_IP 255.255.255.255 eq 4500
    access-list 2VPN-Endpoints permit tcp 192.168.4.0 255.255.255.0 VPN_remote_IP 255.255.255.255 eq 5000

    access-list 2WEB permit ip 192.168.4.0 255.255.255.0 0.0.0.0 0.0.0.0

    and applying them in the following order

    nat (inside) 1 access-list 2VPN-Endpoints
    nat (inside) 2 access-list 2WEB

    global (outside) 1 <1 1st public IP> 255.255.255.255
    global (outside) 2 <2 2nd public IP> 255.255.255.255


    The question is:

    as told above, is it correct or have nat Ids numbers priority meaning so putting the 2VPNendpoint at the top of the
    translation process let the IPsec packets to be translated by the 1st IP and all of the rest of the packets by the 2nd
    IP? I needn't a deny statement at the bottom of the 1st access list, do I?

    The article doesn't talk about a PIX with 2 interface on the Internet side.
    What is your opinion?
    Any comments are welcomed,

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

  2. In article <ANjYd.7713$>, AM <> wrote:
    :What does it mean that access list for policy NAT can note have DENY statements?

    Just that -- they don't allow deny statements in those ACLs.


    :I thought to create two complementary ACL for a pool of addresses and ports and for the rest of the world using DENY
    :statements but the specifications don't allow me to do that.

    :perhaps do the nat ids become important, I mean, they represent the order which ACL are processed with?

    No, the nat id's have *no* significance other than the special value 0 and the fact that they act as groupings.
    No prioritization of any sort is implied.

    Policy nat is matched "in order, until the first match". That means literally in the order that the
    nat statements occur in your configuration.


    :Following the article suggestions I wish create

    :and applying them in the following order

    :nat (inside) 1 access-list 2VPN-Endpoints
    :nat (inside) 2 access-list 2WEB

    :The question is:

    :as told above, is it correct or have nat Ids numbers priority meaning so putting the 2VPNendpoint at the top of the
    :translation process let the IPsec packets to be translated by the 1st IP and all of the rest of the packets by the 2nd
    :IP? I needn't a deny statement at the bottom of the 1st access list, do I?

    No prioritization by nat id (but nat 0 access-list is always first): 2VPN-Endpoints will be used first
    because that's the first one in your configuration. If you had

    nat (inside) 2 access-list 2WEB
    nat (inside) 1 access-list 2VPN-Endpoints

    then 2WEB would be evaluated first because that would be the first one in the configuration.
    --
    "No one has the right to destroy another person's belief by
    demanding empirical evidence." -- Ann Landers
     
    Walter Roberson, Mar 11, 2005
    #2
    1. Advertising

  3. AM

    AM Guest

    Walter Roberson wrote:
    > In article <ANjYd.7713$>, AM <> wrote:
    > :What does it mean that access list for policy NAT can note have DENY statements?
    >
    > Just that -- they don't allow deny statements in those ACLs.
    >
    >
    > :I thought to create two complementary ACL for a pool of addresses and ports and for the rest of the world using DENY
    > :statements but the specifications don't allow me to do that.
    >
    > :perhaps do the nat ids become important, I mean, they represent the order which ACL are processed with?
    >
    > No, the nat id's have *no* significance other than the special value 0 and the fact that they act as groupings.
    > No prioritization of any sort is implied.
    >
    > Policy nat is matched "in order, until the first match". That means literally in the order that the
    > nat statements occur in your configuration.
    >
    >
    > :Following the article suggestions I wish create
    >
    > :and applying them in the following order
    >
    > :nat (inside) 1 access-list 2VPN-Endpoints
    > :nat (inside) 2 access-list 2WEB
    >
    > :The question is:
    >
    > :as told above, is it correct or have nat Ids numbers priority meaning so putting the 2VPNendpoint at the top of the
    > :translation process let the IPsec packets to be translated by the 1st IP and all of the rest of the packets by the 2nd
    > :IP? I needn't a deny statement at the bottom of the 1st access list, do I?
    >
    > No prioritization by nat id (but nat 0 access-list is always first): 2VPN-Endpoints will be used first
    > because that's the first one in your configuration. If you had
    >
    > nat (inside) 2 access-list 2WEB
    > nat (inside) 1 access-list 2VPN-Endpoints
    >
    > then 2WEB would be evaluated first because that would be the first one in the configuration.


    Thanks Walter, but how to invert, or better, how to specify order for nat. I haven't tried still now but can I specify
    the line as in commands for access-lists? I will try, but if you know please let me know. Thanks,

    Alex.
     
    AM, Mar 15, 2005
    #3
  4. AM

    AM Guest

    AM wrote:


    > Thanks Walter, but how to invert, or better, how to specify order for
    > nat. I haven't tried still now but can I specify the line as in commands
    > for access-lists? I will try, but if you know please let me know. Thanks,
    >
    > Alex.


    Perhaps removing all NATs and inserting new ones in wanted order? :)

    Alex.
     
    AM, Mar 15, 2005
    #4
  5. In article <DZwZd.14379$>, AM <> wrote:
    :AM wrote:
    :> Thanks Walter, but how to invert, or better, how to specify order for
    :> nat. I haven't tried still now but can I specify the line as in commands
    :> for access-lists? I will try, but if you know please let me know. Thanks,

    :perhaps removing all NATs and inserting new ones in wanted order? :)

    Exactly. Either that or redefine the meaning of the access-lists ;-)
    --
    "[...] it's all part of one's right to be publicly stupid." -- Dave Smey
     
    Walter Roberson, Mar 15, 2005
    #5
    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. Oleg Tipisov

    PIX Policy NAT: order of NAT commands

    Oleg Tipisov, Aug 12, 2004, in forum: Cisco
    Replies:
    4
    Views:
    8,952
    Walter Roberson
    Aug 13, 2004
  2. wtpandar

    policy nat and static NAt

    wtpandar, Sep 12, 2006, in forum: Cisco
    Replies:
    0
    Views:
    913
    wtpandar
    Sep 12, 2006
  3. Security Advisory

    !!URGENT!! Tor Vulnerability Discovered !!URGENT!!

    Security Advisory, Aug 6, 2007, in forum: Computer Security
    Replies:
    1
    Views:
    989
    http://tinyurl.com/23k3dt@$NIFF-deeply.ahh
    Aug 11, 2007
  4. pooja
    Replies:
    0
    Views:
    1,212
    pooja
    Mar 3, 2009
  5. Griffin
    Replies:
    0
    Views:
    656
    Griffin
    Aug 27, 2010
Loading...

Share This Page