Re: What is your favourite/best firewall on FreeBSD and why?

On May 24, 2014, at 7:16 PM, Peter Wemm <[e-mail]> wrote:

> On 5/23/14, 11:12 PM, Charles Sprickman wrote:
>> On May 23, 2014, at 5:11 PM, Peter Wemm <[e-mail]> wrote:
>> =

>>> On 5/23/14, 3:04 AM, Dr Josef Karthauser wrote:
>>>> On 23 May 2014, at 10:00, G. Paul Ziemba <[e-mail]>=
 wrote:
>>>> =

>>>>> [e-mail] (Lucius Rizzo) writes:
>>>>> =

>>>>>> Ultimately, outside configuration differences all firewalls are esse=
ntially
>>>>>> serve the same purpose but I wonder what is your favorite and why? If
>>>>>> you were to run FreeBSD in production, which of the three would you
>>>>>> choose? IPFilter, PF or IPFW?
>>>>> I switched to pf about seven months ago as I began to need to
>>>>> manage bandwidth for specific classes of traffic (for example,
>>>>> prevent outbound mailing list email from saturating the link
>>>>> and reserve some bandwidth for interactive use).
>>>>> =

>>>>> The syntax is very close and the NAT configuration is simpler in pf.
>>>> Does the pfsync handle NAT tables.
>>>> Could I use it to build a resilient carrier grade NAT solution?
>>>> =

>>> Yes, pfsync includes NAT.  While we don't use NAT in the freebsd.org cl=
uster, we do use it on certain ipv6+rfc1918 machines and it does handle fai=
lover / recovery transparently.  We use it with carp.
>>> =

>>> Be aware that things can get a little twitchy if your switches have an =
extended link-up periods. Our Juniper EX switches and ethernet interfaces h=
ave a significant delay between 'ifconfig up' and link established.  This r=
equired some tweaks on the freebsd.org cluster but nothing unmanageable.  W=
e probably should boot them into a hold-down state while things stabilize a=
nd but we've taken the quick way out rather than doing it the ideal way.
>> Off-topic, but it sounds like you need the Juniper equivalent of the Cis=
co =93spanning-tree portfast=94 command on your switch interfaces that conn=
ect to end hosts.  The pause you see is part of STP where the switch port s=
its in learning mode from 5 to 30 seconds before going to forwarding mode. =
 This is important for inter-switch links, but not at all needed when you k=
now a port is only going to have a host plugged into it.
>> =

> =

> Indeed, I believe this is a legacy of when we had discrete switches chain=
ed together.  We've since switched to virtual chassis configurations so the=
re's only inter-switch forwarding via the backplane.  I've made a note to c=
heck this out when I'm physically present.
> =

> But it is something to be aware of if you're using carp in this configura=
tion as new members will believe they are the master for a short while and =
that does lead to drama as it converges.  =


Interesting.  I don=92t use carp as part of a firewall setup at all (yet), =
but I have a few cases where I use it for service redundancy.  I am beyond =
happy with how well it works in that scenario.  What is the behavior in a c=
arp=92d firewall configuration like you=92ve described?  New host comes up,=
 sees the port up (but forwarding is not active yet), becomes master, and t=
hen you have a period of time after the port starts forwarding where you ha=
ve two masters - what=92s the effect here?  Does traffic using the carp IP =
for a gateway end up basically randomly hitting both hosts in the pair unti=
l the =93false=94 master decides it=92s a slave again?  I assume pf acts od=
dly when pfsync is enabled and you have both hosts in a pair being active.

> This not a pf/carp problem though, more one that we haven't used the avai=
lable tools properly yet.

It seems like it could be fixed in carp though - I mostly deal with Cisco s=
witches, and the delay before a port starts forwarding is a default config.=
  There are also those that totally recommend leaving the STP defaults in c=
ase some junior network guy decides to plug something into the wrong port -=
 I believe it=92s possible to get a forwarding loop going with =93spanning-=
tree portfast=94 enabled.  But most server admins are very keen on enabling=
 the feature because no one wants to wait up to 30 seconds for a port to co=
me alive.  If the carp initialization could do a few checks beyond the basi=
c port status (for example, is at least one MAC address in the ARP table fo=
r the interface in question) and delay initializing until knowing for certa=
in an ethernet link is truly =93up=94, that might make things behave a bit =
better in environments like this.  Someone more clever than I could probabl=
y come up with a more elegant solution though. :)  I don=92t think it would=
 be improper to work around the scenario you describe, as it=92s pretty com=
mon once you move into =93enterprise=94 switching territory.

Sorry for continuing the OT, but I=92m curious about what is probably a fai=
rly common scenario.

Charles

> =

> -Peter
> =

> _______________________________________________
> [e-mail] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[e-mail]"

_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[e-mail]"