Understanding ASA/FW operation

[Trey Grun]

ASA Newbie here.  I couldn't find this exact thread so far - although I saw a number of similar threads.  I understand the role of a FW as a stateful connection monitor, the organization of interfaces into "zones" of varying security levels, and understand how routing and NAT works, so I cannot figure out what I DO NOT understand in terms of basic connectivity through a firewall.  Since I'm emulating functionality via GNS3 I'm only really testing with ICMP right now.  I read that the connectionless nature of ICMP makes it something a firewall can't monitor the state of so that unless a "conduit" (pix language I know) or specific ACL is configured to allow this.  Topologically, I'm having the same basic problem as outlined here: https://supportforums.cisco.com/message/3306478#3306478

I can ping to and from the local fw interfaces, but traffic THROUGH the firewall fails.  My basic config is:

Inside Interface:

ip add 10.0.0.1 255.255.255.0

nameif inside

security-level 0

Outisde Interface:

ip add 192.168.137.2 255.255.255.0

nameif outside

security-level 100

Route:

ip route 0 0 192.168.137.1 1

Nat/Pat:

nat (inside) 1 10.0.0.0 255.255.255.0 (I honestly don't understand the need for the "1" here or in the PAT statement)

global (outside) 1 192.168.137.2

I thought that would've been enough - but apparently not.  I have not tried to implement the solution suggested in the thread I cited, mostly because I'm not sure I understand why those dozen configuration lines would be needed to allow a simple ICMP through the ASA.  That's most important to me.

I got the "IMCP is not monitorable/stateful info from the PIX/ASA handbook, which neglects to offer an easily understandable solution to my issue, and I have not finished going through this link: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aad.shtml#topic2

Which appears to have some suggestions I'd like to try, but really, I was hoping there was a more elegant solution than a dozen line service-policy to allow ICMP replies to known hosts back in through the outside interface.  I'm also interested in confirming the information I read about ICMP.

Thanks in advance for any replies.

[varrao · Accepted solution]

Hi Trey,

Ok let me explain you in detail how this going to work, in case of ICMP:

Lets consider this topo:

router----------------------ASA-----------------------------PC

Now you want to initiate a ping from the PC to the router interface, first thing that you would need is  the NAT statement;

nat (inside) 1 0.0.0.0 0.0.0.0

global (outside) 1 interface  (pat the internal IP's to outside interface of the firewall)

Here '1' is  the nat identifier, it is used to bind the nat statement with a specific global statement, for eg you can also have another nat statement, if you had configured another interface like,

nat (dmz) 2 0.0.0.0 0.0.0.0

global (outside) 2 192.168.2.2

so users behind DMZ should be natted to global statement with identifier 2.

Now second we would need a default route on the ASA, something like:

route outside 0 0 192.168.137.1 1

And the next we would need to allow the icmp return packets on the outside interface, since ICMP is a stateless connection:

access-list out_in extended permit icmp any any

access-list out_in in interface outside   (this means apply the acl for traffic coming into the outside interface)

I guess this is enough to allow ICMP through the firewall.

Moreover have a look at these docs for NAT and basic ASA CLI configuration:

NAT:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008046f31a.shtml

ASA configuration:

http://www.cisco.com/en/US/customer/docs/security/asa/asa82/configuration/guide/config.html

Hope I was able clear your doubts,

Thanks,

Varun

[varrao · Accepted solution]

And yes, as per the thread, to allow the return traffic you can either apply inspect icmp or the ACL.

Varun

[Maykol Rojas]

Hi,

Totallly correct about ALL you said, however it may be simpler that you think. The ASA is able to inspect ICMP messages thru the firewall (keep track of ICMP sessions)  but it is disabled by default.

Something to take in consideration is that is not the ICMP request the one that is being dropped, is the reply, since the ASA did not created an "state session".

In order for the ASA to permit the icmp echo-reply you need one of two things, one the an acl on the outside interface to permit the ICMP echo-reply or the inspection for ICMP.

The ASA firewall has some inspections by default, so the only thing that you need to do is to add the ICMP inspection.

policy-map global_policy

class class-default

     inspect icmp

The only problem is that it wont allow all types of ICMP, it will just allow the ones that have initiated a session and it has a reply (icmp echo, echo-reply) the other ones will be dropped, (time exceeded, unrechable etc).

Here is a very important link that you may read to understand it better.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

Cheers

Mike

[Trey Grun]

Maykol and Varun,

Thank you for your replies!  I was able to get the ACL based reply to work, but not the inspection.  To summ up my topology:

     CLOUD

     /         \

asa1     asa2

    |            |

  R1-serial-R2

    |            |

lans        lans

the idea is to build a site-to-site VPN between the ASAs and use the serial link ONLY for specific traffic (already built a route-map for that) BUT STEP 1 is to validate connectivity to the cloud.

The *simple* thing would be to slap the ACL onto both ASAs to do so and then build my site-to-site VPN, but I would really like to get a death-grip on 2-way icmp communication through these things so I can confidently know when it *should* work in the event I'm at a customer site and some telco or other entity wants to play the "blame the firewall" game.

Any ideas *why* the policy-map may not be working?  here's how it appears in my config:

!

policy-map global_policy

class class-default

  inspect icmp

!

Not much to it!  I'm sure it's a semantic thing I'm over-looking - Thanks!

[Maykol Rojas]

Would you please do a show run service-policy ?

Mike

[Trey Grun]

WH-ASA# show run service-policy

WH-ASA#

no output.  That's wierd.  I assumed the "policy-map global_policy" statement would've established that.  Thanks for the prompt reply!

[Maykol Rojas · Accepted solution]

No issues, that is basically the problem,

do the following on both asa's on config mode,

service-policy global_policy global

[Trey Grun]

Like I said - semantics.  Dead-on - got both methods working now.  What an excellent first exchange in this forum.  Thanks for everything!!!