Connecting the world…

regular

Cisco ASA: DNS reply filtering

Today I was asked to block access to multiple websites and the only device capable of doing this was the firewall. This customer is using a Cisco ASA firewall, which supports basic URL filtering. This customers wanted to block HTTP and HTTPS websites. HTTPS websites use a SSL tunnel from the end device to the end server, so the firewall isn’t capable of inspecting the SSL traffic. Instead of using URL inspection, I configured DNS inspection.

The ASA inspects the DNS request from the internal DNS server or end device to the external DNS server. I use regular expressions to match the FQDN of a website. Below is an example configuration of blocking access to the website (and applications using a DNS entry to this website) LogMeIn.com

regex domain_logmein.com “\.logmein\.com”
!
class-map type regex match-any DomainBlockList
description Blocked Domains
match regex domain_logmein.com
!
policy-map type inspect dns PM-DNS-inspect
parameters
message-length maximum 512
match domain-name regex class DomainBlockList
drop-connection log
!
policy-map global_policy
class inspection_default
inspect dns PM-DNS-inspect
!
service-policy global_policy global

A problem with this approach could be the DNS cache on the internal DNS server. This is domain name is queried before configuring the inspection, the domain will be available until the DNS cache from the DNS server expires. In urgent situation you can maybe clear the DNS cache yourself.

If a DNS reply is matched the ASA generates a syslog message, like shown below.

08-28-2009 15:33:31 Local4.Warning 10.10.1.254 %ASA-4-410003: DNS Classification: Dropped DNS request (id 22251) from inside:DNS-SERVER/59256 to outside:UPSTREAM-DNS/53; matched Class 23: match domain-name regex class DomainBlockList

Failed to establish VPN through PIX

We migrated our Internet connection lately and reconfigured our PIX firewall. We added some memory to install the latest firmware version (8.0(4)). After putting the PIX firewall in production some of the employees were complaining they couldn’t establish any PPTP VPN Tunnels anymore to customers.

Every time when some one called me, I tried it myself and I was always able to connect using a PPTP VPN Tunnel, but every time I was working remote and not at the office. So I always thought that something was wrong with there laptops, but today I encountered the problem myself.

Looking at the logging of the PIX firewall, I saw the following error message:

%ASA-3-305006: regular translation creation failed for protocol 47 src inside:<IP address> dst outside:<IP address>

The error message indicates that there is no NAT mapping for the specified traffic, which could direct you in the wrong direction. I checked the NAT mappings to be sure, but as I already thought, this couldn’t be the cause of the problem.

PPTP uses a TCP connection that uses port 1723 and an extension of generic routing encapsulation (GRE) [protocol 47] to carry the actual data (PPP frame). The TCP connection is initiated by the client, followed by the GRE connection that is initiated by the server. Because the PPTP connection is initiated as TCP on one port and the response is GRE protocol, the PIX Adaptive Security Algorithm (ASA) does not know that the traffic flows are related.

The PPTP fixup feature in version 6.3 allows the PPTP traffic to traverse the PIX when configured for PAT. Stateful PPTP packet inspection is also performed in the process. The fixup protocol pptp command inspects PPTP packets and dynamically creates the GRE connections and translations necessary to permit PPTP traffic. Specifically, the firewall inspects the PPTP version announcements and the outgoing call request/response sequence. Only PPTP Version 1, as defined in RFC 2637, is inspected. Further inspection on the TCP control channel is disabled if the version announced by either side is not Version 1. In addition, the outgoing call request and reply sequence is tracked. Connections and/or translations are dynamically allocated as necessary to permit subsequent secondary GRE data traffic. The PPTP fixup feature must be enabled for PPTP traffic to be translated by PAT.

So I had to configure the fixup protocol pptp feature with the following command:

fw01(config)# fixup protocol pptp 1723

As stated before, we are using fireware version 8.0(4). This version doesn’t support the fixup protocol pptp command and the converts the command an inspect pptp command as shown below.

fw01(config)# fixup protocol pptp 1723
INFO: converting ‘fixup protocol pptp 1723’ to MPF commands

!

!

policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect pptp