L2TP/IPsec
-
Все, вопрос снимается. Они на странице настройки 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" разве не должен предоставлять клиенту маршрут?
![QIP Shot - Screen 2017.03.27 16-51-16.png](/public/imported_attachments/1/QIP Shot - Screen 2017.03.27 16-51-16.png)
![QIP Shot - Screen 2017.03.27 16-51-16.png_thumb](/public/imported_attachments/1/QIP Shot - Screen 2017.03.27 16-51-16.png_thumb) -
Хм. Вполне возможно (?)
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?
![QIP Shot - Screen 2017.03.28 10-16-44.png](/public/imported_attachments/1/QIP Shot - Screen 2017.03.28 10-16-44.png)
![QIP Shot - Screen 2017.03.28 10-16-44.png_thumb](/public/imported_attachments/1/QIP Shot - Screen 2017.03.28 10-16-44.png_thumb) -
Остаётся один вариант, переходить на 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 ?