Booches.nl

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

Tools Page updated

I added a new tool to the Tools page, called Interface Traffic Indicator. The tool can be compared to STG, but needs to be installed on a workstation. The tool can be used to measure the throughput of a specific interface. To use the tool, you need at least the IP address of the device and a SNMP Read-Only string.

Tools like this can come in handy when measuring the used bandwidth of an interface in real-time. Appliance, like Cacti and Nagios, often poll ones in five minutes, which is very useful for establishing a baseline, but not for troubleshooting real-time.

More information about the Interface Traffic Indicator can be found here.

HSRP and ACL’s

I added a Guest VLAN to a network environment with two multi layer switches running HSRP. To secure the internal network from the Guest VLAN, I added a ACL to the Guest VLAN SVI. The ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any
remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The ACL allows querying the DHCP server to obtain the necessary IP address. Next the ACL denies access to all RFC 1918 IP addresses, which are used on the internal LAN segment of the customer. The last two statements allow HTTP and HTTPS access to the Internet.

At first, I just applied the ACL to both the multi layer switches and thought I was ready. After configuring some other tasks and finishing my work, I always check the configuration. Looking at the show standby brief output, I noticed that the primary HSRP switch didn’t have any standby switch anymore, as show in the output below:

Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vl1            1    200 P Active    local         10.1.0.3          10.1.0.1
Vl2            2    200 P Active    local         unknown         10.1.2.1

Because the only change was applying the ACL to the SVI, I already know where to search to correct the problem. Adding a deny ip any any log statement at the bottom of the ACL gave me the information I needed to know.

05:48:09.366: %SEC-6-IPACCESSLOGP: list GUEST-DENY-RFC1918 denied udp 10.1.2.2(1985) -> 224.0.0.2(1985), 360 packetsde

The ACL is blocking the multicast HSRP packets. Looking at the log output, you can see that the HSRP multicast IP address is 224.0.0.2 and port UDP/1985 is used. The multi layer switch is using his SVI IP address as source in the HSRP packet.

I changed the ACL on both multi layer switches by adding a statement to allow the HSRP packets. The new ACL is stated below:

ip access-list extended GUEST-DENY-RFC1918
remark Allow DHCP
permit udp any eq bootpc any

remark Allow HSRP PACKETS

permit udp host 10.1.2.[2|3] eq 1985 host 224.0.0.2 eq 1985

remark Deny RFC 1918
deny   ip 10.1.2.0 0.0.1.255 10.0.0.0 0.255.255.255
deny   ip 10.1.2.0 0.0.1.255 172.16.0.0 0.0.15.255
deny   ip 10.1.2.0 0.0.1.255 192.168.0.0 0.0.255.255
remark Allow HTTP / HTTPS
permit tcp 10.1.2.0 0.0.1.255 any eq http

permit tcp 10.1.2.0 0.0.1.255 any eq https

The HSRP packets weren’t blocked anymore after applying the new ACL to the SVI’s. The primary multi layer switch got his secondary switch back.

Applying an ACL to a SVI happens more often, so it is important to remember if you are running some sort of special protocol on the SVI or somewhere else in the configuration when applying an ACL.

Looking at the Internet I found a nice article on Aaron’s Worthless Words blog about multicast addresses, port numbers and associated protocols.