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
inspect dns preset_dns_map
Latest posts by René Jorissen (see all)
- MacOS Big Sur and SSLKEYFILELOG - November 23, 2021
- ClearPass, Azure AD, SSO and Object ID - August 12, 2021
- ClearPass – custom MPSK - July 20, 2021
Thankyou for taking the time to post this. It solved my issue immediately.
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.
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?
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.
The fixup did the trick for us also. Thnx a lot.