[nycbug-talk] PFSense Talk Followup, Fwd: igb(4) quad port patch for 7.x

[Chris Buechler]

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 
RELENG_7*.

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.

cheers,
Chris