Приветствую, коллеги!

Вопрос с серым IP решил. С белым IP IPSec туннель устанавливается. Но не работает L2TP. Пишет в логах все время l2tpclient_init но ни ошибок ни успешного результата нет. ЧТо делать, куда копать, чего смотреть?

Поскольку в DFL L2TP живет отдельно от IPSec, думаю, что прежде всего нужно убедиться, что маршруты/ правила позволяют трафику бегать на удаленную точку именно через IPSec. Нужно бы посмотреть, идут пакеты L2TP завернутыми в IPSec (ESP) или нет. Должен быть более приоритетный маршрут на удаленную точку через IPSec, чем просто через wan. Трудно что-либо определённее подсказать, сам такого не делал, смотрите логи на другой стороне также.

А вот встречный вопрос: какие правила маршруты нужно добавлять?

Сейчас стоит галка в IpSec - добавлять маршрут - соответственно в main добавляется:

Route tunnel_hp_ipsec pptp_server_hp_ip 90

Нужно ли что-то прописывать еще, например в Rules ?

На той стороне в логах ничего. IPSec-туннель поднимается, но до L2TP не доходит дело. Видимо DFL действительно не может установить соединение.

Правила вроде бы в таких случаях не нужны, она сама разрешает, если только в Adv Settings не меняли. А IPSec точно поднялся, В Status/IPSec SA есть?
Прошивка не русская случайно?

Спасибо!
Прошивка не русская. Туннель поднимается. В статусе есть и в логах на противоположной стороне.

Такой вопрос: а PING должен работать при поднятом туннеле в режиме Transport на remote_endpoint_ip? Сейчас при поднятии туннеля пинг перестает работать. Может просто вообще весь трафик при поднятии тоннеля перестает ходить, в том числе и l2TP поэтому не работает?

Кстати, меня начинает смущать галка

IPsec Before Rules: Pass IKE & IPsec (ESP/AH) traffic sent to the security gateway directly to the IPsec engine without consulting the ruleset.

Не означает ли это фактически правило Allow - в моем случае все равно нужны default-правила NAT, т.к. мой WAN IP и реальный внешний белый ip - разные вещи.

Имею в логах:

2014-03-14
22:12:52 Warning RULE
6000051 Default_Rule UDP tunnel_hp_ipsec
XXX.XXX.XXX.XXX
YYY.YYY.YYY.YYY 1701
1701 ruleset_drop_packet
drop
ipdatalen=85 udptotlen=85

XXX.XXX.XXX.XXX -IP-адрес той стороны
YYY.YYY.YYY.YYY - мой WAN

Видимо правила все-таки нужны...

Добавляю Allow-правило, получаю:

LocalUndelivered UDP tunnel_hp_ipsec
127.0.0.1
YYY.YYY.YYY.YYY 32961
1701 unhandled_local
drop
ipdatalen=85 udptotlen=85

Причем самое интересное, что при добавлении разрешающего правила XXX.XXX.XXX.XXX меняется на 127.0.0.1 и появляется unhandled_local drop. Видимо нужно не Allow, а SAT или NAT ?.. Только в обратную сторону..

Вроде бы, никакой NAT/SAT не нужен, это транспортный режим, Вы просто пересылаете пакеты между двумя точками с белыми IP, обернутые в ESP. Собственно туннель -- т. е. соединение двух сетей с приватными адресами делает L2TP. То, что пинг пропадает, говорит за то, что он идет под IPSec. Почему не возвражается -- может удаленная сторона просто не хочет отвечать на пинги из-под IPSec.
А вот с дропами непонятно. Как выглядит Ваше правило, разрешающее L2TP? Вы его на самый верх поставили? В свойчтвах L2TP правильно указан внешний адрес другой стороны?

Добавляю Allow на "все" :

Action: Allow
Service: all_services
Schedule: (None)

Source Interface: tunnel_hp_ipsec
Source Network: tunnel_hp_remote_endpoint_ip

Destination Interface: any
Destination Network: all-nets

Получаю:

LocalUndelivered

tunnel_hp_ipsec
XXX.XXX.XXX.XXX
YYY.YYY.YYY.YYY 1701
1701 unhandled_local
drop

Настройки L2TP:

Name: tunnel_hp_l2tp
Tunnel Protocol: L2TP
Remote Endpoint: tunnel_hp_remote_endpoint_ip
Remote Network: None

Может быть причина в том, что пакеты приходят на wan_ip, а должны как-то попадать в L2TP-сервер?..