Настройка
Я настроил pfSense 2.0.1 (64-битное изображение) в качестве хоста в Hyper-V. Как описано в других блогах, я должен был выполнить «ifconfig down deX», «ifconfig up deX», чтобы запустить и запустить сеть.
Сервер (HP под управлением Windows 2008 R2) оснащен двумя физическими сетевыми картами.
Первый физический сетевой адаптер (порт 1) не настроен на хосте (только как коммутатор Hyper-V, см. Далее).
Второй физический сетевой адаптер (порт 2) настроен с сетью для удаленного управления (стандартная сеть класса C). Я думаю, что обе сетевые карты подключены к одному и тому же коммутатору, и VLAN = по умолчанию (физическое подключение было выполнено моим поставщиком совместного размещения).
В Hyper-V определены следующие виртуальные сети:
внутренняя : внутренняя сеть виртуальной машины, используемая для связи между виртуальными машинами («ЛВС», соединяющая серверы Windows).
Интернет : виртуальная сеть, используемая в качестве WAN-соединения для pfSense. Эта сеть назначена первому физическому NIC (порт 1) сервера. Виртуальная сеть предназначена для Hyper-V и не используется совместно с хостом.
В моей настройке я использую pfSense в качестве межсетевого экрана, обращенного к Интернету, для пары виртуальных машин (серверов Windows), также работающих на одном хосте Hyper-V.
Ящики Windows используют pfSense в качестве шлюза по умолчанию, и я успешно загрузил обновления Windows на все виртуальные машины через брандмауэр pfSense - все работает гладко.
Для переадресации входящих служб pfSense настроен с 1-1 NAT для сопоставления IP-адресов интернет-провайдеров с внутренними 172.16.0.0/16 адресами в блоках Windows.
Проблема
Проблема, с которой я столкнулся, заключается в том, что после успешной работы с RDP-соединением по сети управления (порт 2) соединение просто умирает, и все сетевые соединения теряются для сервера и виртуальных машин. До возникновения проблемы я сделал два изменения конфигурации.
Перемещен управляющий IP-адрес с порта 1 на порт 2. Это изменение было успешно проверено путем повторного подключения RDP через час на новом интерфейсе (порт 2, как описано выше).
Сделал некоторые настройки на виртуальных IP-адресах в pfSense (необходим для 1-1 NAT).
Через несколько минут связь с машиной была потеряна.
Меня удивляет то, что соединение с сетью управления (порт 2) должно быть не затронуто Hyper-V, поскольку оно не интегрировано с Hyper-V. Однако, похоже, что происходит распространение ошибок от pfSense (с использованием NIC на порту 1).
Ранее сегодня у нас была похожая проблема при использовании только одного сетевого адаптера (порт 1 совместно используется Hyper-V / pfSense и хостом). Проблема, которую мы получили, заключалась в том, что когда pfSense был остановлен, мы могли пропинговать хост, и когда он был запущен снова, эхо-запрос перестал работать (никакого конфликта IP, как мы знаем).
PfSense устанавливается из ISO, и «спуфинг MAC-адреса» по умолчанию = выключен.
Поскольку проблема заключается в распространении между двумя физическими портами, я предполагаю, что это может быть связано с тем, что ARP работает неправильно.
Любые комментарии комментарии по этому вопросу очень ценятся.
/ J
Ответы:
Вы проверяли Event Viewer на W2008R2?
Может быть связано с максимальным количеством TCP-соединений, разрешенных Windows: https://technet.microsoft.com/en-us/library/cc759700%28WS.10%29.aspx
pfSense как программный маршрутизатор использует множество соединений, которые могут быть открыты, но не закрыты, состояние ожидания и т. д. Этот вид использования сети может достигать пределов по умолчанию для стека TCP, а окна могут закрываться или не разрешать больше соединений этого типа. Первое, что нужно сделать в этом случае, это проверить Event Viewer, чтобы увидеть, есть ли что-то, о чем там сообщается.
источник
Это больше похоже на проблему маршрутизации между pfSense и другими устройствами ...
Если вы используете виртуальные машины за pFSense в качестве брандмауэра, вы должны использовать их в другой подсети, нежели ПК на локальной сети. Возможно, вам придется включить дополнительный интерфейс в pfSense (скажем, LAN2), а затем сопоставить его в хосте виртуальных машин с частным коммутатором VS, который используют другие виртуальные машины. Или даже пометить трафик в vSwitch и иметь для него отдельный vlan.
Мне приходилось делать это много раз на VMWare. Также для ваших 1: 1 вам, возможно, придется добавить статическое сетевое сопоставление маршрутов для них в качестве примера. Я видел, как pfSe nse запутался в маршрутизации.
Таким образом, у вас есть ..
IINTERNET -> Wan0 -> pFSense -> ПК LAN1 ..
После этого вы можете лучше контролировать правила маршрутизации и брандмауэра.
Надеюсь, это поможет, ура ...
источник