Interoperating with Other Vendors

Preparing the Interop

When you are trying to make two completely different systems work together, it is easy to immediately get lost in technicalities. People forget that there is usually a lot more going on when trying to make two completely different devices communicate correctly to each other. It is very likely that interop involves not only two different devices, but also two different IT departments. After all, people tend to stick to what they know works, and if it was all up to you, you would be working with two of the same devices to hook up together without a hitch. Keep in mind that you not only need to contend with technical issues, but also social issues. For instance, the other department might work different hours to you, or they might be a lot more or less formal than you. Remember to make an effort to interop with these human aspects as well.

The Human Factor

When attempting an interop between a cheap, free, and unsupported product, such as Openswan, and a very expensive commercial solution with the full support and backing of a large commercial vendor, there is another culture clash. One party will fully believe in the power of open source software, while the other is likely to believe in the expertise and reliability of the commercial vendor. Both parties will know exactly how their product works, and any failure to interop these two will obviously be the fault of the other party. Be careful not to raise the stakes and turn this into a political battle.

Do not make it impossible for the other party to admit fault, and do not be so cocky that you yourself will no longer be able to admit to a human error or bug. Such a charged atmosphere inevitably leads to situations where "things just start working" and "no one changed a thing". If the humans do not interop, neither will the technology. If you can stay friendly and considerate with the other system administrator, chances are they will give you the same courtesy.

Terminology

The first technical hurdle to overcome is the difference in terminology. Those not familiar with Openswan will not understand what is meant by left and right. Most likely, they will be familiar with terms as Local and Remote. Subnets are sometimes called Security Domain or Tunnel Policies. Other rather misleading terms are Medium Security (for AH) and High or Strong Security (for ESP). The DH groups are often called MODP groups. Some appliances use Tunnel to refer to a Phase 1, and Policy to refer to a Phase 2 of an IPsec connection.

Preparation

If you have not yet purchased the appliance that you will deploy as the other end of your IPsec connection, then reading this chapter can assist you in deciding whether some appliance's price is worth the hassle associated with it. If you are looking at a product that we do not describe here, read the specifications for it very carefully. For many appliances, it is not enough to simply look at the box or the manual. A good look at the web configuration interface is often the best way to find out the limitations or additional features of the appliance. Probably the most important feature to be aware of is IPsec passthrough.

206

Chapter 9

IPsec Passthrough

It seems vendors that do not implement IPsec at all like to advertise IPsec passthrough, or VPN Passthrough as a feature on their product packaging. IPsec passthrough is not IPsec. Ensure that the device actually supports IPsec. Even if it does support IPsec, the IPsec passthrough feature usually breaks the IPsec implementation.

Avoid buying appliances that advertise IPsec passthrough.

IPsec passthrough predates the IPsec NAT-Traversal standards and is now obsolete. If it works at all, which is rarely, it will still never work for more than one user behind NAT. Usually IPsec passthrough cannot be disabled, so any such appliances behind a NAT router are about as useful as a brick.

Tunnel Limitations

Some devices come with a limitation on the number of IPsec tunnels you can set up. Sometimes this limit is artificial although sometimes the hardware in these appliances does not have the CPU power necessary for many concurrent tunnels.

You should be wary of deciding you do not need multiple tunnels prematurely, for instance by thinking you only need one tunnel from the appliance to the company network. If you need to connect to two different subnets at the company, for example 10.0.0.0/8 and 192.168.0.0/16, that means you need two tunnels, even though there is only one IKE connection (ISAKMP SA) and two ESP connections (IPsec SAs). Many appliances do not correctly implement such dual tunnels that share a Phase 1, and will tear down the first tunnel when the second tunnel is brought up.

Anticipate Known Problems

If you know the product or vendor that you are trying to connect to, it will help to first use a search engine to look up whether someone else has written some notes about this particular kind of interop. It is very unlikely you are the first to try an interop between Openswan and a particular third-party vendor. Do some homework and avoid reinventing the wheel.

Update the Firmware

If you are responsible for the hardware on the other end, check the vendor website for firmware updates. If necessary, flash the firmware to the latest version. Be aware that some appliances, especially small ADSL/ISDN combination routers, can have different versions of firmware for specific regions. This is usually due to the different phone standards used in different countries, or the appliance has limited firmware space and so has one version for analogue phone lines and another for ISDN. In the past, there were many export versions of firmware with inferior encryption strength. When checking or upgrading the firmware, check that the appliance supports at least 3DES. For example, the older Cisco VPN3000 products often come with only single DES, and will not interop with Openswan out of the box.

207