Cisco ASA DNS doctoring/Guest wireless with external DNS

Recently, I setup a guest wireless network with external DNS. Clients were able to browse the Internet fine however, they were not able to access my company’s website. The problem I was facing was the external DNS was providing me with a public IP address to access my website. Technically I am an internal client within the network. I could change my host file and it would all work well but this was not a solution. I then came across the below website which introduced me to DNS doctoring.

By default, the Cisco ASA does not allow packets to return on the same interface it went out on. DNS doctoring allows the ASA to rewrite DNS A-records. DNS doctoring intercepts a return response from the outside DNS server and converts it to a private IP accessible by the guest client. Cisco states that DNS inspection must be enabled to perform DNS doctoring on the Cisco ASA.

For this to work, edit the required NAT statement and select the advanced button. In the Advanced NAT settings, select ‘Translate DNS replies for rule.’ You should now be able to browse to your company website using the guest wireless configured for external DNS.

Cisco ASA VPN logs

In order for a VPN connection to establish the IPSec Connection Profile must match exactly and is case-sensitive. Whilst trying to troubleshoot a recent VPN connection, from the client I would hit connect however, the connection would soon fail and the Cisco client logs didn’t give me much information.

When I checked the Cisco ASA logs this is what displayed:

Phase 1 failure:  Mismatched attribute types for class Group Description:  Rcv’d: Group 2  Cfg’d: Group 5

Group = DefaultRAGroup, IP = x.x.x.x, constructing ISAKMP SA payload

Group = DefaultRAGroup, IP = x.x.x.x, Received an un-encrypted INVALID_HASH_INFO notify message, dropping

Group = DefaultRAGroup, IP = x.x.x.x, Error, peer has indicated that something is wrong with our message.  This could indicate a pre-shared key mismatch.

I could see that there was a mismatch in the IPSec Connection Profile and after confirming the pre-shared key was correct, I checked the name of the IPSec Connection Profile and discovered that the casing was different. The connection was failing at this level and proceeded to try to use a default Group which failed.

After making the case changes, I received an authentication box and the connection successfully established.

The IPSec Connection Profile name is case-sensitive.

Cisco ASA VPN integration with Symantec VIP Access

I have been working on migrating the Cisco ASA VPN from an RSA key solution to a Symantec VIP Access solution that integrates with smart devices e.g. iPhone, iPad through an App.

For this to work I ran through the below:

Active Directory

  1. Create a service account for Symantec VIP to be able to read AD
  2. Create a group for enabled users to be able to access ASA-VIP VPN

Symantec VIP server

  1. Create a user store
  2. Attach the above AD group for enabled users
  3. Configure RADIUS Validation details including port and shared secret

Cisco ASA

  1. Create a new IPSec Connection Profile with a new Pre-shared key
  2. Configure a new AAA Server Group which used the RADIUS authentication protocol
  3. Create a AAA Server (the Symantec VIP server)
  4. Set the Server Authentication and Accounting ports as well as the RADIUS Server Secret Key and Common Password which were initially setup on the VIP server
  5. Assign the DHCP Servers
  6. Assign the Group Policy

Note: The IPSec Connection Profile is case-sensitive.

On the client machine, I changed the corresponding profile parameters e.g. Connection Profile and Pre-shared key. The destination address points to the Outside interface of the ASA. When you hit connect button, the authentication box appears followed by a prompt on the iPhone VIP App seeking approval for the access. When approval is granted, the VPN connection completes and the padlock is displayed within the Cisco VPN client.

Allow ICMP through Cisco ASA

I have been working with an external vendor who has devices within our network. These devices require icmp access to their servers to download required configuration.

By default the Cisco ASA denies icmp packets externally. The policy-map global_policy specifies all the protocols to inspect. This is contained within the class inspection_default which specifies the default inspection traffic. By default, icmp is not in this list.

To get this to work I had to add icmp to the class inspection_default by adding the commands below.

Policy-map global

Class inspection_default

Inspect icmp

Inspect icmp error

Cisco ASA 5555-X Next-Generation Firewall

This week I had the pleasure of racking 2 x Cisco 5555-X ASA’s. The Next-Gen Firewalls offer:

  • Granular visibility and control
  • IPS to protect against known threats
  • Comprehensive protection from threats and advanced malware

The Cisco Next-Gen ASA Firewalls coupled with FirePOWER provides the following benefits:

  • ASA stateful firewall with advanced clustering
  • Cisco AnyConnect Secure Mobility Solution more securely extends corporate network access beyond corporate laptops to personal mobile devices, regardless of physical location
  • Granular Application Visibility and Control to support over 3000 application-layer and risk-based controls
  • Cisco FirePOWER Next-Generation IPS, which provide threat prevention and contextual awareness
  • Filters on hundreds of millions of URLs in over 80 categories
  • Discovery and protection against advanced malware and threats