[nycbug-talk] PFSense Talk Followup, Fwd: igb(4) quad port patch for 7.x
nycbug at chrisbuechler.com
Thu Mar 4 19:57:09 EST 2010
On 3/4/2010 12:11 PM, Isaac Levy wrote:
> Thought I'd post this here for the record, since a number of people asked if I could send them the fix...
> My plan is to:
> 1) immeadiately foreword this on to the folks who now manage those boxes
> 2) see if I cant' get this pushed back over to the PFSense folks, in an attempt to propogate the patch using the FreeBSD 7.x base,
The next release, 2.0, is being built off RELENG_8 (what will be 8.1),
which should have that already. Not likely to be another release on
Nicely done presentation Ike, thanks for promoting the project!
Some comments after listening to the talk (I missed some things,
listening to it in the background while working on other things, feel
free to follow up with questions):
1) IPv6 - that's likely to be the first thing that goes in after the 2.0
release. Just hasn't been a priority compared to many other things
because it's not available outside of tunneling for 99.99% of our user
base. That's starting to change though.
2) plain text passwords in config - that's from m0n0wall and we've kept
the same, anything that must be used in plain text (mpd (PPTP, PPPoE),
dynamic DNS) is stored in plain text. Those cannot be hashed. Explained
further here: http://doc.m0n0.ch/handbook/faq-plaintextpass.html It's
impossible to securely store those, so rather than obscure things in an
easily reversible format, we keep it blatantly obvious that the config
file has sensitive data and needs to be appropriately secured.
3) States on failover - states are (almost) fully preserved during
failover, that's the entire purpose of pfsync. There will be some loss
of states inevitably but you'll get the vast majority of them. The
primary is always syncing to the secondary, and vice versa. And when
your primary comes back up after rebooting or replacing hardware or
whatever, it gets a full state table sync from the secondary.
4) NAT reflection - in general, NAT reflection is supported, it's ugly
as it's just a bunch of netcat instances that forward traffic back in
(as the source must also be rewritten, and it gets looped through the
firewall). The better option is split DNS, but reflection does work fine
(it's disabled by default). The exclusion, which is the context it was
talked about in, is with server load balancing. There are options there,
depending on exactly how the setup works, but they usually involve
creating a separate load balancing pool listening on an internal IP and
using split DNS.
5) haproxy - noted this was mentioned, there's a relatively new package
for haproxy, a much more capable load balancer than the basic slbd
that's built in. It is relatively new but it's being used in production
and seems to be working fine. It's the best haproxy GUI out there from
what I've seen (tried looking at a number of others to get ideas as we
were designing things, ended up with something unlike what anyone else
has as no one else has done even a remotely good job of putting together
a full GUI for it). If you're going to try it, I'd recommend
haproxy-dev, as it's soon to be moved over to haproxy.
That's what I caught at least. If there were any questions that went
unanswered, feel free to ask.
I'll be at NYCBSDCon this year, look forward to seeing a number of you
whom I've met in the past at BSDCan, and meeting others.
We're also having a training tutorial at BSDCan this year for those of
you who can make it up there.
More information about the talk