Tags:


Notable Replies

  1. Thanks Rene for your introduction to firewall.
    just a friendly feedback, I like a lot your videos when you use the White Board in person with your colored pens, It’s amazing, please keep using it. I feel like I am sitting in a real classroom.

  2. Hi, quick question regarding the service policy placement on the ASA, not including global because that’s pretty self explanatory. I created just a simple topology where the ASA was in the middle and has 2 routers on either side, the outside interface had a security level of 0 and inside 100, the outside interface is also blocking all traffic coming in. I implemented NAT on the ASA as well to change the inside network IP’s to the outside interface.

    My policy map inspects ICMP and i applied it to a service policy that was placed on the inside interface, i tested it and everything worked as it should. NAT worked and allowed the traffic back into the inside network, the outside router could not ping the outside ASA interface IP and any inside network addresses. So everything is fine there. The same was done for the outside interface and the same behaviour was present.

    My main question is then, how does the traffic get back through when the service policy is placed on the inside interface, when the class map matches ICMP then the inspection is applied on the policy map and the service policy is assigned to the inside interface, so the source IP would be the private IP of the host on the inside network, it then goes through NAT where NAT changes the source IP to the outside IP, when the return traffic comes back then it comes back with a destination address of the ASA outside IP but the dynamic ACL return traffic is for the destination address of the private IP, so how does it get through when there is no ACL for the traffic coming into the outside interface?

    This is different from assigning the service policy on the outside where the dynamic ACL is the outside IP as the destination which can then be allowed and then the NAT binding table can direct traffic along it’s merry way.

    Does anyone know the answer to this?

  3. Hello Michael

    First of all, we apologise for the late response. This is an excellent question, and thank you for sharing it with us.

    It all has to do with order of operations. The standard document that is usually provided for order of operations regarding NAT is the following:


    Based on this, the inside to outside and outside to inside orders are different. This means that when the traffic returns, it first goes through a NAT outside to inside translation and then goes through the policy routing, in which your policy maps are included. So the policy routing will take place after the NAT translation. So to answer this question:

    … is that first the NAT translation occurs, then the policy routing which is based on the ACL which contains the internal IP address, that is, the translated IP address of the host in question.

    I hope this has been helpful!

    Laz

  4. Hello Juan

    Keep in mind that traffic from a lower security level to a higher security level is denied by default. In general, a DMZ will have a higher security level than the outside interface, so in order to go against this default behaviour, an access list which will permit such traffic must be applied.

    Now the ACL itself is defined globally using the well-known access list syntax. Once it is defined, you must then apply it to an interface specifying an in our outbound direction. You can find out more information about how to apply access lists on an ASA at the following lesson:


    For your specific question, you must create an ACL that permits the destination IP address and port of the server in the DMZ and apply it to the outside interface on an inbound direction. In the above lesson, Rene describes just such an example in the section titled Permit Traffic to DMZ.

    I hope this has been helpful!

    Laz

  5. Hello Suman

    HTTPS filtering is not supported on ASA due to the fact that HTTPS content is encrypted. So no deep packet inspection can be applied. This is according to the following Cisco documentation:

    I hope this has been helpful!

    Laz

Continue the discussion forum.networklessons.com

9 more replies!

Participants