athacker

HTTPS вы сможете заблокировать только по IP. Во всяком случае, используя только pfSense. Теоретически, squid может блокировать и HTTPS на уровне хостнейма сайта, но практически это нужно настраивать в конфиге руками, через веб-интерфейс это не решается, насколько я помню.

Динамическая маршрутизация спасёт благородного дона. Поднимите в обоих туннелях две BGP-сессии, анонсируйте в туннелях два маршрута в удалённую подсеть, только с разными приоритетами. Если отвалится один туннель -- маршрутизация перейдёт на другой. IPSec, кстати, лучше строить будет где-нибудь на loopback-адресе удалённой сети, чтобы этот адрес был доступен, независимо от того, через какой туннель доступна удалённая площадка.

Только не уверен, что PFSence умеет BGP. Возможно, придётся ставить чистую фрю.

Про pfSence не знаю, а чистая фря будет работать: https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi

Можно, но чревато проблемами. В частности, поддержка сети Hyper-V появилась только во FreeBSD 10.0, а pfSence, насколько я помню, до сих пор на базе FreeBSD 8.X. Но даже если они уже переползли на 9, это мало что меняет.

Чтобы работала сеть в виртуальной фре на Hyper-V, нужно подавать туда Legacy network adapters, и ещё их приходится дёргать после перезагрузки (т.е. делать ifconfig down/up), чтобы сеть поднялась в виртуалке. Бывает, что она сразу не поднимается. Также есть ограничение по размеру диска и по его типу. Т.е. thin provisioning для диска с виртуальной фрёй не прокатит, нужно будет делать fixed disk. У нас диски крашились с размером более 20 Гб -- фря выпадала в корку.

Если готовы мириться с этими граблями -- то тогда ставить можно. Но я бы рекомендовал сделать чистую фрю 10.1 -- она полностью поддерживает сеть Hyper-V и проблем никаких замечено не было.

Либо виртуализировать pfSence на чём-то ещё. На VMware или VirtualBox.

Лучше не пользоваться полу-аппаратными рейдами. они все с теми или иными прибабахами. Делайте честный софтверный, на базе geom mirror.