Date: Sat, 24 May 2014 20:22:18 -0400 From: Charles Sprickman <spork@bway.net> To: Peter Wemm <peter@wemm.org> Cc: freebsd-stable@freebsd.org Subject: Re: What is your favourite/best firewall on FreeBSD and why? Message-ID: <D80A6730-0C6B-4FAE-AADC-CE77CB850FFE@bway.net> In-Reply-To: <5381283C.8010005@wemm.org> References: <20140520070926.GA92183@The.ie> <lln2o2$77d$1@usenet.ziemba.us> <FE050654-7AE7-4E5D-B191-9A620B9D61AD@tao.org.uk> <537FB96D.1040503@wemm.org> <542A7016-FEE2-418C-B1F1-2227378BB4C8@bway.net> <5381283C.8010005@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 24, 2014, at 7:16 PM, Peter Wemm <peter@wemm.org> wrote: > On 5/23/14, 11:12 PM, Charles Sprickman wrote: >> On May 23, 2014, at 5:11 PM, Peter Wemm <peter@wemm.org> wrote: >>=20 >>> On 5/23/14, 3:04 AM, Dr Josef Karthauser wrote: >>>> On 23 May 2014, at 10:00, G. Paul Ziemba = <pz-freebsd-stable@ziemba.us> wrote: >>>>=20 >>>>> Lucius.Rizzo@The.ie (Lucius Rizzo) writes: >>>>>=20 >>>>>> 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). >>>>>=20 >>>>> 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? >>>>=20 >>> 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. >>>=20 >>> 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 =93spanning-tree portfast=94 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. >>=20 >=20 > 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. >=20 > 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. =20 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 carp=92d firewall configuration like you=92ve 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=92s the effect here? Does = traffic using the carp IP for a gateway end up basically randomly = hitting both hosts in the pair until the =93false=94 master decides it=92s= 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=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 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 = =93up=94, 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=92t think it would be improper = to work around the scenario you describe, as it=92s pretty common once = you move into =93enterprise=94 switching territory. Sorry for continuing the OT, but I=92m curious about what is probably a = fairly common scenario. Charles >=20 > -Peter >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D80A6730-0C6B-4FAE-AADC-CE77CB850FFE>