Chapter 9

SonicWALL

SonicWALL has two versions of their OS called Standard and Enhanced. SonicWALL recommends using OS Enhanced for VPN usage. OS Standard has almost no debugging options, so while it can be made to work in a limited number of modes, it is very hard to diagnose problems. PSK-based connections work fine. We have seen configurations using X.509 certificates that failed to work. SonicWALL only supports sending the X.509 certificate inline, you cannot explicitely load an X.509 certificate. The documentation on the SonicWALL website is very outdated, and references FreeS/WAN 1.94. It therefore contains errors, such as, for example, stating that there is no support for Aggressive Mode, which is no longer true.

Do not forget to allow outgoing IKE packets on UDP port 500 and 4500 in the firewall configuration. When using PSKs, you might need to use the SonicWALL's Unique Firewall Identifier (UFI) as the rightid= for your IPsec connection. An example SonicWALL Pro-300 configuration file follows below:

Unique Firewall Identifier: YourUFIHere Security Association: Openswan

IPsec Keying Mode: IKE using Preshared Secret Name: Openswan

IPSec Gateway Address: 193.110.157.17 Phase 1 DH Group: Group 2

SA Lifetime (secs): 28800

Phase 1 Encryption/Authentication: 3DES & MD5

Phase 2 Encryption/Authentication: Strong Encrypt and Authenticate (ESP 3DES HMAC MD5)

Shared Secret: YourPreSharedKey Destination Networks: 192.168.1.0 255.255.255.0

Advanced Options:

Enable Perfect Forward Secrecy : Checked

Phase 2 DH Group: Group 2

In ipsec.secrets, we again use the Unique Firewall Identifier:

193.110.157.131 1.2.3.4 @YourUFIHere : PSK "ThePreSharedSecret"

You can set the UFI in the VPN General screen.

As of version 2.3.0, Openswan can now connect to a SonicWALL VPN Appliance as a roadwarrior. The example given here uses IKE with PSK as its keying mode. On the VPN Summary page of the SonicWALL administration interface, note the value of Unique Firewall Identifier for use in ipsec.conf. Make sure the SonicWALL Group VPN is set up as follows:

Phase 1 DH Group: Group 5

Phase 1 Encryption/Authentication: 3DES & MD5

Phase 2 Encryption/Authentication: Strong Encrypt and Authenticate (ESP 3DES HMAC MD5)

And under Advanced Settings:

Enable XAUTH

Enable Perfect Forward Secrecy

Phase 2 DH Group: Group 5

The corresponding ipsec.conf is:

conn sonicwall left=%defaultroute

229

Interoperating with Other Vendors

leftsubnet=your.subnet/mask

leftid=@home

leftxauthclient=yes

right=sonicwall.ip.address

rightsubnet=vpn.subnet/mask

rightxauthserver=yes

rightid=@sonicwall.unique.firewall.identifier

keyingtries=0

pfs=yes

aggrmode=yes

auto=add

auth=esp esp=3des-md5-96 ike=3des-md5-96 authby=secret

And the ipsec.secrets file contains:

@home @sonicwall.unique.firewall.identifier : PSK "your.shared.secret.goes.here"

BinTec

We have received a few reports on BinTec that suggest some models, for example the X8500, have some issues. One problem is failing to pick the correct IDs, especially when using X.509 Certificates. A workaround for this is to add a SubjectAltname= specifying the IP address to the X.509 Certificate. Furthermore, it seems the failure messages for this ID issue (and possibly other failures in Phase 2), which happens after the ISAKMP SA has been established, are not sent encrypted, but in plaintext. Openswan ignores all those messages because at that point in the negotiation, it expects only encrypted IKE messages. The log will look like this:

Dec 17 15:06:29 Sunrae pluto[21106]: "toronto" #214: sent MR3, ISAKMP SA established

Dec 17 15:06:29 Sunrae pluto[21106]: "toronto" #214: Informational Exchange message must be encrypted

To see what is actually happening on the BinTec, you need to set the ipsecGlobMaxSysLogLevel to debug and then log in to the BinTec console, for example through its serial port, and run the debug ipsec command. From then on, you will see IPsec error messages appear on the console.

The BinTec routers apparently also come with the time unset, meaning the time on the unit starts at January 1, 1970. This will cause all certificates to be invalid, since this time is before the certificates' validity date.

LANCOM

The LANCOM DSL router comes with a web interface that is unfortunately completely inadequate. In fact, it is nothing more than a web interface to the device's SNMP MIBs. This may be handy for the programmers who made the device, but not for anyone who actually bought the device. LANCOM however does ship with Windows software and a user guide to configure the unit. The software at least offers a usable user interface, even though still a bit confusing, since it wants the user to create 'tunnels' and 'policies' and then requires the user to tie them together. Multiple tunnels between the same endpoints should be set up using the Extranet feature.

Older versions of the LANCOM devices require the same ID on both sides, but Openswan of course cannot use the same ID for leftid= and rightid=. It is also not RFC compliant.

230

Chapter 9

Linksys

The Linksys BEFVP41 router's IPsec support is based on a very old version of FreeS/WAN. It is therefore not surprising that it is very compatible with Openswan, though the user interface is a limiting factor here.

It uses the term Local Secure Group for what Openswan calls the leftsubnet= and the term

Remote Secure Group for the rightsubnet=. The Remote Security Gateway is what Openswan calls right=. It can be a host name or IP address.

231

Interoperating with Other Vendors

The BEFVP41 uses 1DES and modp-768 by default, which are not compiled into Openswan by default because they are too weak. You need to change the defaults to 3DES on the VPN page and the MODP group on the advanced page to 1024.

Lucent Brick

The Lucent VPN Firewall Brick is a two-tier system consisting of a managed firewall solution, which can span multiple firewalls, centrally managed by the Lucent Security Management Server (LSMS). On the Brick side, you need to configure the following parameters in your LSMS:

Preshared Key: whateversecretkeyis

Under the Policy tab:

ISAKMP Proposal:

D-H Group: Group 2 (Group 1 is not supported per default by Openswan) Encryption Type: TRIPLE DES (1DES is not supported per default by Openswan) Auth Type: HMAC MD5

SA Lifetime (sec): 28800 (OpenSWAN Maximum is 8 hours) IPSec Proposal:

Protocol: ESP-50

Encryption Type: TRIPLE DES (1DES is not supported) Auth Type: HMAC MD5

SA Lifetime (sec) 14400

SA Lifetime (Kbytes) 10000000

Check Enable Prefect Forward Secrecy Uncheck Enable compression

232