L2TP/IPsec
-
если честно, уже раздражает этот ответ - "Ставьте OpenVPN и забудьте про l2tp"
вот ситуация - 100 юсеров подключались к Microsoft ISA сервер, который мы, слава тебе Господи, наконец то удалили.
у всех юсеров все настроено для подключения по l2tp/ipsec.вот мы переходим на Pfsense. все хорошо и замечательно, ну вот незадача - не работает L2tp/ipsec снаружи. и вы предлагаете ста юсерам перенастроить все, да и еще и сказать - теперь вы будете вводить имя пользователя и пароль…
да и они сами пальцем не пошевелят, чтоб что-то там перенастроить. т.е. придется ко всем подключатся и настраивать.
и ладно бы в Pfsense не было L2tp сервера, я бы сидел и помалкивал, так он же там есть) и даже есть мануал по его настройке, и он почти работает, просто проблема где-то в NAT, потому как на LAN интерфейс l2tp/ipsec клиент подключается... вот, что огорчает и заставляет писать сюда :)
PS - не обращайте внимания - крик души )
-
если честно, уже раздражает этот ответ - "Ставьте OpenVPN и забудьте про l2tp"
Это болезнь всех русскоязычных форумов :) Лучше на английском информацию искать…
Проблему подтверждаю - бьюсь второй день, безрезультатно. Стоит последняя версия pfSense - 2.3.2_1.
Пробовал разные клиенты: Windows 8.1 из-за NAT, Windows 8.1 через прямое соединение, Android через 3G/4G.
Добавлял правила для WAN, менял PSK Identifier с allusers на any и обратно, колдовал с алгоритмами шифрования, менял подсети - результат один: не подключается, на клиенте Windows ошибка 809 (если установить некорректные алгоритмы, ошибка меняется на 789, но это легко поправимо).
Ах да, внутренняя подсеть 192.168.200.0/24, шлюз для L2TP - 192.168.201.1, подсеть для L2TP - 192.168.201.128/25.
Настраивал по документации с оф.сайта (https://doc.pfsense.org/index.php/L2TP/IPsec), опыт настройки различного сетевого оборудования немалый, в IPSec разбираюсь.
Туннели на той же машине прекрасно работают, а L2TP - ни в какую.Вот кусок лога при подключении:
Oct 20 23:40:52 pfSense charon: 14[IKE] 5.5.5.5 is initiating a Main Mode IKE_SA
Oct 20 23:40:52 pfSense charon: 14[IKE] <8> 5.5.5.5 is initiating a Main Mode IKE_SA
Oct 20 23:40:52 pfSense charon: 14[ENC] <8> generating ID_PROT response 0 [ SA V V V V ]
Oct 20 23:40:52 pfSense charon: 14[NET] <8> sending packet: from 10.10.10.10[500] to 5.5.5.5[500] (156 bytes)
Oct 20 23:40:52 pfSense charon: 08[NET] <8> received packet: from 5.5.5.5[500] to 10.10.10.10[500] (260 bytes)
Oct 20 23:40:52 pfSense charon: 08[ENC] <8> parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
Oct 20 23:40:52 pfSense charon: 08[IKE] remote host is behind NAT
Oct 20 23:40:52 pfSense charon: 08[IKE] <8> remote host is behind NAT
Oct 20 23:40:52 pfSense charon: 08[ENC] <8> generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
Oct 20 23:40:52 pfSense charon: 08[NET] <8> sending packet: from 10.10.10.10[500] to 5.5.5.5[500] (244 bytes)
Oct 20 23:40:52 pfSense charon: 08[NET] <8> received packet: from 5.5.5.5[4500] to 10.10.10.10[4500] (68 bytes)
Oct 20 23:40:52 pfSense charon: 08[ENC] <8> parsed ID_PROT request 0 [ ID HASH ]
Oct 20 23:40:52 pfSense charon: 08[CFG] <8> looking for pre-shared key peer configs matching 10.10.10.10…5.5.5.5[192.168.0.2]
Oct 20 23:40:52 pfSense charon: 08[CFG] <8> selected peer config "con1"
Oct 20 23:40:52 pfSense charon: 08[IKE] IKE_SA con1[8] established between 10.10.10.10[10.10.10.10]…5.5.5.5[192.168.0.2]
Oct 20 23:40:52 pfSense charon: 08[IKE] <con1|8>IKE_SA con1[8] established between 10.10.10.10[10.10.10.10]…5.5.5.5[192.168.0.2]
Oct 20 23:40:52 pfSense charon: 08[IKE] scheduling reauthentication in 27961s
Oct 20 23:40:52 pfSense charon: 08[IKE] <con1|8>scheduling reauthentication in 27961s
Oct 20 23:40:52 pfSense charon: 08[IKE] maximum IKE_SA lifetime 28501s
Oct 20 23:40:52 pfSense charon: 08[IKE] <con1|8>maximum IKE_SA lifetime 28501s
Oct 20 23:40:52 pfSense charon: 08[ENC] <con1|8>generating ID_PROT response 0 [ ID HASH ]
Oct 20 23:40:52 pfSense charon: 08[NET] <con1|8>sending packet: from 10.10.10.10[4500] to 5.5.5.5[4500] (68 bytes)
Oct 20 23:40:52 pfSense charon: 12[NET] <con1|8>received packet: from 5.5.5.5[4500] to 10.10.10.10[4500] (332 bytes)
Oct 20 23:40:52 pfSense charon: 12[ENC] <con1|8>parsed QUICK_MODE request 1 [ HASH SA No ID ID NAT-OA NAT-OA ]
Oct 20 23:40:52 pfSense charon: 12[IKE] received 250000000 lifebytes, configured 0
Oct 20 23:40:52 pfSense charon: 12[IKE] <con1|8>received 250000000 lifebytes, configured 0
Oct 20 23:40:52 pfSense charon: 12[ENC] <con1|8>generating QUICK_MODE response 1 [ HASH SA No ID ID NAT-OA NAT-OA ]
Oct 20 23:40:52 pfSense charon: 12[NET] <con1|8>sending packet: from 10.10.10.10[4500] to 5.5.5.5[4500] (204 bytes)
Oct 20 23:40:52 pfSense charon: 12[NET] <con1|8>received packet: from 5.5.5.5[4500] to 10.10.10.10[4500] (60 bytes)
Oct 20 23:40:52 pfSense charon: 12[ENC] <con1|8>parsed QUICK_MODE request 1 [ HASH ]
Oct 20 23:40:52 pfSense charon: 12[IKE] CHILD_SA con1{26} established with SPIs c1933abc_i 0e115774_o and TS 10.10.10.10/32|/0[udp/l2f] === 5.5.5.5/32|/0[udp/l2f]
Oct 20 23:40:52 pfSense charon: 12[IKE] <con1|8>CHILD_SA con1{26} established with SPIs c1933abc_i 0e115774_o and TS 10.10.10.10/32|/0[udp/l2f] === 5.5.5.5/32|/0[udp/l2f]
Oct 20 23:41:27 pfSense charon: 05[NET] <con1|8>received packet: from 5.5.5.5[4500] to 10.10.10.10[4500] (76 bytes)
Oct 20 23:41:27 pfSense charon: 05[ENC] <con1|8>parsed INFORMATIONAL_V1 request 380039615 [ HASH D ]
Oct 20 23:41:27 pfSense charon: 05[IKE] received DELETE for ESP CHILD_SA with SPI 0e115774
Oct 20 23:41:27 pfSense charon: 05[IKE] <con1|8>received DELETE for ESP CHILD_SA with SPI 0e115774
Oct 20 23:41:27 pfSense charon: 05[IKE] closing CHILD_SA con1{26} with SPIs c1933abc_i (750 bytes) 0e115774_o (0 bytes) and TS 10.10.10.10/32|/0[udp/l2f] === 5.5.5.5/32|/0[udp/l2f]
Oct 20 23:41:27 pfSense charon: 05[IKE] <con1|8>closing CHILD_SA con1{26} with SPIs c1933abc_i (750 bytes) 0e115774_o (0 bytes) and TS 10.10.10.10/32|/0[udp/l2f] === 5.5.5.5/32|/0[udp/l2f]
Oct 20 23:41:27 pfSense charon: 13[NET] <con1|8>received packet: from 5.5.5.5[4500] to 10.10.10.10[4500] (84 bytes)
Oct 20 23:41:27 pfSense charon: 13[ENC] <con1|8>parsed INFORMATIONAL_V1 request 2453243046 [ HASH D ]
Oct 20 23:41:27 pfSense charon: 13[IKE] received DELETE for IKE_SA con1[8]
Oct 20 23:41:27 pfSense charon: 13[IKE] <con1|8>received DELETE for IKE_SA con1[8]
Oct 20 23:41:27 pfSense charon: 13[IKE] deleting IKE_SA con1[8] between 10.10.10.10[10.10.10.10]…5.5.5.5[192.168.0.2]
Oct 20 23:41:27 pfSense charon: 13[IKE] <con1|8>deleting IKE_SA con1[8] between 10.10.10.10[10.10.10.10]…5.5.5.5[192.168.0.2]</con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8></con1|8>Здесь 5.5.5.5 - клиент, 10.10.10.10 - адрес на WAN-интерфейсе. Подключение прямое - белый IP выдает провайдер.
В логах L2TP - тишина. Служба сообщает об успешном запуске и ожидании подключений. Но ни одного подключения нет…
Правила All-To-All в секциях IPSec и L2TP добавлял, порт 1701 UDP открыт (проверял с помощью nmap).Судя по логам, канал IPSec успешно создается, но до mpd ничего не доходит (в веб-интерфейсе для правила L2TP значится 0/0).
По мне, так это какой-то баг...
-
Все, вопрос снимается. Они на странице настройки L2TP/IPsec в вики написали: Users have reported issues with Windows L2TP/IPsec clients behind NAT. If the clients will be behind NAT, Windows clients will most likely not function. Consider an IKEv2 implementation instead.
По отзывам англоязычной аудитории, работает подключение только с iOS или напрямую (без NAT). К сожалению, проверить не на чем :(
Так что настраиваем IKEv2: https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2 -
Так что настраиваем IKEv2:
Настроил по этой инструкции, виртуальную сеть указал 192.168.32.0/24, в НАТ аут стоит авто и эта виртуальная сеть имеется в списке. На клиенте маршруты сети удалённого офиса (192.168.1.0/24) не прописались. Вопрос: как объявить маршруты для удалённых клиентов?
-
Так что настраиваем IKEv2:
Настроил по этой инструкции, виртуальную сеть указал 192.168.32.0/24, в НАТ аут стоит авто и эта виртуальная сеть имеется в списке. На клиенте маршруты сети удалённого офиса (192.168.1.0/24) не прописались. Вопрос: как объявить маршруты для удалённых клиентов?
Или используете это соединение как маршрут по умолчанию, или дописываете вручную
-
PbIXTOP, Можно конечно и так, но это ведь не цивилизованно, в OpenVPN например указываешь local network и remote network и всё, маршрутизируется на "Ура".
Может есть ещё у кого мысли, как средствами сервера решить доставку верного маршрута? -
ни в L2TP, ни в IPsec такая возможность не предусмотрена.
Вы можете попробовать воспользоваться протоколами OSPF или RIP для назначения маршрутов на конечные устройства. -
У меня к стати вообще почему-то не указан удалённый шлюз, видимо накосячил в настройке. Где мог напортачить?
PS Параметр "Provide a list of accessible networks to clients" разве не должен предоставлять клиенту маршрут?
 -
Хм. Вполне возможно (?)
https://forum.pfsense.org/index.php?topic=127457.0
http://cocoontech.com/forums/blog/29/entry-454-pfsense-vpn-easy-peasy-way/
https://boredwookie.net/blog/m/how-get-pfsense-ipsec-vpn-work-bb10 -
Настроил на другом роутере, тоже не выдаёт шлюз по умолчанию. Кому помешал PPP сервер в pfsense, не всем нужна лютая безопасность?! Остаётся один вариант, переходить на OpenVPN?
 -
Остаётся один вариант, переходить на OpenVPN?
Как рабочий вариант - да.
Немного лирики. Случай из недавнего прошлого.
Очередной Ipsec site-to-site туннель (остальные прекрасно работают с тем же ПО (не pfSense в центре и аналогичным оборудованием в филиалах) поднимается и работает. Но ходят по нему только пинги (нужные порты открыты, проверено телнетом и пр.)
Попытки решать вопрос с провайдером, попытки менять MTU\MSS\MRU вопрос не решили. Как временное решение перешли на OpenVPN, но, чувствую, решение останется постоянным. -
site-to-site туннель
Site2site используем давно средствами OVPN, вполне устраивает. Site2client удобно было всегда с помощью стокового клиента Windows, без доп ПО.
-
Согласен, clientless VPN удобно. Однако встречал и тут и не тут, что есть трудности с подключением клиента Windows из-за NAT, а клиент почти всегда за NAT.
-
2 Ilyuha
А тип туннеля - tun ? Точно не tap ?
