Watchguard PPTP VPN user validation via RADIUS using Cisco ACS 4.2

Wow that title is a mouthful.

A customer has a Watchguard Firebox firewall and a Cisco ACS, all the users for Cisco related activities are on the ACS and the customer wants to migrate all the PPTP VPN users from the firewall to the Cisco ACS.

Both the ACS and Firebox support RADIUS, so it sounds quite easy.

I did the initial configuration; creating the AAA client in the ACS, changing the VPN configuration on the watchguard so it asks the ACS for the users, creating a test user and a test group with the following RADIUS parameters:

[011] Filter-Id PPTP-Users

[311\007] MS-MPPE-Encryption-Policy "Encryption Required"
[311\008] MS-MPPE-Encryption-Types "128-bit"
[311\012] MS-CHAP-MPPE-Keys 
[311\016] MS-MPPE-Send-Key 
[311\017] MS-MPPE-Recv-Key

Testing with a Windows 7 Enterprise client, I got the error:

Error 734: The PPP link control protocol was terminated. 

The logs on the firewall showed:

level=''3'' msg=''pri=''3'' msg_id=''1401-3003'' msg=''pptp MSCHAPv2 authentication ok for peer wg''''
level=''7'' msg=''sent [CHAP Success id=0x32 ''S=5F85A740C65AD93F308ED6681B455486FC2EF4F5 M=Access granted'']'' new_msg='' level=''7'' msg=''sent [CHAP Success id=0x32 ''S=5F85A740C65AD93F308ED6681B455486FC2EF4F5 M=Access granted'']'''' Debug
pppd[1255] MPPE required, but keys are not available. Possible plugin problem?
pppd MPPE required but not available'''

Basically the issue seemed to be MPPE related, since the configuration requires encryption, no MPPE = no VPN.

In the ACS the authentication showed as successful and little else. I checked and double checked the RADIUS attributes. After sometime with Watchguard support, they suggested to get a packet capture of the ACS RADIUS response:

Using Wireshark, it was clear that the ACS was not sending any MPPE related attributes and in fact the only Microsoft attribute was the one indicating that the authentication was OK. 

I replicated the VPN configuration using a cisco router and it worked without issues, after that, I was checking everything again and noticed that the cisco router was defined in the ACS AAA client section as "RADIUS (Cisco IOS/PIX 6.0)" while the Watchguard Firewall was defined as "RADIUS (IETF)"

I changed the firewall to "RADIUS (Cisco IOS/PIX 6.0)" and ta-da, everything worked.

All the Microsoft attributes were there and all was well in the land. Of course after reading the ACS help, it seems obvious:

"RADIUS (IETF). These are the standard IETF RADIUS attributes. Select this option if you are using devices supporting RADIUS but do not need to make use of the vendor-specific attributes (VSA) of the manufacturer.

RADIUS (Cisco IOS/PIX 6.0) Select the RADIUS (Cisco IOS) option when using a Cisco Systems IOS device as a AAA client. This option enables you to make use of the Cisco IOS and PIX 6.0 RADIUS VSAs."

Cisco IOS Site-to-Site IPSec VPN using Certificates

After a couple of weeks trying to get a Site-to-Site IPSec tunnel to work using a Watchguard firewall, I decided to simply do it with a Cisco Router.

These are the steps involved in the configuration, hopefully this will help someone else or myself in the future.

In my particular case, the remote end uses certificates for the VPN and has a Certification Authority, so first we have to generate a certificate and ask them to sign it, the CSR can be generated on the IOS but for backup purposes I always tend to use openssl, that way if the router/firewall dies, we have backups:

openssl req -new -nodes -keyout example.key -out example.csr

Generating a 1024 bit RSA private key

.............++++++

............++++++

writing new private key to 'example.key'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:

State or Province Name (full name) [Some-State]:

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:

Organizational Unit Name (eg, section) []:

Common Name (eg, YOUR name) []:

Email Address []:

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:

Now that the CSR its done, the CA has to sign it.

After the CA does the signing, we need to import the certificates into the IOS device. There are many ways of doing this, but I prefer the PKCS#12 method since it's self-contained and simpler.

To use PKCS#12, we need to create the p12 file, I do this with openssl:

openssl pkcs12 -export -in example.cer -inkey example.key -certfile ca.cer -name "name" -out example.p12

Enter Export Password:

Verifying - Enter Export Password:

Now that we have the certificate signed and in PKCS#12 format, we have to import it to the IOS device, for that we have to create a pki trustpoint:

R1(config)#crypto pki trustpoint EXAMPLE-VPN

R1(ca-trustpoint)#revocation-check none

With the trustpoint created, we can import the certificate. There are several methods, I use TFTP:

R1(config)#crypto ca import EXAMPLE-VPN pkcs12 tftp: PASSWORD

% Importing pkcs12…

Address or name of remote host []? 1.1.1.1

Source filename [trustpoint]? example.p12

Reading file from tftp://1.1.1.1/example.p12

Loading example.p12 from 1.1.1.1 (via FastEthernet0/0): !

[OK - 1245 bytes]

CRYPTO_PKI: Imported PKCS12 file successful

We can verify that everything was imported correctly with the commands:

show crypto pki trustpoints

show crypto pki certificates

Now that the certificates are out of the way, we can focus on the VPN configuration itself.

The tunnel parameters for this example are:

IKE Phase 1

• Encryption 3DES
• Hash SHA
• DH-Group 2

IKE Phase 2

• ESP-3DES-MD5
• Local Network: 192.168.2.1/32
• Remote Network: 192.168.1.0/24

IKE Phase 1:

crypto isakmp policy 1

encr 3des

authentication rsa-sig

hash sha

group 2

This can be verified using show crypto isakmp policy

Transform-Set(s):

crypto ipsec transform-set TRANSFORM-SET-NAME esp-3des esp-md5-hmac

This can be verified using show crypto ipsec transform-set

Interesting traffic and NATing the source:

Lets assume that my network is 192.168.0.0/24, the remote network 192.168.1.0/24 and that the remote side has told me that all of my traffic has to come from 192.168.2.1

ip access-list extended NAT-IP-VPN

permit ip host 192.168.0.0 0.0.0.255 192.168.1.0 0.0.0.255

ip nat pool VPN-NAT 192.168.2.1 192.168.2.1 prefix-length 30

ip nat inside source list NAT-IP-VPN pool VPN-NAT overload

ip access-list extended TRAFFIC-VPN

permit ip host 192.168.2.1 192.168.1.0 0.0.0.255

Be careful with the NAT because if you have more than one statement the order matters. This can be verified using show ip nat translations, show access-lists

Crypto Map:

This is where we put it all together for the IKE Phase 2

crypto map VPN-Map-1 10 ipsec-isakmp

set peer 1.1.1.1

set security-association lifetime seconds 86400

set transform-set TRANSFORM-SET-NAME

match address TRAFFIC-VPN

Apply the crypto map/nat on the interfaces:

interface FastEthernet0/0

description LAN

ip nat inside

interface ATM0.1 point-to-point

description WAN

ip nat outside

crypto map VPN-Map-1

Verification:

Now all we have to do is generate interesting traffic and test what happens, some useful commands are show crypto isakmp sa and show crypto ipsec sa.

Useful Links:

Site-to-site IPSec VPN using Digital Certificates

Site-to-Site and Extranet VPN Business Scenarios

Deploying Cisco IOS Security with a Public-Key Infrastructure
Creating PKCS12 Certificates

Import PKCS12 certificate on IOS router

CiscoSecure ACS for Windows Router PPTP Authentication

If you need to migrate your PPTP users from a IOS device/PIX to a Cisco ACS, this is a good starting point:

Configuring CiscoSecure ACS for Windows Router PPTP Authentication

I was having an odd issue with this configuration, everything seemed fine but on my Windows 7 Test client I got the Error 742: "The remote server does not support encryption" every time I tried to connect, the ACS 4.2 showed the authentication as successful and nothing else, the debug on the router pretty much the same thing with the exception of :

"Vi1 MPPE: RADIUS keying material missing"

After 2 weeks with TAC,  We came to the conclusion that the issue was caused by the fact that starting with Vista, MS-CHAP v1 is deprecated, so in order for MS-CHAP v2 to work we needed to enable the extra MPPE Attributes:

[311\016] MS-MPPE-Send-Key
[311\017] MS-MPPE-Recv-Key

In the new Cisco ACS 5.x family, enabling the these particular attributes does not seem to be necessary  since "These are added to the profile as required".