Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Building And Integrating Virtual Private Networks With Openswan (2006).pdf
Скачиваний:
78
Добавлен:
17.08.2013
Размер:
4.74 Mб
Скачать

Interoperating with Microsoft Windows and Apple Mac OS X

In practice, the certificate will be imported, but it will not show up as valid.

Regardless of the method used, you should now start KeyChain Access.app and look at your certificate and your CA certificate. They should have a green check symbol in a circle, and say

This certificate is valid.

The CA certificate can be found in X509Anchors, and your personal certificate can be found in

Certificates or System.

Summary

This chapter showed two ways of getting Microsoft Windows machines to connect to an Openswan server using a VPN, using either plain IPsec or L2TP/IPsec. It also walked through the process of how to connect to Openswan using Mac OS X, which unfortunately still has some way to go before it is really useful. You should now be able to configure both the Openswan server and Windows clients to connect safely using L2TP with PSK or X.509, or X.509 without L2TP using a third-party IPsec client. You should also be able to set up PSK-based L2TP connections with Mac OS X. You should always use Openswan-2.5.0 or never when using either Mac OS X or L2TPbased IPsec connections.

204

9

Interoperating with Other Vendors

So far, we have covered the ins and outs of interoperating Openswan with end-user computers running Linux, Microsoft Windows, and Apple Mac OS X. The choice of end-user platform is rather limited, which makes the interop procedure fairly simple and straightforward.

Unfortunately, this is not true for connecting Openswan to various third-party IPsec appliances.

This chapter will describe a few examples and the issues involved with hardware interop, and will list a few appliances and the peculiarities involved in getting these to work with Openswan.

Openswan as a Client to an Appliance

Using Openswan on the server end is quite easy. You have all the logs of the incoming connection, and you know what your connection parameters for the clients are supposed to be. Using Openswan as a client on the other hand can be very hard. Often the server in such cases is a non-Openswan system and usually the VPN server logs are not available. People trying to use Openswan as a client to connect to these systems usually do not have the cooperation of the system administrator on the other end. The best source of tips and information in these cases is usually to have a look at the configuration of other clients using the same setup.

For Cisco's VPN client for example, you usually get a PCF file from the administrator of the Cisco Concentrator. In the Openswan contrib directory is a utility that will try to convert these files to

ipsec.conf syntax.

Usually these VPN appliances are set up in a very strict way. They will want the first IKE packet to contain the exact proposal, instead of letting IKE negotiate this. This is of course always the case for Aggressive Mode, which does not support the negotiation of connection parameters. If your first packet fails to meet their requirements, they often silently drop the packet. In these cases you must specify ike= and esp= options to ensure the very first proposal that Openswan sends is the exact correct one.

If you do not know the exact configuration for PFS, use pfs=no. If the other side uses PFS anyway, Openswan will still accept and use PFS.