I also did the same thing.  I installed BandwidthD around 9:30am (judging from BandwidthD's daily graph) yesterday, and around the same time RRD stopped updating any of its graphs.

After reading your post, I checked the system logs for "lighttpd" entries, and saw the following:

Dec 1 09:23:32 lighttpd[30518]: (mod_fastcgi.c.2543) unexpected end-of-file (perhaps the fastcgi process died): pid: 31140 socket: unix:/tmp/php-fastcgi.socket-1 Dec 1 09:23:32 lighttpd[30518]: (mod_fastcgi.c.3282) child exited, pid: 31140 status: 0 Dec 1 09:23:33 lighttpd[30518]: (mod_fastcgi.c.3329) response not received, request sent: 1394 on socket: unix:/tmp/php-fastcgi.socket-1 for /pkg_edit.php?xml=bandwidthd.xml&id=0, closing connection

I was going to post a question about this earlier, but now my RRD graphs seem to be updating again.  I'm just missing a chunk between ~9:30am yesterday and ~7:30am this morning.

In the future, is there something that can be done to keep the process that logs RRD data running?  Or notify me if it goes down?

SUCCESS!

I manually assigned the interfaces to what they should be and its all working now! :)
disabled all the other stuff in the bios too

im just using 2.03 since its the one i already have, suppose i should get the up to date one before going further

Thanks for the help  ;D ;D ;D ;D ;D ;D ;D

@GruensFroeschli:

@vincom:

@GruensFroeschli:

You don't necessarily need to assign the created bridge interface.
From the description in this thread it appears as if the bridge was never created in the first place.

thats correct as the tuts and howto posts ive read it states to create a virtual interface first then create the bridge

Creating the bridge is what creates the virtual interface.

i know that now but the howto posts dont state that, they state to click the + sign to add a virtual then bridge the physical opt1 and the virtual opt2 and then reasign the lan port.

@joebleed:

I'm running the x86 version now and get the same + missing when all physical nics have been assigned.

As for the op trying to bridge, I don't know why it would matter, but have you tried setting the wap's ip to static and see if it just works after that?

Edit:  oh, just wondering, if you want the lan and wap bridged to the same network, why not just plug it into the switch on the lan?  Can you still control traffic between them once bridged?

i had the extra gig nic and made a project for myself and in doing so learn more about pf

Ok, tried a new clean install except I used the x86 version this time and only used squid 2 and squid guard 1.5x  still I get the ssl cert because it's trying to go through https.

reading this post:  http://forum.pfsense.org/index.php?topic=7317.0

I decided to force webconfig to http and not https.  i no longer get the https error and it goes directly to the error page as expected.

Seems obvious, but i thought with out checking the "Disable webConfigurator redirect rule" i wouldn't need to do this.  I'd still only have the https web configurator port only.

Any way this can be fixed?  I'm thinking about trying some of the stuff listed in this old thread, but i don't know if that will do any good.  Could/should i change the squid port to 80?  seems this may be asking for trouble if i do that.

Not sure if this is the case but I had random crashes when I upgraded to 2.1. I fixed it by doing a backup, doing a fresh install instead of the upgrade and restoring the backup. No crashes since so if you did an upgrade to 2.1 i'd suggest doing a fresh install.

Found my answer hidden in the DNS forwarder settings to register local systems in DNS.

Using Snort with a specific signature for Ultrasurf seems like a better way to do it. Maybe using Layer7 with a specific pattern. Although even using these will fail eventually as ultrasurf employs many techniques to disguise itself.
If you look at firewalls that claim to able to block it (Watchguard, Sonicwall) they are doing it using Layer7 pattern recognition.

You can attempt to block the IPs ultrasurf uses for it's servers but it will fail eventually as the list is a constantly moving target.

Steve

@stephenw10:

What most people want to know is the throughput of the box. I.e. 'If I have a 200Mbps WAN connection can hardware X pass that?'.

To test that you need a box on both sides that is at least as fast as the pfSense box. A popular test is utility for this is iperf, it's inclufed in pfSense so you can use 3 pfSense boxes to test but it's also available for other OSs. Run it as a server on a box on one side of the box under test and as a client on a box on the other side. Test the throughput. Test it in the other direction. This artificial test will give you a nice comparable number but real world bi-directional, multi-connection traffic will be different to some extent.

Steve

Thanks, i will try using iperf as instructed.  :)

Possibly it's failing to download the lists.
This question would be much better in the pfBlocker thread:
https://forum.pfsense.org/index.php/topic,42543.0.html

Steve

jimp

Thank you for the straight forward reply… how did I miss that  ??? and i've been around pfsense for like 2 years now... I just never tried this... and been bumping my head against this for a while...

I guess I kind of ignored it as I thought it was for multiple pfsense's?... actually I have no idea what happened in my head...

Again, thanks for the reply!.

What I do to stay fit for me. Not need to be downloaded on the web too. I will get back with you.

Well you could enable "Deny unknown clients"  And create reservations for all your workstations.

From a general security setting any ports not in use should be disabled, if users are plugging into unused ports those ports should be off in the first place.

Now sure what your using for switching, but many managed switches provide for port security.  Look into cisco port security for example.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/port_sec.html

This can allow you prevent users from unplugging their workstations from the port on the wall and plugging in their devices.  Now if they are smart enough to change the mac your out of luck :)

But this is more security than just not giving them a dhcp address.  You can also enable Static ARP entries in pfsense, now it will only talk to devices it has reservation for, etc.  This prevents users from just putting in a static IP on your network.

You could look into a fullblown NAC or NAP..
http://en.wikipedia.org/wiki/Network_Access_Control

Something like http://www.packetfence.org/ comes to mind.

Status -> DHCP leases will only show you clients that request DHCP addresses from pfSense.  To check for static IP hosts as well, head over to:  Diagnostics -> ARP table.

@Clear-Pixel:

Until we find out how Cisco will affect the open source end of it if any, I suggest continue developing the snort package and refining it.

Oh, I don't intend to abandon Snort at all.  Just looking at Suricata as another alternative to have in the package collection.

Bill

Figures it would be in the one place I never go to,thank you for the help.