Connecting the world…

VPN

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

Cisco Firewall Design and Deployment

The session about firewall design and deployment didn’t reveal a lot of new things about the Cisco ASA appliance or FWSM module. The only new thing for me was the possibility to configure a redundant interface for a Cisco ASA appliance. The screen shot below shows the cabling scheme for an implementation with and without interface redundancy.

HA redundancy

This interface redundancy makes it possible to connect a ASA to two different physical switches. When the active switch would crash, the second switch would become the active switch.

Important here is to notice that this configuration doesn’t provide load-balancing across two links. The configuration is only for link redundancy.

To configure interface redundancy you can use the configuration snippet shown below.

interface Redundant1
  member-interface GigabitEthernet0/2
  member-interface GigabitEthernet0/1
  no nameif
  no security-level

  no ip address
!
interface Redundant1.4
  vlan 4
  nameif inside
  security-level 100
  ip address 172.16.10.1 255.255.255.0
!
interface Redundant1.10

  vlan 10
  nameif outside
  security-level 0
  ip address 172.16.50.10 255.255.255.0

The configuration of interface redundancy has some caveats as listed below:

  • Firewalls have to be configured in Active/Standby mode. No load-balancing or link aggregation is supported;
  • Interface redundancy is available on Cisco ASA 5510 and above. The ASA 5505 already has a build in switch and FWSM doesn’t have any physical interfaces;
  • Subinterfaces (IEEE 802.1Q) need to be configured on top of the logic redundant interface;

During the session the different modes for the firewalls have been discussed. Normally we only use the Routed Mode, but there are more modes like described below:

  • Routed mode: traditional mode of the firewall. Two or more interfaces that separate two or more layer 3 domains;
  • Transparent mode: the firewall acts as a bridge and functions mostly at layer 2 of the OSI model (this functions is often used for filtering traffic between two routers who, for example, exchange routing information through a dynamic routing protocol);
  • Multi-context: one physical firewall is divided in more virtual firewalls;
  • Mixed mode: using routed and transparent firewalls in a virtual environment (NOTE: mixed mode is only supported in FWSM today);

Firewall virtualization using multiple context has some caveats. We, Ictivity consultants, already noticed these caveats during firewall implementations. Firewall virtualization has the following caveats:

  • No support for VPN services;
  • No support for dynamic routing protocols;
  • No way to configure the sharing of CPU usage between contexts;
  • No support for multicast routing (multicast bridging is supported);

Especially not supporting VPN services (site-to-site VPN, remote access VPN and SSL VPN) is mostly the most used reason for not using multiple context implementation for the firewall.

ID Control

Ictivity received via via an e-mail about strong authentication products from ID Control. Strong authentication is authentication were you need multiple factors (what you have, what you know, what you are) to actual authenticate to a system, network or something else. We, as Connectivity Consultant, were asked to look at the different products and start a discussion about these products. Are they interesting for us or some of our customers??

The main focus is on three different authentication products. In this post you can read MY OPINION about the three different authentication items.

HandyID

HandyID is the leading mobile authentication method which provides a One Time Password (OTP) token-based, two-factor authentication solution on your mobile phone (handy), PDA, Blackberry and/or smart phone. HandyID turns your mobile device into a hardware token enabling a cost-effective, easy, convenient and user-friendly strong authentication solution for online banking, government and ecommerce. In combination with ID Control Server the set up and deployment is easy and fast.

Reading the text above I am thinking what HandyID brings extra in comparison to tokens like the ones from RSA. In my opinion I only see disadvantages. According to ID Control, you can use HandyID on every mobile device. I will not run it on my device, because the Nokia I am using isn’t that stable. I see crashing mobile phones, mobile phones with empty batteries and no charger nearby. I see incompatibilities with some tropical applications. In general, I like the concept of HandyID, but I would prefer a decent token from RSA (RSA SecurID).

KeystrokeID

KeystrokeID is the biometric solution based on behaviour traits that are acquired over a certain time period the user is typing on his or her keyboard (versus a physiological characteristic or physical trait). KeystrokeID monitors and analyses all keyboard behaviour performed by the user during his/her access. Based on this keystroke behaviour performed in comparison to the user’s normal behaviour access is granted when this user is also authorized.

Huh?? So reading this, the keyboard is learning the way you type and grants you access on that process. Sounds cool, but again I see a lot of customers having problems accessing the stuff they would like to access. I can image that KeystrokeID would work for a private secretary who finds the keys blindly on the keyboard, but what about people who cannot type that well and what when you are typing at night in bed, without decent light. I guess you won’t type the same as during normal day time. Summarizing, I would advise OUR customers to use KeystrokeID, because I THINK that the product brings more authentication problems than solving authentication problems.

USB Token

ID Control’s USB Token is a portable end-user authentication token that can replace user name and password for workstation, website, VPN, file, email, network, file and/or disk access security. ID Control USB Token plugs into any standard USB port and can even run without any software.

After reading the documentation about USB Token, I definitely imagine advising USB Token to customers and even use one for my own. The USB Tokens ease of use looks really better in comparison to smart-cards or biometrics. Nowadays USB keys are common usage and the price for USB keys won’t be that high. Another advantage of the USB Token is that you only need an enabled USB port on a workstation and that’s it. For smart-cards and biometrics, you normally need extra equipment before you can actually use the smart-cards.

The USB Token can be used for different reasons like Secure VPN Authentication, File and Disk Encryption, Web (Application) Sign-on, Secure Password Manager, Computer and Network Sign-on, Email Encryption & Signing and PKI. I would definitely use the USB Token for File and Disk Encryption and Secure Password Manager. In my line of work and our customers, I can also imagine using the USB Token for Secure VPN Authentication.