IPSEC на IKEv2 с EAP-MSCHAPv2 пинги не ходят дальше pfsense
-
Доброго времени суток!
- Поднял IPSEC на IKEv2 с EAP-MSCHAPv2. Все делал в точности как описано тут Подключение клиента проходит успешно. Пингую ip сетевой карты LAN. Но устройства в локальной сеть никак. В правилах фаервола уверен, даже для ipsec интерфейса разрешил все протоколы везде.
- Не могу назначить клиентам постоянные адреса.
Если верить описанию, то пользователю uname должен быть присвоен ip 192.168.66.144
-
@humaxoid
Здр
включайте tcpdump в разных точках и смотрите , где теряются пакеты
Лично я решил проблему присваивания IP адресов через Freeradius -
Доброго.
-
а какие у Вас адреса интерфейсов, и в особенности с маски сетей? Что стоит в Phase 2 Entries в General Information?
-
насколько я помню, в IPSec pfSense для mobile clients невозможно назначать постоянные IP адреса. Да и как Вы это себе представляете? По какому критерию? Один и тот же пользователь может заходить одновременно с разных IP адресов.
P.S. Воспринимать интерфейс pfSense на русском очень непривычно. Выбирая его, Вы в некотором смысле отказываетесь от всего международного форума.
P.P.S. Мне бы вашу уверенность в правилах фаервола, когда что-то не работает...
-
-
-
Mode- Tunnel IPv4
Local net - LAN subnet
NAT/BINAT translation - None -
VPN/IPsec/Pre-Shared Keys/Edit
Virtual Address Pool - 192.168.xx.xx/32
Снизу пояснение: Optional. If used, must be IPv4 address. If left blank, "Virtual Address Pool" of "Mobile Clients" will be used.
В фаерволе собственно и указывать нечего
-
-
Local net - LAN subnet
А адрес?
И на мой вопрос
а какие у Вас адреса интерфейсов, и в особенности маски сетей?
Вы не ответили. Интересуют LAN и DMZ.
Virtual Address Pool - 192.168.xx.xx/32
Пожалуйста, без xx, *,.. etc.
-
@yarick123
LAN Subnet - 192.168.1.0/24
Адрес лан интерфейса 192.168.1.1
DMZ на данный момент не интересует.Сделал вот что:
- Клиентам назначаем адреса из другой подсети, а именно 192.168.2.0/24, т.е
отличной от локальной 192.168.1.0/24. - Добавил у клиента маршрут до локальной подсети route -p 192.168.1.0 mask 255.255.255.0 192.168.1.1 . ЛАН интерфейс pfsense стал отвечать на запросы. Но устройства в локальной сети на запросы так и не отвечают.
Завтра попробую добавить маршруты на устройствах к которым хочу получить доступ.
- Клиентам назначаем адреса из другой подсети, а именно 192.168.2.0/24, т.е
-
DMZ на данный момент не интересует.
Если пересекаются сети, то очень даже интересует.
- Добавил у клиента маршрут до локальной подсети route -p 192.168.1.0 mask 255.255.255.0 192.168.1.1 . ЛАН интерфейс pfsense стал отвечать на запросы.
Это должен делать сам VPN client (software). Похоже, у Вас проблемы с роутингом на клиенте, что является следствием ошибки в конфигурации IPsec.
А вот ещё такой вопрос. Какой у Вас адрес локальной сети на клиенте, когда Вы работаете без VPN?
Посмотрите, что у Вас с галкой в "Network ListProvide" в "Mobile Clients" в разделе "Client Configuration (mode-cfg)". В моём понимании в вашем случае эта опция должна быть выключена.
Попробуйте прописать в Phase 2 Entries в General Information "Network" с адресом 0.0.0.0/0 в качестве "Local net", отключив при этом "Network ListProvide" в "Mobile Clients" в разделе "Client Configuration (mode-cfg)".
-
@humaxoid
Здр
Хочу повторить второй раз свой совет - используйте tcpdump в различных точках туннеля.- точка - wan интерфейс ( esp пакеты)
- точка - enc0 интерфейс
- точка - lan интерфейс
И сразу видно , где что пришло и ушло
И попробуйте , как Вам советуют , настроить фазу 2 с адресом 0.0.0.0/0 , тогда весь трафик клиента должен идти через туннельИ использовать адресацию 192.168.1.0/24 внутри корпоративной сети - не самое лучшее решение
-
Спасибо коллеги!
Tcpdump_ом как раз и пользовался. Запустил на пф, смотрел в обе стороны по очереди.
Вопрос разрешен, но разрешен таки не совсем так как хотелось бы. Спотыкач был в двух вопросах:-
Я задал мобильным клиентам туже подсеть что и локальная. А надо было клиентам задать любую другую (свободную). Хотя до этого юзал L2TP. Там вообще пофигу.
-
Еще надо было прописать маршруты на обоих сторонах, а не только со стороны клиента.
ДМЗ не пересекается. Более того, я его на время отключил. Локальный адрес на клиенте белый, выданный провайдером. Смотрит напрямую в инет.
"Network ListProvide" - стоит галка.
По второй фазе установил сеть 0.0.0.0/0
Ничего не изменилось. -
-
@humaxoid said in IPSEC на IKEv2 с EAP-MSCHAPv2 пинги не ходят дальше pfsense:
Я задал мобильным клиентам туже подсеть что и локальная. А надо было клиентам задать любую другую (свободную).
На это и был ориентирован вопрос:
Какой у Вас адрес локальной сети на клиенте, когда Вы работаете без VPN?
Еще надо было прописать маршруты на обоих сторонах, а не только со стороны клиента.
Странно это. Что с одной, что с другой стороны. Это говорит о том, что либо у Вас-таки остались проблемы с конфигурацией, либо Вы очень много чего не рассказали о сетях, которые используете. Ну, или используете pfSense 2.4.5 (до которого у меня не дошли руки) в котором возможно появились новые "баги".
-
@yarick123
Вернемся к теме. Все-же это не правильно когда каждому клиенту приходится прописывать маршрут руками. Если клиентов много, то это реально утомляет.
Пробовал на версиях 2.4.4 и 2.4.5, картина везде одинаковая. Вот что я заметил.
У клиента смотрим свойства соединения. Видим что нет адреса шлюза.Возможно что его и не должно там быть. Но тогда не будет правильного маршрута.
Соответственно и пакеты не дошли до места назначения. Если прописать маршрут вручную с указанием шлюза, метрики и правильного интерфейса, то все нормально. Сразу увидели ответ по пингам.
Все настройки перерыл, все тщетно. Я так понимаю что pfsense для работы ipsec использует strongswan? Может есть возможность где-то в конфигах указать шлюз для клиента? Указать правильный маршрут клиенту с указанием шлюза? -
@humaxoid
Классический IPSEC работает немного не так , ему не нужен адрес шлюза
Strongswan (сторона PFSense) и второй IKE менеджер (сторона клиента) передают данные ядру , а ядро выставляет ловушки для перехвата "интересного" трафика , шифрует его и передает его в ESP пакетах.
Эти ловушки Вы можете видеть на закладке SPD. Вы это указываете в настройках фазы 2.
Все то что не попадает под критерии "интересного" трафика ,обрабатывается в обычном режиме и не шифруется.обратите внимание на этот текст, написанный Вам чуть выше
Странно это. Что с одной, что с другой стороны. Это говорит о том, что либо у Вас-таки остались проблемы с конфигурацией, либо Вы очень много чего не рассказали о сетях, которые используете. Ну, или используете pfSense 2.4.5 (до которого у меня не дошли руки) в котором возможно появились новые "баги".
Покажите настройки фазы 2
и адресацию сетей клиентов -
-
@humaxoid
При таких настройках фазы 2 весь трафик клиента пойдет через туннель. Никакие маршруты "ручками " прописывать не надо .