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

Isaac Levy isaac at diversaform.com
Thu Mar 4 20:16:07 EST 2010


Amazing,

On Mar 4, 2010, at 7:57 PM, Chris Buechler wrote:

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

YEEEEEAAAAAAAAAAAAAAA!

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

I hope it came across right, I completely appreciate this approach- I believe it's far better than just doing some slapdash insecure BS that 'looks secure'...

Config files are, after all, critical resources!

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

Oh!  Well I'll be...

Is this true for IPSEC tunnels?  (Mine always drop and re-initiate when the failover occurs...)

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

!!!!!!!!! Wow. 

> 
> 
> 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

Thanks for posting these additions/corrections Chris!  I know we're all really excited to finally see yall in NYC-

And keep up the great work!

Best,
.ike





More information about the talk mailing list