State table was checked before I posted - my old address wasn't there. After that I started packet capture on WAN. I will wait for the next provider initiated reconnect and double check again.

After removing Freeswitch and Freeswitch-dev, the message has disappeared from Filter Reload, and the aforementioned services start at boot.  Now I see several instances of the following two error messages under System logs.  I saw neither of them under 1.2.3: dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory. kernel: CPU0: local APIC error 0x2 I believe the first error has something to do with miniUPNPd.  I'll have to look into that one a little more. I believe the second error has to do with a setting in my BIOS.  It does not seem to be disrupting service.  I'll have to mess with that late tonight when I will be disrupting fewer users.

Sounds like your outbound NAT isn't right.

ok, thanks for the answer! Michele

rpsmith; ill help you. delete all the old text, and copy and paste this in its place. # Check for different HZ if [ -f /boot/loader.conf ]; then         HZ=`/usr/bin/grep -c kern.hz /boot/loader.conf`         if [ "$HZ" = "1" ]; then                 NOTELENGTH="10"         fi fi if [ -c "/dev/speaker" ]; then                 if [ "$1" = "start" ]; then #                      /usr/local/bin/beep -p 500 $NOTELENGTH #                      /usr/local/bin/beep -p 400 $NOTELENGTH #                      /usr/local/bin/beep -p 600 $NOTELENGTH #                      /usr/local/bin/beep -p 800 $NOTELENGTH #                      /usr/local/bin/beep -p 800 $NOTELENGTH                 fi                 if [ "$1" = "stop" ]; then #                      /usr/local/bin/beep -p 600 $NOTELENGTH #                      /usr/local/bin/beep -p 800 $NOTELENGTH #                      /usr/local/bin/beep -p 500 $NOTELENGTH #                      /usr/local/bin/beep -p 400 $NOTELENGTH #                      /usr/local/bin/beep -p 400 $NOTELENGTH                 fi fi

These rules will eventually be turned into normal rules that reference a special alias for rfc1918 and bogons. (Probably for 2.1) It's easy to disable the rfc1918 rule and make your own alias that contains the rfc1918 nets (it's only three networks) and then use your own rule, set however you like.

Maybe this topic should be moved to the Traffic Shaping forum.

Does not look that way as I went back to a previous build on March 1 at 23:xx and I still have OpenVPN issue. I still get: openvpn[38096]: write UDPv4: No buffer space available (code=55) Does anyone know when the last update to OpenVPN was so that I can go back prior to the changes and re-test? I am also seeing sustained FTP download loosing connection, but to be fair the other side is an up-to-date pfsense outside of my control. Going to test with DVD download soon. Podilarius.

With OpenNTP and the logs the time is working as expected in the build listed above. Still have OpenVPN issue and will open another thread for it. Pod.

You should be able to run i386 binaries on amd64 (we install the compat libs, IIRC) but you can't run amd64 binaries on i386. That said, it should definitely be installing the amd64 version if it's available.

Is your GUI actually running on port 443? Can you telnet to 192.168.1.2:443 from the master?

Sweet.. Thanks sleeprae!! I knew there had to be something out there that I could not find. I will give this a try a little later. Thanks again!

Ok. Thank you for the info! cheers!

yup, that definately seems to have fixed it. No more spilling out of the database. Thank you very much for all your help :-)

Do a tcpdump of the traffic to see what's going on or try to allow ip-options to be forwarded in pfSense.

I feel silly now. Pfsense is totally fine with all versions of internet explorer. I just ran into the rejected issue http://redmine.pfsense.org/issues/1346. Sending the voucher code with a simple keypress of <enter>results in the reloading of the captive portal entry page but klicking on the "continue" button works fine.    ::)</enter>

If your gateway is monitoring the lan ip of the modem than the lost connectivity will not be detected. So check that first otherwise the system log is needed which you do not have, next time :(.

I suspected that also so I installed the "cron package" to be on the safe side. It works like a charm and it makes managing cron jobs easier, but I think Vi will do the job too. Btw, I also had to restart the cron service manually using the shell after changing the crontab file. Once everything was set up and tested I rebooted pfSense to be sure everything's ok. So far so good! :)