Introduction to Firewalls

(Rene Molenaar) #1

This topic is to discuss the following lesson:

(Wisam A) #2

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.

(Rene Molenaar) #3

Hi @wisamani,

Glad to hear you like it. I am also trying some “whiteboard” videos on my surface pro like the one in the SDN article:

Do you think those are just as good or still prefer the real whiteboard videos?


(Wisam A) #4

Thanks Rene for your reply, this video is very good, but honestly I am seeing your videos on the white board is much better. They are very strong, very clear and easy to understand.
Thanks for your amazing classes Rene. I just passed CCNP switch.

(Rene Molenaar) #5

Thanks for your input Wisam, and grats for passing the SWITCH exam!

(Satish K) #6

I really enjoyed this lesson. Thanks Rene for making this so easy to understand! I have a question though.

  1. What is NGFW and how it is different from the regular ones e.g. the one discussed in the lesson.
  2. Also Would be helpful if you guide to some resource on DPI (deep Packet Inspection) firewalls.

Also I Prefer this mode of presentation coz i feel more focussed this way. Whiteboard does not look so neat and also my focus shifts when you move during the video. Just my bit of feedback :slight_smile:
Thank you!

(Rene Molenaar) #7

Hi @Satish,

Thanks for your feedback. I also prefer the desktop recording, it’s more convenient than a whiteboard that requires cleaning and it’s easier to record from my desk :smile:

Laz wrote about the differences between “regular” firewalls and NGFWs awhile ago:

I’ll see if I can write some more about DPI in the future.

(Michael R) #8

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?

(Lazaros Agapides) #9

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!


(Juan C) #10

taking in mind this excerpt from this lesson:

“To ensure traffic from the OUTSIDE is able to reach the servers in the DMZ, we will use an access-list that only permits traffic to the IP address (and port numbers) that the servers in the DMZ use.”

Where you have to configure the ACL ? i mean, if i want to permit a specific public ip addr to have connectivity to a mail server behind the firewall, i could configure an ACL to permit this public ip addr, but where the ACL has to be located ?

(Lazaros Agapides) #11

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!


1 Like
(Suman R) #12

Hi I want to know how how ASA FW does packet inspection on encrypted packet? If browser is using https to access something how ASA does deep packet inspection?

(Lazaros Agapides) #13

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!


(Tin Marlar O) #14


if don’t have the Hardware,how to practice ASA firewall?


(Lazaros Agapides) #15

Hello Tin

The ASA is available on the GNS3 platform. Take a look at this information from the GNS3 site that details how to get the ASA working on their platform.

I hope this has been helpful!