Hey guys and gals, I wanted to give you a heads up that most of my networking related posts have now shifted to my new website HackAndTinker.net. Hack and Tinker is completely focused on what I am terming Network Adventuring. What is Network Adventuring, you ask? Network Adventuring is a term coined by our team to describe one’s desire to learn as much as possible about the inner workings of computer networks. This can be anything from network security, to pen testing, network configuration, server setup and web development. PhilipStraatsma.com will remain for now, but at some point I may refocus it into something else or even just redirect it to Hack And Tinker. So, stop on over to the HAT website and check out what we have going on and let me know what you think.
Every network administrator has heard this question from their users before, “why does guest wireless access not work like my connection at home?”. What they really mean is “why can’t I access all of InsertYourCompany’sName external websites/webmail when I am on the quest wireless network?”. Typically our guest networks share the same internet connection/outside ASA interface as our DMZ and internal networks do forcing us to segregate the networks. This is typically done on the ASA where all these networks “terminate” and the NAT translation is done out to the internet.
The simplest way to segregate your three networks is to set the DMZ network to the lowest security level of the three (50 for this example), set the guest wireless network security level a bit higher (70 for this example) and internal to the highest possible (100). This allows internal and guest clients access to the DMZ network while keeping hosts on the guest and DMZ network from accessing the internal network creating a basic security barrier. This is where things begin to get problematic. Typically we would assign our guest clients our internal DNS servers so they can resolve our DMZ servers via their private DMZ address. However, besides the general security problems of our guest clients having access to our internal DNS servers the guest clients can also be subject to the problem of split-horizon DNS. Split-horizon DNS is often used by companies to grant additional access for internal clients to web resources or pointing them at internal private server vlans while presenting outside clients DMZ servers! For example, as a employee on-site I might go to CorpWebSalesServer and the DNS entry would send me to 10.100.0.120 but, if I am an outside customer connecting to CorpWebSalesServer from home I would be given 184.108.40.206 address in response to my DNS query. So, in order for our clients on guest wireless to access CorpWebSalesServer (remember they are technically internal clients) they would need to have access to our internal servers instead of our DMZ, which creates a massive security hole. To solve this you could simply set the guest clients to an external DNS server such as Google’s public DNS (220.127.116.11 and 18.104.22.168) and because the guest network is a lower security level they would not be able to access our internal networks, just the DMZ and Internet. However, this too creates a problem. Google, will return the public IP address of the DMZ web server back to the guest client which then tries to access the web server by its public IP address. By default the Cisco ASA will not allow packet redirection on the same interface (outside) which is tried by the guest client trying to access the DMZ server by its NAT’d public IP address. There is however an awesome solution to this. DNS doctoring.
DNS doctoring intercepts the return response for the outside DNS server and converts it to a private DMZ IP address accessible by the guest client. For example, a guest client wants to get to YourCorp’s web server and asks Google’s DNS server for its IP address. The IP address returned by Google for YourCorp is 22.214.171.124 which hits the firewall on its way back to the guest client. The firewall sees the public IP address in the response and promptly replaces it with the private DMZ address of YourCorp, 10.50.0.110. The guest client now knows that YourCorp is at 10.50.0.110 and happily able to access the server.
DNS doctoring is supported on the Cisco ASA firewall and is very simple to setup.
Step 1: Pour yourself some Dark Horse Raspberry Ale, great summer beer that goes down a little too easy.
Step 2: Load up the good ‘ole ASDM Select Configuration -> Firewall -> Objects ->Network Objects/Groups
Step 3: Double click on the Network Object for the server in question to edit it and click on the NAT header to expand the Object window and click the Advanced button.
Step 4: In the Advanced NAT Settings windows check “Translate DNS replies for rule” and hit OK a couple of times.
Step 6: That’s it, sit back, enjoy your Dark Horse Ale while the ASA does all the doctoring work for you.
Pro-tip: Just remember to limit access to 80 and 443 from the guest network to the DMZ network for web access only, you don’t want any guest users attempting to RDP to your DMZ boxes.
So, I wrote this whole boring intro paragraph on my goals for this post, a back story on the problem, something about the cloud and encryption… But, I decided it was junk, scrapped it and came up with a simple breakdown of the problem:
Give voice calling and signaling priority over all other traffic through a VPN over a cable Internet connection thus providing basic QoS.
My first thought was to go with a packet shaping solution however, I found the commands for shaping we strangely missing from my 5512-x. I scoured the internet for information on why the commands were missing and even upgraded to the latest version of 9 code thinking it was a function added to newer code but came up empty handed. Finally, I contacted TAC about the issue and was informed that multiprocessor units like the 5512-x do not support traffic shaping. Odd thing, the 5512-x only has one processor…
CiscoASA# show ver <---output omited for brevity---> Hardware: ASA5512, 4096 MB RAM, CPU Clarkdale 2792 MHz, 1 CPU (2 cores)
Maybe the tech meant traffic shaping is not supported on multiple processors and multicore processors or the ASA software sees multiple cores like multiple processors like Windows, who knows. Supposedly the tech was going to have this caveat regarding shaping on the 5512-x added to Cisco configuration articles so others will not run into the same problem as I, but as of yet has not been added to the Cisco ASA QoS configuration guide.
With packet shaping not an option I began looking at packet policing and what it can offer me in granting voice priority. After digging around a bit I discovered an excellent article on the Cisco support forums and below is what I came up with. We will be applying the QoS policy to the outside interface as this is really the only interface that we care to (or can) dictate the priority in which traffic is allowed through.
ASA(config)# priority-queue outside
ASA(config)# access-list tcp-traffic-acl permit tcp any any ASA(config)# class-map tcp-traffic-class ASA(config-cmap)# match access-list tcp-traffic-acl
ASA(config)# class-map vpn-voice-class ASA(config-cmap)# match tunnel-group your-tunnel-group ASA(config-cmap)# match dscp ef cs3 af31
ASA(config-cmap)# class-map vpn-rest-class ASA(config-cmap)# match tunnel-group your-tunnel-group ASA(config-cmap)# match flow ip destination-address
ASA(config)# policy-map police-priority-policy ASA(config-pmap)# class tcp-traffic-class ASA(config-pmap-c)# police output 3000000 ASA(config-pmap-c)# class vpn-voice-class ASA(config-pmap-c)# priority ASA(config-pmap-c)# class vpn-rest-class ASA(config-pmap-c)# police output 3000000 ASA(config-pmap-c)# class class-default ASA(config-pmap-c)# police output 1000000
ASA(config-pmap-c)# service-policy police-priority-policy interface outside
This configuration is based on a 8Mbps transmit speed. Now let’s take a look at the important adjustable fields that you may need to tweak for your setup.
ASA(config-cmap)# match tunnel-group your-tunnel-group
First up, matching your tunnel group, whenever you see ASA(config-cmap)# match tunnel-group your-tunnel-group make sure you enter the name of your tunnel group that is handling your vpn in place of your-tunnel-group.
ASA(config)# class-map vpn-voice-class ASA(config-cmap)# match dscp ef cs3 af31 ASA(config-cmap)# match tunnel-group your-tunnel-group
Next up we want to match the voice traffic and in my case voice signaling so that we can differentiate voice traffic from everything else. ASA(config)# class-map vpn-voice-class creates the class map for voice and ASA(config-cmap)# match dscp ef cs3 af31 matches voice calls and signaling marked by your router before it hits the ASA. Notice that we are also matching only voice traffic over the VPN with this command, ASA(config-cmap)# match tunnel-group your-tunnel-group.
ASA(config)# policy-map police-priority-policy ASA(config-pmap)# class tcp-traffic-class ASA(config-pmap-c)# police output 3000000 ASA(config-pmap-c)# class vpn-voice-class ASA(config-pmap-c)# priority ASA(config-pmap-c)# class vpn-rest-class ASA(config-pmap-c)# police output 3000000 ASA(config-pmap-c)# class class-default ASA(config-pmap-c)# police output 1000000 ASA(config-pmap-c)# service-policy police-priority-policy interface outside
Continuing on we want to set voice and voice signaling as priority and police the output of all other traffic. To start we will need to create a policy map, ASA(config)# policy-map police-priority-policy and then begin to select the traffic we want to police. First up we want to limit non-vpn tcp so udp traffic is not overrun by someone downloading a large file. We use the class map we created earlier and limit it to 3000000 bps with the following commands ASA(config-pmap)# class tcp-traffic-class and ASA(config-pmap-c)# police output 3000000. Next we are going to give voice priority on the interface, ASA(config-pmap-c)# class vpn-voice-class and ASA(config-pmap-c)# priority. If you notice we go not provide a bps limit to voice, instead voice is simply given priority over all traffic and if you do your math you will notice that there is 1000000 bps left of the initial 8000000. Next we want to limit non-voice traffic on the VPN to 3000000 bps using these commands ASA(config-pmap-c)# class vpn-rest-class and ASA(config-pmap-c)# police output 3000000. And, lastly we will limit everything left over that is not tcp, voice or vpn to 1000000 with ASA(config-pmap-c)# class class-default and ASA(config-pmap-c)# police output 1000000. The final step is to apply the service policy to the outside interface with this command ASA(config-pmap-c)# service-policy police-priority-policy interface outside.
You may have noticed something that may seem somewhat off in this configuration, in which case if you did, good job and let me explain myself. First off 3000000 bps + 3000000 bps +1000000 bps + 1000000 bps does not actually = 8 Mbps, it is actually more like 7.62 Mbps. I intentionally used incorrect numbers for a few reasons. Number one, round numbers, such as 3000000 are much easier to read then 3145728 when trying to comprehend this solution. And secondly cable connections like the one I am policing for above are notoriously all over the place when it comes to actual throughput and I like to give myself a little breathing room, better to err on the low side then the high side I say.
I started my foray into the Cisco ASA about a few months ago as my job started to spill into the network security arena. Similar to the way I felt when I began to learn about Cisco Routers and Switches, I feel a bit like a fish out of water when it comes to the ASA. So I decided that a bottom up approach to learning the ASA platform was needed starting with the basics of an ASA firewall.
The Cisco ASA firewall is known as a stateful firewall. A stateful firewall only permits packets that match an existing rule on the firewall through from one network to another. Once permitted the firewall adds the connection to a state table and any additional traffic matching the entry with the same source and destination is allowed to quickly pass. In a real life scenario you are typically protecting your internal network from the dangers of the Internet. As a result most companies setup their rules to allow connections to be initiated from hosts on the internal network out to the Internet while denying most (if not all) connections from being initiated from the Internet to the internal corporate network. For those devices such as web servers and Internet facing application servers that need to allow hosts outside of the internal network to initiate a connection, companies will setup a segregated section of their network called the DMZ. The DMZ however is not left wide open and unprotected to the Internet; administrators will typically setup rules that only allow specific traffic through, like port 80 and 443 traffic on a web server.
This brings us to specifically how the ASA manages security between different networks. The ASA uses something called network security levels. Network Security levels use the numbers 0 to 100 that are assigned to interfaces on the ASA. 0 is considered the least secure and is typically assigned to the Internet facing interface, 100 is considered the most secure and is typically assigned to the internal network. The idea behind the differing security levels is that traffic is allowed by default to initiate connections from a higher level security zone to a lower level security zone but not vice versa. So, for example an inside network with the security level of 100 can initiate connections to the outside network with the security level of 0 however, the outside network cannot initiate a connection to the inside network. Additional networks can be added with any security level between 100 and 0 including, for example the DMZ network. Most companies will assign a number below 100 to their DMZ, typically 50, because they want the DMZ to have a higher security level than the Internet, but not as high as the inside network. This Allows the DMZ to open connections to the internet but not back to the inside network yet this still allows the inside network to open connections to both the DMZ and the outside.
The concept of security levels work well if you don’t want to allow any traffic from the outside to any hosts on the inside/DMZ and if you want to allow all traffic unfiltered from the inside/DMZ out. However, there are many cases such as the example of a web server I used above when you want to allow traffic from the Internet to a protected network, like your DMZ. You can allow traffic from the outside in by creating access control lists (ACL) that allow specific traffic through, like port 80 and port 443 for web traffic while denying all other traffic. Additionally you can block specific traffic from the inside out using an ACL as well. Many companies will block traffic from the inside out for things like file sharing applications, instant message clients and network ports used by popular viruses.
Thanks for reading; part 2 will be a beginner’s step-by-step guide to setting up the ASA.
If you ever have the need to recovered a pre-shared key from a Cisco ASA it is not as simple as it is on a router. Sadly simply issuing the show run command only presents you with a line of *****.
ASA_Firewall# show running-config
!– Output Omited
tunnel-group 10.1.1.1 type ipsec-l2l
tunnel-group 10.1.1.1 general-attributes
tunnel-group 10.1.1.1 ipsec-attributes
ikev1 pre-shared-key *****
!– Output Omited
Fortunately there is an easy way around this albeit not a extremely obvious one. To show the clear-text version of the pre-shared key simply issue the more system:running-config command and scroll down to the location of the key in your config and voila, unencrypted pre-shared key.
ASA_Firewall# more system:running-config
!– Output Omited
tunnel-group 10.1.1.1 type ipsec-l2l
tunnel-group 10.1.1.1 general-attributes
tunnel-group 10.1.1.1 ipsec-attributes
ikev1 pre-shared-key MySecretKey
!– Output Omited
This past week I learned a valuable lesson about upgrading the IOS to a newer version on a cisco switch. Always specify the location (flash: in my case) of the image before the image name when using the boot system imagename command.
For some reason I entered the command boot system c2950-i6q4l2-mz.121-6.EA2c.bin into the configuration for the switch I was upgrading to a new version of the IOS I had just copied over, forgetting the location of the image, in this case flash:. I then saved the configuration and rebooted the switch, which of course failed to come back up. When I consoled into the switch I was presented with the following error message upon reboot:
Loading “c2950-i6q4l2-mz.121-6.EA2c.bin”…c2950-i6q4l2-mz.121-6.EA2c.bin: permission denied
Error loading “c2950-i6q4l2-mz.121-6.EA2c.bin”
Interrupt within 5 seconds to abort boot process.
Boot process failed…
The system is unable to boot automatically. The BOOT
environment variable needs to be set to a bootable
To correct the problem you need to enter the boot flash:image-name.bin (substituting image-name with the actual name of the IOS file you wish to boot to) while in rommon and the switch will reload into the IOS image you specify. If you are unsure of the name of the image you need to boot into simply issue a dir flash: command while in rommon, this will give you a list of all the files located in flash.
Once back into the IOS, login and enter exec mode command boot system flash:image-name.bin, again substituting image-name with the name of the IOS file in flash you want to use. Save the config and you are good to go.
Since passing the CCNA exam last year I am frequently asked what resources and study methods I used to pass the exam. So a couple of days ago I sat down and began compiling a guide using the methods that I used to pass the ICND1 and ICND2 exams. I am planning on this being a living document to be updated and sorted for ease of use.
Recommended CCNA Exam Resources:
-CCENT/CCNA ICND1 Official Exam Cert Guide – Odom
-CCNA ICND2 Official Exam Cert Guide – Odom
-Boson Practice Exam Environment – included with Odom books
-Cisco Packet Tracer
-Experienced Network Engineer Mentor
I passed the ICND1 exam and ICND2 exam last year and found the ICND1 exam to be easier than the ICND2 exam. That being said it could have been because I spent less time studying for the ICND2 exam. Looking back I would recommend spending more time on the ICND2 exam than the ICND1 exam given the sheet amount of new concepts it covers.
I would start with CBT Nuggets, it really helps you get excited about the exams and used to the material. Plus Jeremy really helps translate the information you will learn into practical everyday uses.
I read both books twice, the second time taking notes in a physical notebook. This is extremely time consuming but it really helps you pick up the small things you missed the first time around. The trick is to write down all the small details about everything, these are the things you will get hung up on in the exams. By the end of my ICND2 studying I ended up with 140 pages of hand written notes. Also, the book does not cover everything on the exam so I recommend finding a mentor who has taken the exams before that you can bounce questions off of. My mentor especially enjoyed this process as it made him think about and recall things he had not thought about in a while. If you do not have a mentor available you may want to look into picking up another CCNA study book.
Cisco Packet tracer is a router and switch simulator that is totally sufficient for the ICND1 and ICND2 exams as long as you know how to use it. Fortunately, there are a multitude of videos on youtube on how to setup things like frame relay that are not necessarily clear.
It took me a total of 7 months to pass both the ICND1 and ICND2 exams with a one week break between the exams. I would study during my lunch breaks and at night on weekdays and roughly 4 hours a day during the weekends. Two weeks out from the exam I studied every available waking minute. If you are working full time always schedule the exam for a Monday morning, which will give you the entire weekend to cram your head full of the small details. For the ICND2 I woke up early on Monday and ran through the practice exam questions that came with the book just to get into the right frame of mind for answering the actual questions during the exam.
As soon as you start taking the exam brain dump the numbers needed for your mental subnet calculator to the dry erase board given to you. After that take a deep breath and don’t stress out. Take your time but don’t go too slowly through the questions and remember that you cannot go back. Make sure you read the questions and all answers through at least twice and double check your answer selection before hitting next. If you get hung up on a multiple guess question, move on you, will want all the time you can for the simulation questions.
Some people may say this is overkill, but I know I am not the world’s best test taker and I wanted the information to stick well beyond the test date. In the end I posted very high scores on each exam which adds an additional bit of satisfaction to passing each exam.
After you pass the ICND1 exam, frame your certification and hang it above your desk. Every time you see your CCENT certification you will be remind of your success and it will give you a goal of replacing it with the full CCNA certification.
Good luck and enjoy the studying!
Here are the basic steps to configure SSH on your Cisco Router including a few optional steps.
Rt1Lab(config)#ip domain-name lab.local
Rt1Lab(config)#crypto key generate rsa
The name for the keys will be: Rt1Lab.lab.local
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.
How many bits in the modulus : 1024
% Generating 1024 bit RSA keys, keys will be non-exportable…[OK]
Rt1Lab(config)#ip ssh authentication-retries 3 (optional, sets the number of bad login retries before disconnection)
Rt1Lab(config)#ip ssh time-out 60 (optional, sets the negotiation time in seconds which includes the time you have to enter the username and password at the login prompt before you get disconnected)
Rt1Lab(config)#username fred password cisco
Rt1Lab(config)#line vty 0 4
Rt1Lab(config-line)#transport input ssh
Rt1Lab(config-line)#exec-timeout 30 (optional, sets the idle time before disconnect from the VTY lines)
Simply a must learn for any CCNA candidate. When time is your enemy on the exam this method is your best friend: