On most rules that description is chopped off at the proper length, I'm not sure how that one slipped by. It would have been interesting to see what the /tmp/rules.debug line that failed looked like.

Howdy, Stumbled in here browsing the forum & this thread was helpful 2-fold: Hadn't used ee before & vi on pfsense didn't seem to work like vi I was used to from centos plus the pkg commands are handy to know as I've been used to yum so thanks. :) Bill

@cyboc: @jimp: Are you specifying an address pool/tunnel subnet on both sides? That's where the ifconfig line is made from. Both sides, I think. Can't check right now because the client side's router is in a box on some Fedex truck right now. LOL! I just noticed that the Tunnel Network setting is only boldface on the server side so that would indicate it's only required on the server side, as you suggested. I will try removing that setting on the client side when the router arrives to see if it gets rid of the warning. Thanks Jimp! The client side's router arrived yesterday and we hooked it up right away. The Tunnel Network setting was indeed configured on both sides. So, I tried removing it from the client side and I restarted the tunnel. The good news is that this got rid of the ifconfig line in the client side's GUI-generated OpenVPN config file. The bad news is: 1) I still continued to see the ifconfig warning and 2) I could not ping across the tunnel any more. So, for now, I'll put the Tunnel Network setting back on the client side. I guess I can live with the warning message as long as the tunnel works. No biggie.

I had thought that was fixed by one or both of these commits: https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/650b573bd8a435449178385a2d132f7f0002d309 https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/b0eaa10cda0b6307429a1bf4dabc2fbd3686d801 Are you still seeing that on a current snapshot?

They're really amd64 :-) http://snapshots.pfsense.org/FreeBSD_RELENG_8_1/amd64/pfSense_HEAD/nanobsd/?C=M;O=D

And the obligatory XKCD on the topic… http://xkcd.com/538/

ok, great. thanks!

Problem solved installing new snapshot and reconfiguring openvpn manually. It does not seem to like old config.  (ver 6.4)

@cyboc: Up until a few weeks ago…I had been consistently getting at least 14 Mbps download speed from multiple speedtest sites. More often than not, I had been getting as high at 28 Mbps in speed tests, due to the effects of Shaw PowerBoost. FYI, for any Shaw users out there, please note that despite what Shaw's website currently says, the Server Connect package does NOT include PowerBoost at this time. Shaw called me yesterday to apologize and to say that their website is incorrect and will be updated soon. That is why my download speed tests at work are topping out at about 14 Mbps after switching from the Internet Extreme package to the Server Connect package. More details here.

2.0-RC1 (amd64) built on Sat Mar 26 00:18:39 EDT 2011 When I updated to this snapshot, the pppoe interface came up fine. When I rebooted last night without updating, I had to manually connect the pppoe interface, even after making and saving changes on the PPPs tab.

Same here: ath0: unable to reset hardware; hal status 3 ath0: ath_chan_set: unable to reset channel 13 (2472 MHz, flags 0xa0), hal status 3 ath0: ath_chan_set: unable to reset channel 2 (2417 MHz, flags 0xa0), hal status 3 and so on… Seems somebody tries to fix it (10. March 2011): http://groups.google.com/group/mailing.freebsd.mobile/browse_thread/thread/108658f53a476879?pli=1

No, just the system log or logs from any of the other tabs that might have something relevant at the time. It might be good to at least start with: Details about your ISP (dhcp? pppoe? any other details…) If you're doing anything such as spoofing a MAC address Some hardware info, what kind of network cards you're using Screenshots of the various RRD graphs The contents of the system log, whether or not you think they're interesting, someone else might. :-)

Given my recent experiences, it seems that stunnel has to be added to this list, too…

When, instead of just reinstalling from the installed packages page, I deinstall the package from there, and then reinstall it from scratch, then the install stops here: Installing stunnel and its dependencies. Beginning package installation for stunnel... Downloading package configuration file... done. Saving updated package information... done. Downloading stunnel and its dependencies... Checking for package installation... Loading package configuration... done. Configuring package components... Additional files... done. Loading package instructions... So something seems to be busted…

A reply by Jimp which should cover your question. http://forum.pfsense.org/index.php/topic,33530.msg173926.html#msg173926

It does seem to be removing or losing track of the rules after an update.  Once I go in and update them my interfaces will start. Logs show warning/error that the rule/file being loaded cannot be found and snort stops.

thanks for reply, I have already solved it. On version 1.2.3, I did backup Captive Portal (ex. file1.xml), and in 2.0 version I did backup to System (ex. file2.xml). Then, I edited the files file1.xml and file2.xml, and copied all users from file1.xml to file2.xml, and I changed tags to new format in 2.0 version(For know the new format tag, do open the file2.xml file and see pfsense default user).  After that, for each user copied, replace all tags <password>to <hash-md5>in file2.xml. To finish, Restore System with file2.xml in pfsense version 2.0.</hash-md5></password>

reboot fixed it..