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

[Charles Sprickman]

On May 24, 2014, at 7:16 PM, Peter Wemm <peter at wemm.org> wrote:

> On 5/23/14, 11:12 PM, Charles Sprickman wrote:
>> On May 23, 2014, at 5:11 PM, Peter Wemm <peter at wemm.org> wrote:
>> 
>>> On 5/23/14, 3:04 AM, Dr Josef Karthauser wrote:
>>>> On 23 May 2014, at 10:00, G. Paul Ziemba <pz-freebsd-stable at ziemba.us> wrote:
>>>> 
>>>>> Lucius.Rizzo at The.ie (Lucius Rizzo) writes:
>>>>> 
>>>>>> Ultimately, outside configuration differences all firewalls are essentially
>>>>>> 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 cluster, we do use it on certain ipv6+rfc1918 machines and it does handle failover / 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 have a significant delay between 'ifconfig up' and link established.  This required some tweaks on the freebsd.org cluster but nothing unmanageable.  We probably should boot them into a hold-down state while things stabilize and 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 Cisco “spanning-tree portfast” command on your switch interfaces that connect to end hosts.  The pause you see is part of STP where the switch port sits 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 know 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 chained together.  We've since switched to virtual chassis configurations so there's only inter-switch forwarding via the backplane.  I've made a note to check this out when I'm physically present.
> 
> But it is something to be aware of if you're using carp in this configuration 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’t 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 carp’d firewall configuration like you’ve described?  New host comes up, sees the port up (but forwarding is not active yet), becomes master, and then you have a period of time after the port starts forwarding where you have two masters - what’s the effect here?  Does traffic using the carp IP for a gateway end up basically randomly hitting both hosts in the pair until the “false” master decides it’s a slave again?  I assume pf acts oddly 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 available tools properly yet.

It seems like it could be fixed in carp though - I mostly deal with Cisco switches, and the delay before a port starts forwarding is a default config.  There are also those that totally recommend leaving the STP defaults in case some junior network guy decides to plug something into the wrong port - I believe it’s possible to get a forwarding loop going with “spanning-tree portfast” 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 come alive.  If the carp initialization could do a few checks beyond the basic port status (for example, is at least one MAC address in the ARP table for the interface in question) and delay initializing until knowing for certain an ethernet link is truly “up”, that might make things behave a bit better in environments like this.  Someone more clever than I could probably come up with a more elegant solution though. :)  I don’t think it would be improper to work around the scenario you describe, as it’s pretty common once you move into “enterprise” switching territory.

Sorry for continuing the OT, but I’m curious about what is probably a fairly common scenario.

Charles

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