cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
571
Views
0
Helpful
3
Replies

ASA behavior

JeromeTechie1
Level 1
Level 1

Hello people,

so i am setting a lab up and i am trying to go a little deeper on ASA default behavior. As far as i know by default ASA has a default access list permitting Any IP traffic from higher to lower security level interface. Default global inspection rule allowing the configured protocol to come back in.

I deleted the default inspection rule and configured some PAT rule. Basically traffic should be able to go out and not back in.

I am turning NTP on one of my Inside router and while i expect Time request to go out I dont expect them to come back in since there is no inspection rule configured

Turning on wireshark i see both NTP request and replies on the OUTSIDE Link from ASA to Outside NTP source. I turn on logging message (debugging level) on ASDM and there nothing get denied, i get curious i check NTP time and association on my downstream router boom synchronized...

Anyone can explain to me how that stupid packet comes back in with no Service Policy Configured???

Thanks for those who take some time to answer

1 Accepted Solution

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Here's what the Cisco documentation says about the "inspect" configurations

Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports.

Your test with the NTP and it working doesnt really depend on having the "inspect" configurations. The return traffic for it is allowed because there is a existing connection and xlate since the ASA has already allowed the connection to form. As the ASA is a statefull device it will then know to let the return traffic through the "outside" interface as it has already allowed the connection once.

The most typical "inspect" uses I run into when configuring ASAs are

  • inspect ftp
    • Helps with FTP connection forming since after the Control channel has been opened the Data channel might be using random ports and its also a totally new connection.
  • inspect icmp
    • Automatically allows ICMP echo reply messages through the firewall wihtout having to open them in the interface ACLs. This is NOT enabled by default
  • inspect esmtp, inspect sip, inspect h323
    • Sometimes need to be removed as they actually prevent the mentioned traffic through the firewall

So the "inspect"s configured dont really prevent traffic from getting through your firewall. They are meant to (to my understanding) get around problems with some applications passing through the firewall but also sometimes enforce certain rules for traffic.

So even if you have no "inspect" configured the ASA should to my understanding rely on the xlate/connection table to see what traffic it should allow back through the firewall (return traffic)

So if you are using only "security-level" values on interfaces to control traffic flow then everything is allowed from High Security to Low Security interface and the return traffic is also allowed. Some applications might not work if they are dependant on the "inspect" configuration being there

If you want to enforce a more strict access policy then you need to use ACLs on the ASA interfaces.

Hopefully the information was helpfull

- Jouni

View solution in original post

3 Replies 3

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

Here's what the Cisco documentation says about the "inspect" configurations

Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports.

Your test with the NTP and it working doesnt really depend on having the "inspect" configurations. The return traffic for it is allowed because there is a existing connection and xlate since the ASA has already allowed the connection to form. As the ASA is a statefull device it will then know to let the return traffic through the "outside" interface as it has already allowed the connection once.

The most typical "inspect" uses I run into when configuring ASAs are

  • inspect ftp
    • Helps with FTP connection forming since after the Control channel has been opened the Data channel might be using random ports and its also a totally new connection.
  • inspect icmp
    • Automatically allows ICMP echo reply messages through the firewall wihtout having to open them in the interface ACLs. This is NOT enabled by default
  • inspect esmtp, inspect sip, inspect h323
    • Sometimes need to be removed as they actually prevent the mentioned traffic through the firewall

So the "inspect"s configured dont really prevent traffic from getting through your firewall. They are meant to (to my understanding) get around problems with some applications passing through the firewall but also sometimes enforce certain rules for traffic.

So even if you have no "inspect" configured the ASA should to my understanding rely on the xlate/connection table to see what traffic it should allow back through the firewall (return traffic)

So if you are using only "security-level" values on interfaces to control traffic flow then everything is allowed from High Security to Low Security interface and the return traffic is also allowed. Some applications might not work if they are dependant on the "inspect" configuration being there

If you want to enforce a more strict access policy then you need to use ACLs on the ASA interfaces.

Hopefully the information was helpfull

- Jouni

Thanks a lot,

This was really helpful actually. SO default ASA behavior is Stateful. I had actually some hard time understanding the difference in logic between the ASA and ZBF. to allow return traffic ZBF needs the protocol or port to be inspected (if i got it right) while ASA with default behavior will statefully allow it back in.

So yes according to your explanation if you want to control what comes back you need control what comes out in the first place. Was not rly clear in the Official Firewall Book, you just made it clearer to me.

Priceless

If you want to read a bit more on the ASA (while doing configurations) I would suggest getting the Configuration Guide and Command Reference for the ASA software you are running (shown with "show version" command on the CLI)

You can either navigate through the Cisco site to find these or simply Google for

  • ASA Configuration Guide
  • ASA Command Rererence

You can usually download them as PDF files. I always keep both on my desktop for quick reference. There are also other document like System Log messages that give a little more explanation on the log messages you might be seing. But to be honest in some/many cases they are simply "cryptic" or dont help at all.

Configuration Guide will provide you with the some basic configurations on the ASA. It will also provide background information related to all the configurations and how the ASA operates.

Command Reference is a good thing to check when you want to know what a certain command does and what parameters are available in some command (Though it can be really confusing especially with the new NAT commands)

Otherwise you are probably better of trying to find specific guides online to configure what you need. If you can't find it you can always try out these forums and see if someone can point you in the right direction

- Jouni

Review Cisco Networking for a $25 gift card