Делаю IPSEC site2site VPN между DFL-260E (2.40.04.08-21460) и PIX-501 (6.3(5)).
Вообще-то, делал это уже сто раз. Теперь делаю в 101, нужно кое-чему научиться.
Да, на DFL настроен также L2TP/IPSEC сервер. На PIX вообще ничего, связанного с VPN, нет, кроме этого туннеля.
Сделал, все политики и числовые параметры одинаковые. Десять раз проверил.
Со стороны DFL туннель устанавливается, со стороны PIX - виснет на проверке пароля.
Смотрю логи ikesnoop - да, вроде именно пароль и не совпал.
Цитата:
Exchange type : Informational
ISAKMP Version : 1.0
Flags :
Cookies : 0x58be4a540712c41 -> 0x82ed5d39a1a31ced
Message ID : 0x15aab882
Packet length : 181 bytes
# payloads : 1
Payloads:
N (Notification)
Payload data length : 149 bytes
Protocol ID : ISAKMP
Notification : Invalid payload type
Notification data:
Notify message version: 1
Offending payload type: Unknown payload type
Error text: "Incorrect pre-shared key (Invalid next payload value)"
Offending message ID: 0x00000000
На DFL, естественно, два IPSEC интерфейса - от L2TP и моего туннеля. От туннеля - второй в списке.
Переставляю первым - все начинает работать.
И возникает вопрос: что это за особенность в поведении DFL, которая не дает строить туннель из-за порядка IPSEC в списке?
Все при том, что у меня работают несколько DFL с IPSEC туннелями, на некоторых их по нескольку штук. И везде есть L2TP сервера, и все работает.
На какие это грабли я наступил?
PS. Подумал, есть еще один момент. Анализируя логи ikesnoop, вижу, что DFL из числа предложений по IKE, поступающих от PIX, выбирает AES-MD5, которое на DFL для этого туннеля не разрешено (но разрешено для IPSEC от L2TP). Включение этого варианта в число разрешенных для VPN DFL-PIX не помогает.