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:
- R1 should be able to ping the server “Radio.INE.com” by name.
- 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 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?
About Keith Barker, CCIE #6783:
Keith Barker excelled as a Network Engineer beginning in 1986 with EDS. Before opting for a career in IT Education, Keith’s practical experience culminated with the position of IT Manager for Paramount Pictures. Once joining the field of IT Education, Keith became a top-rated Microsoft and Cisco Certified Instructor. Keith Barker, along with Jeremy Cioara and Anthony Sequeira helped to make KnowledgeNet, the most respected Online IT Training organization of its time. You will find Keith Barker in Live Classroom, Live Online, and Self-Paced Route/Switch and Security classes here at INE.
You can leave a response, or trackback from your own site.
39 Responses to “How quickly can you troubleshoot an ASA configuration?”
Leave a Reply

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
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)
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
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
*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
a) No security levels define so DMZ takes sec. level of 0.
!! (unless icmp is inspected in global policy)
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
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
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?
Sorry i got the DNS-DOCTORING ACL reversed
it’s actually
“#static (dmz,outside) 136.1.122.100 10.0.0.100 dns”
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.
OK, i’m almost rambling at this point, but are the routes from R1 to DNS server configured already?
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
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
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.
Do we have to allow “echo-reply” back from DMZ to inside zone?
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;
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
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
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
This is great Keith. 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!
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
Also need to enable nat-control
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
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
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
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,
Keith
Yes, we would like to see more challenges, especially with prizes such as Amazon-gifts and INE tokens for the first 3 winners
Hi Keith,
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
Absolutely! I think these methods of teaching are very useful and creative!
Kind regards,
Dani
Yes, Please.
THANKS
Hell yes Keith!
It was really interesting and informative. Keep the good work
Send few more like this
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!
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,
Keith
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
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
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.
[...] smiled to himself as he remembered how much he has learned about the technologies of DMVPN, the ASA Firewall and IPSec, including GET [...]