Failed to establish VPN through PIX

René Jorissen on October 17, 2008 5 Comments • Tags: #1723 #305006 #47 #asa #creation #failed #firewall #for #gre #pix #pptp #protocol #regular #stateful #translation #vpn

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

The following two tabs change content below.

René Jorissen

Co-owner and Solution Specialist at 4IP Solutions
René Jorissen works as Solution Specialist for 4IP in the Netherlands. Network Infrastructures are the primary focus. René works with equipment of multiple vendors, like Cisco, Aruba Networks, FortiNet, HP Networking, Juniper Networks, RSA SecurID, AeroHive, Microsoft and many more. René is Aruba Certified Edge Expert (ACEX #26), Aruba Certified Mobility Expert (ACMX #438), Aruba Certified ClearPass Expert (ACCX #725), Aruba Certified Design Expert (ACDX #760), CCNP R&S, FCNSP and Certified Ethical Hacker (CEF) certified. You can follow René on Twitter and LinkedIn.

Latest posts by René Jorissen (see all)

  1. Jeff Burdine says:

    Thankyou for taking the time to post this. It solved my issue immediately.

  2. BJ says:

    Thanks heaps.
    Worked a treat!

    We use ASA 8.4(1) Cisco Adaptive Security Appliance Software Version 8.4(1)

    The fixup added “inspect pptp” to our policy-map global_policy.

    Turns out our older firewalls running 8.2 already have the inspect in the policy-map. Suspect it was added to those by a previous tech prior to me starting with the company.
    Regardless… now when staff attempt to connect to their customer’s VPN – it works a treat.

    Thanks again.

  3. Sfiso gasa says:

    Rene you handsome fellow you.. I was baffled as to why this would be a NAT issue and then i came across your article. it sorted out the problem but what i would like to know is how you ended up researching the ‘fixup’ command as being the possible resolution?

    Sfiso gasa

  4. Hey Sfiso,

    Experience is the magic word…. ;-) I had similar problems with the use of the esmtp fixup. That’s why I started looking at the fixup feature after I knew for sure that NAT wasn’t the problem.


  5. M. Boekholt says:

    The fixup did the trick for us also. Thnx a lot.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.