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 126.96.36.199 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 (188.8.131.52 and 184.108.40.206) 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 220.127.116.11 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.