We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 588 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

319 New Members signed up the last 30 days!

satisfaction-guaranteed

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hi Rene,

    one question regarding the “Restrict Outbound Traffic” scenario.

    If the ASA would NAT here and we would work with src ip in the ACL statement, we would have to specify the NAT IP address in the SRC part, right?
    As the packet is routed and NAT´d first before the ACL is applied, right? If we go from “inside” to “outside”.

    Thanks
    Florian

  2. Hi Rene,

    a question regarding those statements:

    •When you create an ACL statement for inbound traffic (lower to higher security level) then the destination IP address has to be: ◦The translated address for any ASA version before 8.3.
    ◦The real address for ASA 8.3 and newer.

    •The access-list is always checked before NAT translation.

    If the ACL is checked first, does the dest IP not have to be the NAT´d IP then?
    Cause the ASA looks at the packet and compares it to the ACL. In the packet we still have the NAT´d IP and therefore we would need to specify the NAT´d IP in the ACL, or not?
    Cause otherwise the ACL wouldn’t match the packet!?

    Thanks
    Florian

  3. Hello Florian

    According to Cisco:

    Although the syntax of the ACLs haven’t changed much (just added capabilities for new objects), the significant change is that all IP addresses listed in ACLs which are applied to an interface will be converted (on upgrade) from using global (ie: translated or post-NAT) IP addresses, to using the real IP address.

    This means that in all cases the real address must be used for post ASA 8.3 versions.

    The comment that:

    The access-list is always checked before NAT translation

    is the case for all ACLs that function with NAT EXCEPT for the case of ACL statement for inbound traffic.

    I hope this has been helpful!

    Laz

  4. Hi Laz,

    thanks again for your reply.

    So this means in either case we will always use the REAL IP address for the ACL statement.
    As you mentioned before that we will always use the REAL IP address for post 8.3. versions and that for INBOUND traffic NAT is performed first and thus we will need the REAL IP address in the ACL statement.
    Is that correct?

    But my first question was regarding the “Restrict Outbound Traffic” scenario.
    Here the ACL was placed on the on the OUTSIDE interface outbound and thats why I thought that you would need to use the NAT´d IP address in the ACL statement as the traffic will hit the ingress interface INSIDE, then will be NAT´d and then will hit the OUTSIDE interface with the ACL attached to it, which means the IP has changed already.
    I think I didn’t make myself clear before, hope its better now.

    Thanks for your help in advance!
    Florian

  5. Hello florian

    In the restrict outbound traffic scenario, the IP address that is used to match the access list is the 192.168.2.2 address. This is the FastEthernet 0/0 interface of R2. This is an external IP address and does not actually get translated at all. The ALL_OUTBOUND access list only matches destination IP addresses for packets going from the INSIDE or DMZ ports to the OUTSIDE port. Again, this destination address will not be translated therefore the criteria for which the matching takes place does not change.

    I’m not sure if I’ve misunderstood your question or if I’ve answered it satisfactorily. Please let me know and if you need any clarifications, feel free to respond.

    I hope this has been helpful!

    Laz

28 more replies! Ask a question or join the discussion by visiting our Community Forum