Это https соединения с серверами google оставшиеся после блокировки каким то правилом

@nomeron:

setenv PACKAGESITE ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/8.1-RELEASE/packages/Latest

Вот так правильно
setenv PACKAGESITE ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/8.1-RELEASE/packages/Latest/
+перегрузка по окончанию

@tim2000:

Буквально на прошлой неделе заметил, что проброс перестал работать, ранее работал норм. Конфиг не менял. Ребут не спасал.
Удалил все правила этого касающиеся, создал заново - всё заработало.

надо будет попробовать.

У меня такая же проблема. Решить пока не удалось. Если чего раскопаешь-отпиши плиз

@NegoroX:

не там, надо на закладке    General     строка  Bypass proxy for these source IPs

Спасибо!

@dvserg:

Но тут есть важные различия:

Разные IP адреса LAN/WAN списки юзеров

И есть одна огромная проблема безопасности взаимодействия этих машин. На CARP это решается на физическом уровне.
В принципе идея решаемая. Но другой вопрос, кто и зачем возьмется ее решать?

Согласен, не частая задача… просто изначально думал узнать о такой возможности, т.е. есть ли она или это не реализовано в данном релизе ([2.0.1-RELEASE]), да и думаю в последующих, по скольку достаточно редко встречаются такие вопросы =(

Сейчас поставил посмотреть на виртуалку. Сборка на основе pfsense 2.0-alpha (FreeBSD 8.0-RC1). Там только DNS и  DHCP сервера. НАТа нет. Настроек минимум. Только правила интерфейсов. На ВАН преднастроены правила DNS. Да судя по всему это tinyDNS

А для какой цели?  Вы можете назвать их как угодно (LAN, WAN, WIFI и т.п.)насколько я понимаю это "Alias", но система их определяет исходя из контроллера(RE0 - Realtek, SIS0 - SIS и т. п.).

2 dvserg

Хочу попробовать клиентский гипервизор.

тыц.

Есть ещё триальный Citrix XenClient 2.

меня тоже это интересует.
Хочется сделать аналогию принтесервера на роутерах.
Вот пункты, как я вижу:

принтер подключается по USB к коробке с pfsense'ом; После этого на адрес сенса (192.168.2.1 и на определенный порт {9000}) отправляем печать по одному из двух протоколов (LPR или Raw).

как и в какой последовательности что надо сделать\поставить чтобы так заработало?

@Mavric:

… Проще Transmission вынести за pfSense...

Ну вот так и делайте…

[global]
netbios name = Pfsense
workgroup = WORKGROUP 
server string = Pfsense
security = SHARE
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=65536 SO_SNDBUF=65536
interfaces = sk0 run0
bind interfaces only = yes
os level = 39
encrypt passwords = yes
oplocks = no
level2 oplocks = no
kernel oplocks = no
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
 
[public]
    comment = %h Shared Public Directory
    path = /mnt/disk
    force directory mode = 0777
    force create mode = 0777
    force group = wheel
    force user = root
    guest ok = Yes
    guest only = Yes
    public = yes
    writeable = yes
    read only = no

мой конфиг самбы
подправлен для более шустрой работы по сетке (20 МБайт/сек)

шара только на внутреннюю сетку ( interfaces = sk0 run0 )
ну и вайфай

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=65536 SO_SNDBUF=65536
про эти параметры можете отдельно погуглить и поиграть значениями чтобы выбрать оптимальный буфер

По 443 порту в прозрачном режиме сквид не может работать, как и с ftp. Такое правило ради интереса я пробовал - не работает.
Трафик по 443 порту пришлось пустить в обход сквида. А правилами файрвола я закрыл доступ из вай-фай к локальной сети за исключением некоторых адресов.

Вопрос как разделить людей на группы, т. е. есть у меня ограничение на скачку не более 260 Мб, но нужно некоторым людям разрешить больше? Добавить в "Bypass proxy for these source IPs" не вариант, т. к. это слишком много для них.

А можно ли просто отключить кэширование, если это оно?

урл не подскажу, а привязка у меня по макам, и все равно какой ип.

Спасибо большое!

Полностью решил все проблемы просто переходом с 2.0.1-RELEASE-amd64 на 2.0.1-RELEASE-i386. Рядом поставил чистую установку i386, проверил несколько проблемных функций - заработало. Сделал еще раз чистую установку amd64 - не работает. Заменил версию на шлюзе на i386 и все вышеописанное работает (и разрешение на echo request, и доступ удаленному пользователю к проксе через впн и НАТ для впн клиента). Так же на amd64 не получается дать доступ к веб интерфейсу любому другому пользователю кроме admin, что при тех же настройках работает на i386 версии.

@pigbrother:

Остается вопрос:

Перевод Firewall: NAT: Outbound в режим Manual Outbound NAT rule generation.
Чем это грозит мне в дальнейшем? Не появится ли необходимость создавать\редактировать в правила Outbound NAT при внесении изменений в Firewall, открытии портов и т.д

В случае с пробросом портов правила в Firewall: Rules формируются автоматом. А так, возможно, прийдется прописывать правила в NAT вручную. Далеко не часто, но прийдется.