Обсуждение статьи тематического каталога: PBR на freeBSD посредством pf (freebsd pf firewall nat)Ссылка на текст статьи: http://www.opennet.me/base/net/pbr_pf_freebsd.txt.html
Блин фразу "ipfw + natd - использовать не рекомендую из-за запутанности правил и
связки natd + ipfw. При работе с ipfw+natd ttl вырастал до бешенных резмеров что привело к тому, что пинги ходили с задержками в 2-3 секунды" надо на баш отправить.
Да вообще, писал человек достаточно слабый :). Хотя я лично тоже не рекомендую natd, но всё-таки совсем по другим причинам :). А именно, natd очень не экономичен в плане ресурсов CPU. Да и вообще, тот же pf, лично по-моему, значительно более "мощный" (по функционалу) и удобный, чем ipfw.
>Да вообще, писал человек достаточно слабый :). Хотя я лично тоже не
>рекомендую natd, но всё-таки совсем по другим причинам :). А именно,
>natd очень не экономичен в плане ресурсов CPU. Да и вообще,
>тот же pf, лично по-моему, значительно более "мощный" (по функционалу) и
>удобный, чем ipfw.natd единственный под FreeBSD справляется с задачей nat для pptp соединений. PF этого не умеет до сих пор. Свистелок типа os detection и pfauth в ipfw нет, но их необходимость сомнительна. Функционала ipfw достаточно для любых реальных задач по обработке траффика, никакого "значительного" превосходства тут не может быть в принципе. На мой взгляд у всех unixlike файрволов сходный синтаксис и возможности. В плане производительности natd вероятно уступает in kernel реализациям, хотя насколько сильно лично я не измерял. Для средних размеров организации на современном железе ее хватает за глаза, ну а для магистралей существуют совсем другие решения. И еще надо заметить что ipfw часть FreeBSD, а PF всетаки порт с другой системы. В некоторых случаях ipfw оказывается гибче. Если есть желание почитайте http://nuclight.livejournal.com/
статьи такого уровня запудривают ньюбам моск, искажая их представление о ФриБСД вцелом.имхо:)