Fantastic!

Thanks for the information guys. I thought I was going crazy (and so did heper it seems)

It does fascinate me that one of the places I work at switched it on in the GUI with their multiple pfSense boxes at multiple campuses and never had an issue with it.
I must check to see if they are actually pointing their systems to it for NTP or they only think they are.

Hey, thanks for trying FlashPan. We're all in this together.

So we're not using AD (yet). At the moment, it's just a separate box (a VM actually) running OpenLDAP. Since we now have about a dozen services that can use LDAP to authenticate, we're trying to go that route. pfSense is just one of these services.

The good news is that we figured out how to get this working with pfSense…kind of. By adding a 'manager' attribute to Person objects, setting a manager to point to a DN that starts with cn=SOMEGROUP, making sure that there is a pfSense group names SOMEGROUP, and finally setting pfSense's group member attribute to 'manager', it works.

The only issue we have is that using the manager attribute to store group membership is disgusting. I'm hoping that we learn something while setting up an AD service (through Samba4).

Hard to say what's messed up exactly that lets it pass the test.

Step 1 would be to get us a copy of the "bad" file.

I belive I had found perect solution http://www.jasemccarty.com/blog/?p=101
crossroads may provide what I need.

No problem.  ;D

Steve

There isn't an option for that yet, but you might be able to hack around a bit in /usr/local/www/bandwidth_by_ip.php and manually adjust it. (I don't know which specific numbers are limiting the table to that size, but it's all in that file)

thanks again for the replies.  i'm going to play around with this for the next few days and see what i can make heads and tails of.  i'll have more questions for sure.  either way…... i see my wndr4000 to likely be hitting the f.s. section of the computer forums i frequent.

I want to thank John an Steve for all there time they spent on my question/problem.

And most important "THE PROBLEM IS SOLVED" ;D ;D ;D ;D

Thanks guy's

If the connection isn't closed (by a FIN or RST), they sit there for a day waiting to time out. TCP connections will most always be closed on their own though, in cases where they aren't there generally is some kind of poorly behaving application involved, or maybe some other issue outside the firewall. You can change the state keeping to aggressive to time them out more quickly, but that sounds like an indication of some other problem.

Yes you can delete LAN, though you could also just reassign it to one of your VLAN interfaces. The only thing that makes LAN different to any other interface is the pre-defined firewall rules.

You will only be able to access the webgui via another interface if you have setup firewall rules to allow it.

Steve

Yes you can make it bigger, though you shouldn't have to. The only restriction is the amount of memory it uses, as far as I know, though I suppose it could have some other consequences if you made it ridiculously large. E.g:

@http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-kernel-limits.html:

The NMBCLUSTERS kernel configuration option dictates the amount of network Mbufs available to the system. A heavily-trafficked server with a low number of Mbufs will hinder FreeBSD's ability. Each cluster represents approximately 2 K of memory, so a value of 1024 represents 2 megabytes of kernel memory reserved for network buffers. A simple calculation can be done to figure out how many are needed. If you have a web server which maxes out at 1000 simultaneous connections, and each connection eats a 16 K receive and 16 K send buffer, you need approximately 32 MB worth of network buffers to cover the web server. A good rule of thumb is to multiply by 2, so 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. We recommend values between 4096 and 32768 for machines with greater amounts of memory. Under no circumstances should you specify an arbitrarily high value for this parameter as it could lead to a boot time crash. The -m option to netstat(1) may be used to observe network cluster use.

I guess that advice is a bit old now, 64MB is not going to trouble your system!

Steve

I could do it with root and scp transfer.

Thank you.

In Endian it works well… I haven't defined all 8 IP's because I dont use it

endian.png
endian.png_thumb

thank you very much Steve.  :)
booting from USB is OK and pfsense installed successfully on SATA DOM.
the problem was USB CDROM.

Guessing it could have something to do with the NIC's that virtual pc is emulating. Don't think anything other than Windows is supported on virtual pc and afaik it emulates a network card that most OSS operating system don't fully support…

I'm still having trouble with this and I do not have the answer.
Does someone know or can tell me in which way seeking ?

Airy

@Phonebuff:

I appeared to loose all DNS resolution and specifically the CBeyond DNS as the SIP registry went away.

–---------------------------------------------------------------------------------------------------

Did I miss something in my configuration(s) ?

JMS.

I see you mentioned Asterisk later in the post.  The fact you lost all SIP registrations to the server is a very well documented Asterisk problem.  If your Asterisk server loses DNS resolution (sounds like you have a SIP trunk as this bug doesn't affect TDM devices from what I've heard), then it will fail to respond to SIP registrations itself.  There have been many attempts at work arounds (dns caching and such) but it will still always fail eventually.  It sounds like you got your DNS issues sorted, so you probably noticed your phones started to register at that point too…

@al1x:

OpenSSL? crypt? pam? I haven't looked at them in depth but they would seem to be relevant.. no?

crypt applies strictly to DES hashing, which we don't use anywhere. The PAM one isn't applicable to anything we do. The OpenSSL one, we got a private heads up related to that which I can't discuss, but it's not something that's applicable in our use cases and there are other reasons it's been delayed until now (like the additional one on sysret, though local priv escalation generally isn't applicable either). Now that the sysret one is settled with the updated advisory this week, we'll have 2.0.2 out shortly.

We have a good relationship with the FreeBSD security team and are always on top of security advisories. If/when there is ever a reason for a quick update, we'll put one out immediately.