Sep
14

It was a dark, cold night in late December, and Bob, (the optimistic firewall technician), had a single ASA to deploy before going home for the holidays.  The requirements for the firewall were simple.   Bob read them slowly as follows:

  1. R1 should be able to ping the server “Radio.INE.com” by name.
  2. PC should be able to ping the server “Radio.INE.com” by name.

Bob also read the background information to see if this was something he could finish before leaving the office.   Bob read the following:

DNS Server is mapping radio.ine.com to the global address of 136.1.122.100
All devices have appropriate routes in place.
R1 and the PC are both configured to use the DNS server at 136.1.122.2
DNS Server, PC, R1  and supporting L2 switchports for the ASA are configured correctly.

Bob also looked at the diagram:

Bob's Quick Installation Gone Wrong

Bob's Quick Installation Gone Wrong

Bob put the following together in notepad, and then quickly pasted it into the ASA using Secure CRT:

!************ begin ASA configuration ************

enable

conf  t
clear config all

no nat-control
hostname ASA1
interface Ethernet0/0
nameif outside
ip address 136.1.122.10 255.255.255.0
interface Ethernet0/1
nameif inside
ip address 172.16.16.10 255.255.255.0
interface Ethernet0/2
nameif dmz
ip address 10.0.0.10 255.255.255.0
nat (inside) 1 172.16.16.0 255.255.255.0
nat (dmz) 1 10.0.0.0 255.255.255.0
global (outside) 1 interface
access-list outside permit tcp any host 136.1.122.100 eq www
access-list outside permit icmp any host 136.1.122.100 echo
access-group outside in interface outside
static (dmz,outside) 136.1.122.100 10.0.0.100

wr

!************end ASA configuration*************

After waiting a few moments, Bob went to R1, issued the following command and hoped for the best:

Ping radio.INE.com

The ping failed.    He tried the same ping from the PC which also failed.    As much as Bob “hoped” it would work, it didn’t, and Bob secretly wished he had the skills and knowledge of a Security CCIE that would allow him to quickly solve the configuration problem so he could go home for the holidays.

My fellow CCIE bloggers and INE fans, your mission, should you choose to accept it, is to identify the missing and/or incorrect elements that need to be in place for successful pings to radio.ine.com from the PC and R1.

There is more than 1 way to solve this, and there are between 5 and 7 corrections that need to take place.

Will you assist BOB?


You can leave a response, or trackback from your own site.

40 Responses to “How quickly can you troubleshoot an ASA configuration?”

 
  1. Zak says:

    I think first of all we must add this:

    Firewall(config)# policy-map asa_global_fw_policy
    Firewall(config-pmap)# class inspection_default
    Firewall(config-pmap-c)# inspect icmp

  2. khaleel says:

    nat-control
    hostname ASA1
    interface Ethernet0/0
    nameif outside
    ip address 136.1.122.10 255.255.255.0
    interface Ethernet0/1
    nameif inside
    ip address 172.16.16.10 255.255.255.0
    interface Ethernet0/2
    nameif dmz
    ip address 10.0.0.10 255.255.255.0
    same-security-traffic permit intra-interface

    !
    nat (inside) 1 172.16.16.0 255.255.255.0
    nat (dmz) 1 10.0.0.0 255.255.255.0
    global (outside) 1 interface
    access-list outside permit tcp any host 136.1.122.100 eq www
    access-list outside permit udp any host 136.1.122.100 eq 53
    access-list outside permit icmp any host 136.1.122.100 echo-reply
    access-group outside in interface outside
    static (dmz,outside) 136.1.122.100 10.0.0.100 dns

    wr

    Khaleel (CCIE#23492)

  3. shrek says:

    For the PC to be able to ping radio.INE.com the static translation needs to be:

    same-security-traffic permit inter-interface
    static (dmz,outside) 136.1.122.100 10.0.0.100 dns

    for R1 to be able to ping radio.INE.com
    access-list dmz_in permit icmp host 10.0.0.100 any echo-reply
    access-group dmz_in in interface dmz

  4. Rizzo says:

    Mr. Bob let help you. :)

    Just did in notepad and didn’t verify it.

    hostname ASA1
    interface Ethernet0/0
    nameif outside
    ip address 136.1.122.10 255.255.255.0
    security-level 0
    no shut

    interface Ethernet0/1
    nameif inside
    ip address 172.16.16.10 255.255.255.0
    security-level 100
    no shut

    interface Ethernet0/2
    nameif dmz
    ip address 10.0.0.10 255.255.255.0
    security-level 50
    no shut

    domain-name INE.com
    dns domain-lookup outside

    nat-control

    nat (inside) 1 172.16.16.0 255.255.255.0
    nat (dmz) 1 10.0.0.0 255.255.255.0
    global (outside) 1 interface

    static (dmz,outside) 136.1.122.100 10.0.0.100

    access-list outside permit tcp any host 136.1.122.100 eq www
    access-list outside permit tcp any host 136.1.122.100 eq dns
    access-list outside permit icmp any host 136.1.122.100 echo
    access-group outside in interface outside

  5. Tim Rowley says:

    *Forgot the dns keyword on the static NAT
    *The outside acl is not allowing the echo-reply, add a rule or add icmp inspection
    *Dont need the 1st ACE, this is permitted because of the state table
    *Need a static (i,o) 136.1.122.100 10.0.0.100 dns
    interfaces need a no shut if this is a new install, sounds like it is
    *nameif dmz will yield a sec level of 0, perhaps he could use the same-security-traffic inter-interface cmd to allow traffic between dmz and outside
    *In all actuality the outside ACL is not needed, the first line doesnt do anything and the 2nd can be permitted via icmp inspect. This whole ACL can be removed and applied to the inside interface to limit outbound activity

  6. Puneet says:

    a) No security levels define so DMZ takes sec. level of 0.
    b) Access list should refer to echo reply not echo (if ping is required to check connectivity to DNS). In addition need to permit DNS traffic for DMZ (as they share same sec levels.)
    c) No access-list assigned to DMZ (if sec level is 0) which means no pingy pingy :) !! (unless icmp is inspected in global policy)
    d) If DMZ and Outside have the same security level, we need the same security inter interface command or define different security levels.

    Ok back to work now :P

  7. Tacack says:

    Ok here’s what i think are the changes to be made :

    Firstly, we need to make sure the NATting is perfect.
    Bob’s already configured NAT for traffic going from inside-> outside, dmz -> Outside. But he has’nt configured NAT from inside->dmz. This is required if R1 wants to ping “Radio.INE.com”

    So BoB has to add this line to his config :

    “nat (inside) 2 172.16.16.0 255.255.255.0
    global (dmz) 2 interface”
    ———————————————–
    Bob has to permit icmp replies going from the dmz to the inside network, so he has to add an ACL called “DMZ” and apply it on the inbound direction on the dmz interface.

    “#access-list dmz permit icmp host 10.0.0.100 any echo-reply
    #access-group dmz in interface dmz”

    ———————————————-
    Next since we’re performing a DNS query to server located on the outside network, let’s make sure that DNS traffic is permitted back in. So BOB Has to update the “outside” ACL and add this ACE to it.

    “#access-list outside permit udp host 136.1.12.2 any eq dns”
    ———————————————–
    Now, there’s a small problem. The DNS server will return the IP address of “Radio.INE.com” as the outside address, which should be changed to the dmz address of 10.0.0.100. So BOB has to perform “DNS-DOCTORING” by adding these line

    “#static (dmz,outside) 10.0.0.100 136.1.122.100 dns”

    ———————————————–

    Please let me know if they’re right or wrong? :)

  8. Tacack says:

    Sorry i got the DNS-DOCTORING ACL reversed
    it’s actually
    “#static (dmz,outside) 136.1.122.100 10.0.0.100 dns”

  9. Tacack says:

    And another thing,

    DMZ and OUTSIDE are at the same security level,
    so one needs to either change the security levels or add

    “#same-security-traffic permit inter-interface”

    on the ASA.

  10. Tacack says:

    OK, i’m almost rambling at this point, but are the routes from R1 to DNS server configured already?

  11. Malick Ndiaye says:

    Well I am a CCIE R&S student but not a CCIE Security student, but I will give it a shot.

    I think Bob forgot to permit DNS resolutions from going through the firewall and back.R1 is not permitted to get to the DNS server.

    Just my 2 cents

  12. Kelvin Dam says:

    Bob needs to perform DNS Doctoring.

    His access-list outside is fine, but he needs to add the keyword “dns” to the static command:

    static (dmz,outside) 136.1.122.100 10.0.0.100 dns

    Further more – make sure that the global inspection rule, has dns up for inspection, as per. default :

    policy-map type inspect dns preset_dns_map
    parameters
    message-length maximum 512
    policy-map global_policy
    class inspection_default
    inspect dns preset_dns_map

    :-)

    /Kelvin

  13. Razvan says:

    First of all Bob has to place a security level on the DMZ interface because by default it has a security level of 0, after it was named. Second the static command needs the DNS parameter so that the ASA will translate the DNZ reply from the server.Third we have to enable ICMP inspection in ASA. Fourth we should add a global command for traffic coming from inside and going to DMZ: global (dmz) 1 interface. I think this is it, i tested it in GNS3.

  14. Toshi says:

    Do we have to allow “echo-reply” back from DMZ to inside zone?

  15. NTllect says:

    Bob should read several topics about PIX/ASA configuration, such as:

    1) DNS-doctoring;
    2) the difference between ‘nat-control’ and ‘no nat-control’ commands;
    3) type of icmp messages and security-levels;

  16. cisco says:

    We need to do some changes like–

    1. Need to configure acl that permit icmp (echo & reply) from inside to dmz and apply it to the dmz interface
    2. Need to add dns keyword to resolve the name i.e. static (dmz,outside) 136.1.122.100 10.0.0.100 dns

  17. rraussie says:

    Here is my shot!

    I supose Bob left all the default settings, so dmz and outside should both have sec level 0.

    same-security-traffic permit inter-interface
    !
    static (dmz,outside) 136.1.122.100 10.0.0.100 netmask 255.255.255.255 dns
    !
    class-map inspection_default
    match default-inspection-traffic
    !
    policy-map global_policy
    class inspection_default
    inspect dns
    !
    service-policy global_policy global

  18. The Evil Muffin says:

    policy-map global_policy
    class inspection_default
    inspect icmp

    same-security-traffic permit inter-interface

    static (dmz,outside) 136.1.122.100 10.0.0.100 netmask 255.255.255.255 dns

    global (dmz) 1 10.0.0.50

  19. yohon says:

    This is great. These sort of troubleshooting scenarios (especially someone else’s network) really enforce concepts learned at INE.

    I will take a stab at it but would like to know if we should post the answers here or e-mail them in to you.

    Thanks and keep up the great work!

  20. HAT says:

    The problem is ASA does not translate the IP address in DNS payload. To correct, put these commands to ASA:

    - alias (dmz) 10.0.0.100 136.1.122.100 255.255.255.255
    - alias (inside) 10.0.0.100 136.1.122.100 255.255.255.255
    or
    - static (dmz,outside) 136.1.122.100 10.0.0.100 dns

  21. HAT says:

    Also need to enable nat-control

  22. Barooq says:

    In short the following has to be done

    Method 1:
    Use static with dns key word to doctor the dns A record to 10.0.0.100

    static (dmz,outside) 136.1.122.100 10.0.0.100 dns netmask 255.255.255.255
    Allow icmp recho-reply on dmz interface or allow icmp inspection in firewall

    Method 2:
    Use alias command to doctor the DNS entry instead of static and again the acl to permit icmp from dmz to inside.
    alias (dmz) 10.0.0.100 136.1.122.100 255.255.255.255

    alias (inside) 10.0.0.100 136.1.122.100 255.255.255.255

    And of course ACL on DMZ

    Method 3:
    Hairpinning:
    1) same-security-traffic permit intra-interface (Enables Hairpinning and redirection on interface)
    2) static (dmz,dmz) 136.1.122.100 10.0.0.100
    3)static (dmz,inside) 136.1.122.100 10.0.0.100

    And ofcourse ACL on dmz :)

  23. Mohammed Gazzaz says:

    Here is what I did to help Bob
    ——————————-

    interface Ethernet0/0
    nameif outside
    security-level 0
    ip address 136.1.122.10 255.255.255.0
    !
    interface Ethernet0/1
    nameif inside
    security-level 100
    ip address 172.16.16.10 255.255.255.0
    !
    interface Ethernet0/2
    nameif dmz
    security-level 50
    ip address 10.0.0.10 255.255.255.0

    static (inside,dmz) 172.16.16.1 172.16.16.1 netmask 255.255.255.255

    static (dmz,outside) 136.1.122.100 10.0.0.100 netmask 255.255.255.255 dns

    policy-map global_policy
    class inspection_default
    inspect icmp

  24. Mike Heider says:

    conf t
    nat-control
    interface Ethernet0/2
    security-level 10
    no static (dmz,outside) 136.1.122.100 10.0.0.100
    static (dmz,outside) 136.1.122.100 10.0.0.100
    netmask 255.255.255.255 dns
    access-list dmz-access-in permit icmp any any echo-reply ! Redundant to the next ACE but you get the point.
    access-list dmz-access-in permit ip any any
    access-group dmz-access-in in interface dmz
    access-list NoNAT permit ip 172.16.16.0 255.255.255.0 10.0.0.0 255.255.255.0
    nat (inside) 0 access-list NoNAT
    clear xlate
    wr mem

  25. Thank you so much for all the great ideas. I know Bob would be grateful too, and would have wanted your knowledge BEFORE he threw in that configuration.

    Below is one set of solutions that Bob could use to solve the configuration:

    1: Bring up the interfaces.
    2: ICMP inspection needs to be added, OR echo reply allowed inbound on outside interface.
    3: DNS keyword added to the static for the radio.ine.com server
    4: global (dmz) 1 interface for translation from inside to dmz
    5: same-security-traffic permit inter-interface so that traffic may flow between dmz and outside.

    Thanks to all for your ideas, comments and feedback. YOU ROCK!

    Would you like to see more scenarios in the blog in this same format?

    Let me know and thanks again.

  26. mg says:

    Hi,

    Why you add a global nat ?

    4: global (dmz) 1 interface for translation from inside to dmz

    When nat-control is disabled the translation is not needed :)

  27. NTllect says:

    Yes, we would like to see more challenges, especially with prizes such as Amazon-gifts and INE tokens for the first 3 winners ;)

  28. Dani Petrov says:

    Absolutely! I think these methods of teaching are very useful and creative!

    Kind regards,
    Dani

  29. Mohammed Gazzaz says:

    Yes, Please.

  30. Bilal says:

    It was really interesting and informative. Keep the good work

  31. Bilal says:

    Send few more like this

  32. yohon says:

    Please do bring on more challenges like this. These are great learning exercises. I know that the Route/Switch track got a troubleshooting module/bootcamp and was wondering if the security track would get something like this as well. Even though it is not in the lab exam, these troubleshooting scenarios go along way to understanding the technologies.

    Great work and we look forward to more of you scenarios!

  33. Hello mg-

    Great question of:

    Why did you add a global nat ?
    4: global (dmz) 1 interface for translation from inside to dmz
    When nat-control is disabled the translation is not needed

    Because we have nat (inside) 1 172.16.16.0 255.255.255.0 we are committed to nat for the inside network of 172.16.16.0

    Without the global to the dmz interface, R1 would not be able to reach radio.ine.com

    Thanks.

  34. Sachin says:

    I think we all are missing a very basic requirement.

    When we have opened ICMP or echo reply we do not need to inspect icmp

    With DNS doctoring we always need to inspect DNS

    policy-map global_policy
    class inspection_default
    inspect dns

  35. Sachin says:

    Here is the complete configuration you need.

    hostname ASA1
    interface Ethernet0/0
    nameif outside
    ip address 136.1.122.10 255.255.255.0
    security-level 0
    no shut

    interface Ethernet0/1
    nameif inside
    ip address 172.16.16.10 255.255.255.0
    security-level 100
    no shut

    interface Ethernet0/2
    nameif dmz
    ip address 10.0.0.10 255.255.255.0
    security-level 50
    no shut

    access-list outside permit tcp any host 136.1.122.100 eq www
    access-list outside permit tcp any host 136.1.122.100 eq dns
    access-list outside permit icmp any host 136.1.122.100 echo
    access-group outside in interface outside

    global (outside) 1 interface
    nat (inside) 1 172.16.16.0 255.255.255.0
    static (inside,dmz) 172.16.16.0 172.16.16.0 netmask 255.255.255.0
    static (dmz,outside) 136.1.122.100 10.0.0.100 netmask 255.255.255.255 dns

    policy-map type inspect dns MY_DNS_INSPECT_MAP
    parameters
    message-length maximum 512
    inspect dns MY_DNS_INSPECT_MAP

    Regards,
    Sachin
    svaish@cisco.com :)

  36. CCIE_India says:

    HI,

    THe DNS Server IP is 136.1.122.2 used by the PC and R1

    Access-llist to be permited to this for DNS
    <<>>

    This will help PC & R1 to resolve the IP from the DNS server for server.

    Rest all config by Bob is fine.

  37. [...] smiled to himself as he remembered how much he has learned about the technologies of  DMVPN, the ASA Firewall and IPSec, including GET [...]

  38. wharley says:

    Great stuff…Please can you set up how a traceroute can be permited throught an ASA without using an ACCESS-LIST

    Regards,

    Wale

 

Leave a Reply

Categories

CCIE Bloggers