Archive

Archive for the ‘ASA’ Category

Guest wireless access with external DNS while maintaining access to the local DMZ

August 22nd, 2013 No comments

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.

DNSDoctoringNetwork

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 23.60.144.110 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 (8.8.8.8 and 8.8.4.4) 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 23.60.144.110 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
networkobjects
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.
AddObject
Step 4: In the Advanced NAT Settings windows check “Translate DNS replies for rule” and hit OK a couple of times.

AdvancedNATSettings
Step 5: Repeat as necessary for additional Objects.

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.

Categories: ASA, Cisco Tags:

Traffic Policing on the Cisco ASA 5512-X with Priority to Voice Over the VPN

June 28th, 2013 No comments

So,QoSSUCCESS 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:

Problem:

Give voice calling and signaling priority over all other traffic through a VPN over a cable Internet connection thus providing basic QoS.

Solution:

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

 

The Breakdown

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.

 

8071526975_7bc933b835You 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.

Categories: ASA, Cisco Tags: