In different scenario’s it is required to configure some kind of routing protocol between two offices, but the routers should be configured to look directly connected to each other. Normally I always configure an IPsec VPN between the two offices and configure an additional GRE tunnel over the IPsec VPN tunnel. In that way the routers look directly connected and adding a routing protocol is no problem.
In the past I noticed several times that the GRE tunnel doesn’t come up, when using a Cisco PIX firewall or a Cisco ASA firewall. When using IOS 6.x on the PIX or 7.x on both hardware platforms, there is a workaround by using the following command:
clear local-host <remote peer>
Cisco has reported this bug in BugID CSCse36327:
The IPSEC tunnel was previously working and either one of the following events occured:
1. the crypto map and/or isakmp has been removed and reapplied to the interface
2. the PIX/ASA is upgraded from version 6.x to version 7.x
3. the PIX/ASA is rebooted
4. The remote IPSEC peer/s is rebooted
All events except 1 occur when a dynamic crypto map is used without a match address statement.
This typically affects only GRE traffic.
In PIX/ASA 7.x, GRE encryption may stop working (GRE packets are sent in clear) after removing and reapplying the encryption. This behaviour is by design in 7.x. If encryption is disabled but GRE packets are coming to the PIX in this time, GRE session is created on the PIX and marked as clear-text one (“do not encrypt”). When encryption is applied back, non-encrypted GRE session still exists on PIX and GRE packets that should be encrypted still bypass crypto map until old session is timed out or deleted. If there is a dynamic routing (OSPF/EIGRP/etc) running over GRE, this GRE session may never timeout and should be cleared manually.
In PIX/ASA 8.0.2, new functionality was introduced with new CLI command: “sysopt connection reclassify-vpn”. Default state is disabled. If this command is enabled, then enabling encryption causes non-encryption sessions to be dropped and reestablished with encryption.
Looks like there is a new command introduced in IOS 8.0.2 as mentioned above, by using sysopt connection reclassify-vpn.
There is also an entry on the Cisco SupportWiki about this problem. So the next time I will try this new command.
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