День добрый.
Жила у меня конфигурация в которой, в частности, один из IPSEC туннелей был вида:
DFL-210->i-net->IPCOP все работало как часы. NET<->NET, PSK, main mode, 3DES, SHA1.
И тут вдруг провайдер на стороне DFL решил, что он отказывает клиентам в реальных адресах и заворачивает всех через NAT.
И выдает два адреса: 10.0.0.111 и наружный конец NAT в виде 87.A.A.A
Ладно, думаю, проверим как работает IPSEC через NAT...
________
Оговорюсь сразу, чтобы было меньше подозрений, что я совсем что-то неправильно настраиваю: мне удалось запустить в этой конфигурации туннель вида DFL-210(IPSEC/nat-t)->NAT-> i-net->DFL-700
Но ТОЛЬКО такую конфигурацию. Замена DFL-700 на DFL-210 или IPCOP - и конструкция не работает. Про работающую конфигурацию - расскажу отдельно, она работает с виду (содержимое логов и отображение состояния туннеля) - очень странно, хотя трафик через нее идет и претензий к ней нету...
________
Так вот IPCOP - это openswan. C пониманием NAT-T у него вроде все должно быть нормально.
Ан нет:
В результате в логе IPCOP:
____
16:27:43 pluto[7217] | next event EVENT_DPD in 1 seconds for #1706
16:27:43 pluto[7217] | state transition function for STATE_MAIN_I3 failed: INVALID_ID_INFORMATION
16:27:43 pluto[7217] "M3" #1726: sending notification INVALID_ID_INFORMATION to 87.A.A.A:4500
16:27:43 pluto[7217] "M3" #1726: we require peer to have ID '87.A.A.A', but peer declares '10.0.0.111'
16:27:43 pluto[7217] "M3" #1726: Main mode peer ID is ID_IPV4_ADDR: '10.0.0.111'
16:27:43 pluto[7217] | state object #1726 found, in STATE_MAIN_I3
16:27:43 pluto[7217] | peer and cookies match, provided msgid 00000000 vs 00000000
16:27:43 pluto[7217] | state hash entry 31
16:27:43 pluto[7217] | peer: 57 f5 b7 5d
16:27:43 pluto[7217] | RCOOKIE: 4e b9 26 96 49 e0 4f b2
16:27:43 pluto[7217] | ICOOKIE: 1e 4f d7 af 22 bb fd bd
16:27:43 pluto[7217] | *received 68 bytes from 87.A.A.A:4500 on eth1
16:27:43 pluto[7217] |
16:27:43 pluto[7217] | next event EVENT_DPD in 1 seconds for #1706
16:27:43 pluto[7217] | inserting event EVENT_RETRANSMIT, timeout in 10 seconds for #1726
16:27:43 pluto[7217] "M3" #1726: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
16:27:43 pluto[7217] | inserting event EVENT_NAT_T_KEEPALIVE, timeout in 20 seconds
16:27:43 pluto[7217] "M3" #1726: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
16:27:43 pluto[7217] | aa a4 eb 25
16:27:43 pluto[7217] | received NAT-D: 33 1b c8 c7 ca d8 f8 51 f0 db 10 aa fb 35 51 d4
16:27:43 pluto[7217] | f2 1d 88 a2
16:27:43 pluto[7217] | received NAT-D: a0 ef ce 3a b5 6e 1c 17 b6 63 53 fa 32 a8 d9 8e
16:27:43 pluto[7217] | cd f9 9a 1a
16:27:43 pluto[7217] | received NAT-D: 1c 27 ac 2f d5 17 79 91 9c be be 06 04 ca 56 09
16:27:43 pluto[7217] | 36 0c 59 82
16:27:43 pluto[7217] | received NAT-D: f1 35 31 7e 0c dc 78 5f 0e 4c ca c1 63 74 0a df
16:27:43 pluto[7217] | d6 bc b0 bf
16:27:43 pluto[7217] | received NAT-D: 31 02 ef 23 7b d2 cb ca 97 f0 60 44 d0 b7 69 bd
16:27:43 pluto[7217] | df b0 e6 1f
16:27:43 pluto[7217] | expected NAT-D: 00 b1 4d 1f 0e fe 47 b1 e1 43 c7 36 57 0c 08 67
16:27:43 pluto[7217] | NAT_TRAVERSAL_NAT_BHND_PEER
16:27:43 pluto[7217] | df b0 e6 1f
16:27:43 pluto[7217] | _natd_hash: hash= 00 b1 4d 1f 0e fe 47 b1 e1 43 c7 36 57 0c 08 67
16:27:43 pluto[7217] | _natd_hash: port=37905
16:27:43 pluto[7217] | _natd_hash: ip= 57 f5 b7 5d
16:27:43 pluto[7217] | 4e b9 26 96 49 e0 4f b2
16:27:43 pluto[7217] | _natd_hash: rcookie=
16:27:43 pluto[7217] | 1e 4f d7 af 22 bb fd bd
16:27:43 pluto[7217] | _natd_hash: icookie=
16:27:43 pluto[7217] | _natd_hash: hasher=0x80e013c(20)
16:27:43 pluto[7217] | ba 41 2c a6
16:27:43 pluto[7217] | _natd_hash: hash= 44 b8 72 95 35 f0 69 ba 7d 75 8c 21 8c af 47 ae
16:27:43 pluto[7217] | _natd_hash: port=37905
16:27:43 pluto[7217] | _natd_hash: ip= c3 ef 94 24
16:27:43 pluto[7217] | 4e b9 26 96 49 e0 4f b2
16:27:43 pluto[7217] | _natd_hash: rcookie=
16:27:43 pluto[7217] | 1e 4f d7 af 22 bb fd bd
16:27:43 pluto[7217] | _natd_hash: icookie=
16:27:43 pluto[7217] | _natd_hash: hasher=0x80e013c(20)
16:27:43 pluto[7217] | state object #1726 found, in STATE_MAIN_I2
16:27:43 pluto[7217] | peer and cookies match, provided msgid 00000000 vs 00000000
16:27:43 pluto[7217] | state hash entry 31
16:27:43 pluto[7217] | peer: 57 f5 b7 5d
16:27:43 pluto[7217] | RCOOKIE: 4e b9 26 96 49 e0 4f b2
16:27:43 pluto[7217] | ICOOKIE: 1e 4f d7 af 22 bb fd bd
16:27:43 pluto[7217] | *received 324 bytes from 87.A.A.A:4500 on eth1

____

В это же время в лог DFL-210 пишутся повторяющиеся сообщения:
Bad logmsg: [2006-12-08 16:27:41] <6>FW: IPSEC: prio=1 Phase-1 [responder] between ipv4(udp:500,[0..3]=10.0.0.111) and ipv4(any:0,[0..3]=195.B.B.B) done.

87.А.А.А – “наружный конец” NAT
195.B.B.B – “честный” конец туннеля

___
есть конструктивные идеи - что подправить в консерватории?

NAT-T используется в том случае, если используется NAT, запрещающий прохождение через него ESP протокла, в реальности такие NAT мало где всречаются.
А вот насчёт IKE, в стадии init нужно использовать Aggressive mode, чтобы упростить систему авторизации без проверки адресов.

-- непонятно как обойтись без проверки адресов.
Если включить Aggressive mode, запретить NAT-T и отключить подмену IP со стороны DFL-210 будет вот такая картина:

13:43:40 pluto[7217] | next event EVENT_DPD in 2 seconds for #7007
13:43:40 pluto[7217] | state transition function for STATE_AGGR_I1 failed: INVALID_ID_INFORMATION
13:43:40 pluto[7217] "M3" #7029: sending notification INVALID_ID_INFORMATION to 87.А.А.А:500
13:43:40 pluto[7217] "M3" #7029: initial Aggressive Mode packet claiming to be from 87.А.А.А on 87.А.А.А but no connection has been authorized
13:43:40 pluto[7217] "M3" #7029: no suitable connection for peer '10.0.0.111'
13:43:40 pluto[7217] "M3" #7029: Aggressive mode peer ID is ID_IPV4_ADDR: '10.0.0.111'
13:43:40 pluto[7217] "M3" #7029: received Vendor ID payload [Dead Peer Detection]
13:43:40 pluto[7217] | state object #7029 found, in STATE_AGGR_I1
13:43:40 pluto[7217] | peer and cookies match, provided msgid 00000000 vs 00000000
13:43:40 pluto[7217] | state hash entry 21
13:43:40 pluto[7217] | peer: 57 f5 b7 5d
13:43:40 pluto[7217] | RCOOKIE: 00 00 00 00 00 00 00 00
13:43:40 pluto[7217] | ICOOKIE: 2a 6a ba 1e 24 7d cc 6c
13:43:40 pluto[7217] | state object not found
13:43:40 pluto[7217] | state hash entry 15
13:43:40 pluto[7217] | peer: 57 f5 b7 5d
13:43:40 pluto[7217] | RCOOKIE: 56 cc 37 3a 35 4e eb eb
13:43:40 pluto[7217] | ICOOKIE: 2a 6a ba 1e 24 7d cc 6c
13:43:40 pluto[7217] | *received 288 bytes from 87.А.А.А:500 on eth1

-- вдогон: туннель между DFL-210 и DFL-700 замечательно поднимается в main mode с подменой адреса со стороны 210-го, только IKE SA не отображается почему-то на 210-м, будто его и нет вовсе.

-- там проблема в том, что конец туннеля идентифицируется по приватному айпишнику. А сообщается - публичный, естественно. Потому как никакого способа сообщить приватный - нету.
Есть идея как это обойти?

Есть один способ, аналог Dynamic_IPSec
Выставьте agressive mode на устройствах, а в 700-м в качестве remotgateway выставьте 0.0.0.0/0 агрессивный режим упростит авторизацию, а такая маска убдет принимать соединения, но возможно столкнётесь с проблеммой при работе с другими туннелями.

--так в том и дело, что 700-й и без того плюет на то, что ему неправильный адрес суют. И работает.
А вот 210-210 и 210-IPCOP (или любой другой OPEN|FREE S-WAN) запустить не удается, там проверка правильности концов туннеля производится честно.

Не могли бы Вы _более_ ясно объяснить в чём состоит проблема. Лучше всего позвонить.

-- после более детальных разбирательств установлено следующее:
В условиях, когда один из маршрутизаторов (а именно - DFL-210) имеет на WAN интерфейсе приватный адрес вида 10.0.0.1 и "фиктивный" публичный адрес, по которому он доступен из интернета, удается:
1) поднять IPSEC VPN в main mode. При условии, что у DFL-210, стоящем за NAT, в настройках роутинга установлен параметр "сообщать другой адрес, а не адрес интерфейса" и в этот "другой адрес" вписан "фиктивный" публичный адрес. Туннель удается установить со стоящими на нормальных публичных адресах DFL-210 и DFL-700. NAT-T можно включить, можно выключить - работает и так и так.
Странность при этом - ровно одна - на страничке, отображающей наличие и состояние туннелей IKE ISA у маршрутизатора, стоящего за NAT не отображается вообще ничего. Как будто тунелей IKE нет вовсе ни одного.
2) а вот установить туннель IPSEC net-net от стоящего за NAT DFL-210 до линукс-роутера - не получается.
Пробовано - в режиме MAIN MODE как без NAT-T, так и с NAT-T. Результат одинаковый. Причина - линукс-роутер обнаруживает подмену адреса конца туннеля и посылает.
Вот таким образом:
18:01:54 pluto[7909] | state transition function for STATE_MAIN_I3 failed: INVALID_ID_INFORMATION
18:01:54 pluto[7909] "dop3" #1807: sending notification INVALID_ID_INFORMATION to 87.А.А.А:500
18:01:54 pluto[7909] "dop3" #1807: we require peer to have ID '87.245.183.93', but peer declares '10.0.0.111'
18:01:54 pluto[7909] "dop3" #1807: Main mode peer ID is ID_IPV4_ADDR: '10.0.0.111'
18:01:54 pluto[7909] | state object #1807 found, in STATE_MAIN_I3
18:01:54 pluto[7909] | peer and cookies match, provided msgid 00000000 vs 00000000
18:01:54 pluto[7909] | state hash entry 13
18:01:54 pluto[7909] | peer: 57 f5 b7 5d
18:01:54 pluto[7909] | RCOOKIE: 1b 2d 8a aa 7b ec 88 fc
18:01:53 pluto[7909] | ICOOKIE: 3b 5c 8f cc 17 c3 ea c6
18:01:53 pluto[7909] | *received 68 bytes from 87.А.А.А:500 on eth1
________
В это же время в лог DFL-210 регулярно валятся сообщения об успешном окончании первой фазы установления туннеля:
Bad logmsg: [2006-12-14 14:03:36] <6>FW: IPSEC: prio=1 Phase-1 [responder] between ipv4(udp:500,[0..3]=10.0.0.111) and ipv4(any:0,[0..3]=195.В.В.В) done.
________
Вопрос - как объяснить линуксовому роутеру, что неправильный адрес воторого конца туннеля надо игнорировать?

-- собственно, если я правильно понимаю, нужно перейти к конфигурации, когда опознавание концов туннеля ведется не по адресу, а по сообщаемому символическому имени. Как это сделать в линуксе - я знаю. Осталось выяснить как это сделать в DFL-210.
___
З.Ы. что такое Bad logmsg, которое приписывается к каждой второй строке в логе?

Собственно всё жду обещанные логи.
Имена не проставляются... только по IP

-- логи отправлены.