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

Configuring IPsec

106 "xauth-roadwarriors" #1: STATE_MAIN_I2: sent MI2, expecting MR2

002 "xauth-roadwarriors" #1: I did not send a certificate because I do not have one.

002 "xauth-roadwarriors" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3

108 "xauth-roadwarriors" #1: STATE_MAIN_I3: sent MI3, expecting MR3

002 "xauth-roadwarriors" #1: Main mode peer ID is ID_FQDN: '@groupname' 002 "xauth-roadwarriors" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4

002 "xauth-roadwarriors" #1: ISAKMP SA established

004 "xauth-roadwarriors" #1: STATE_MAIN_I4: ISAKMP SA established 041 "xauth-roadwarriors" #1: xauth-roadwarriors prompt for Username: 040 "xauth-roadwarriors" #1: xauth-roadwarriors prompt for Password: 002 "xauth-roadwarriors" #1: XAUTH: Answering XAUTH challenge with user='username'

002 "xauth-roadwarriors" #1: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1

002 "xauth-roadwarriors" #1: XAUTH client - awaiting CFG_set

004 "xauth-roadwarriors" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set 002 "xauth-roadwarriors" #1: XAUTH: Successfully Authenticated

002 "xauth-roadwarriors" #1: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1

002 "xauth-roadwarriors" #1: XAUTH client - awaiting CFG_set

004 "xauth-roadwarriors" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set 002 "xauth-roadwarriors" #2: initiating Quick Mode 002 "xauth-roadwarriors" #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2

002 "xauth-roadwarriors" #2: sent QI2, IPsec SA established

004 "xauth-roadwarriors" #2: STATE_QUICK_I2: sent QI2, IPsec SA established

Fine Tuning

Sometimes it can be necessary to slightly alter the kind of keys, algorithms, ciphers, or lifetimes used for various components of the cryptographic systems used. These are all tunable per connection through configuration options.

You can find their descriptions in the ipsec.conf man page, but we will provide a few examples here. For all these options, the default setting is the setting used when not specified in the connection at all.

Perfect Forward Secrecy

Perfect Forward Secrecy is not supported by all IPsec implementations. Normally this should be enabled (pfs=yes), which is the default, as this protects previous key exchanges even if the current one is compromised. You almost never need to set this to no. One such exception is the MS-L2TP client.

If you are unsure whether the other end wants to use PFS, you can safely set pfs=no. If Openswan receives a request with PFS, it will allow it despite its own setting to disable PFS, because there is absolutely no reason not to use PFS if it is available.

Rekeying

Rekeying is normally enabled (rekey=yes). It will ensure that new keys are negotiated when the current key is about to expire. If rekey is set to no, then when the keylife is reached, the connection will be torn down. Note that this does not prevent the other end from rekeying. If you

106