По внешнему виду, отличия есть — более ранняя выгляит дороже, смотрите сами:
Крепление БП с резьбовой муфтой, отдельная кнопка питания, быстрый доступ к сим-карте… Крч, как обычно, чем новее, тем дешевле… Не только москвич этим занимался, все занимаются 🙂
Но я не об этом. Главное отличие 106 и 107 ревизий, это то, что консоль в 106 висит на COM1, по этому для установки pfsense на него, образ надо скачивать вот так:
То есть, для R106, нужен обычный образ AMD64, для флешки, с Serial-консолью на COM1, дальше всё как обычно.
В этом образе уже настроен вывод картинки в консоль, и не надо будет извращаться с параметрами загрузки.
Далее, аналогично предыдущей статье, подключаем железку к любому компьютеру, вставляем флешку в usb-порт железки, и подаём питание
Выбираем терминал по умолчанию (vt100)
Всё, стартует установка pfsense, без каких-либо особых заморочек. Единственное — я настоятельно рекомендую выбирать ZFS в качестве файловой системы. По опыту, она сильно легче переживает перезагрузки по отказу питания
и я всегда делаю раздел swap равным объёму оперативной памяти
Всё, дальше выбираем диск для zfs, чуть ждём, перезагрузка и всё готово
Порты сетевушек распределяются почти (ibg0 — порт 1, igb1 — порт 0, дальше подряд) порядку:
У меня снова патч-корд в 6-м порту, по этому я выбираю в качестве LAN-интерфеса igb5, назначаю ему ip-адрес и всё
pfsense установлен, можно настраивать.
И первое, что надо сделать, это заставить pf запомнить, что консоль на COM2, иначе, после отключения питания, консоль будет недоступна.
так что сразу, как только попал в браузер, возвращаюсь в консоль, где:
# vi /boot/loader.conf.local
comconsole_port="0x2f8"
сохранить, выйти (:wq), и можно смело перезагружать и выключать не боясь потерять консольный доступ.
Для того, чтобы ikev2 без головной боли работал на клиентах, серверу всегда нужен валидный сертификат от реального центра сертификации. Использовать самоподписанные и импортировать CA на всех клиентах то ещё развлечение, по этому
Добавьте запись в DNS, со ссылкой на внешний айпшиник pfsense. Типа vpn.example.com или ещё как-то
Установите в pfSense расширение acme, которое автоматизирует получение бесплатных сертификатов от Let’sEncrypt. Там всё достаточно просто и очевидно.
Получите бесплатный сертификат. Я делал это с проверкой через DNS, что требует добавления текстовой записи вида _acme-challenge.vpn.exmaple.com в DNS
Запомните на будущее, что клиент должен обращаться к серверу только по созданному и указанному в сертификате доменному имени (то самое vpn.example.com)
Авторизация
Для авторизации логично использовать стандартный доменный пароль пользователей, это облегчает жизнь администратору :), но EAP-MSCHAPv2 авторизация не поддерживает прямое обращение к LDAP, т.к. шифрует логин и пароль. Зато шифрованные пароли хорошо поддерживает RADIUS, а Windows умеет в RADIUS, по этому:
Создайте в AD группу, в которую будут входить пользователи VPN. В отличие от LDAP, в pfsense, RADIUS-метод управляет на основе групп, а не на основе контейнеров
Настройте Microsoft NPS по инструкции от NetGate Не забудьте сохранить в блокнот «общий секрет» из мастера — он понадобится при настройке pfSense
В целом, на сайте Netgate есть очень качественный пример настройки, который можно использовать «один в один», но сначала надо подготовить авторизацию через LDAP (из Active Directory).
В Windows для этого ничего делать не надо, кроме создания пользователя для связи, а в pfSense настроить связку с LDAP по вот этой инструкции
Чтобы не морочиться с тем, почему не работает, важно правильно ввести имя пользователя в поле «Bind credentials».
Инструкция рекомендует использовать либо короткую %username%, либо каноническую «CN=username,CN=Users,DC=domain,DC=suffix»
В реальной жизни, работает нотация username@domain.suffx (bob@example.local)
Ещё один важный момент — авторизация в LDAP в актуальном pfSense управляет доступом не на основе групп пользователей, а на основе контейнеров (CN, OU) в вашей доменной структуре, так что доступ получат все пользователи указанного в конфигурации LDAP подразделения (контейнера, CN, OU)