The .zip is made by the client export package. As for what you need, that is entirely dependent on how you have the openvpn server instance setup.

Much thanks.  I just verified on the FreeBSD forum.  That's too bad.

Nothing obviously wrong there, not the things I would expect to see that make it fail in past cases. Have you tried restoring a copy of that config with the <installedpackages>section removed?</installedpackages>

thanks iorx!  that sounds promising.  :) Roy…

booted and installed the iso and it said there was a (march 4th) update. I needed to pull this back out and put the 1.2.3 hd back in due to all the issues. might try again.  but, so far: 1.2.3 won't upgrade (had driver/usb or boot issues with 2.0 rc1 iso) 2.0 rc1 iso won't even install (if there is an existing boot loaded on the hd.. see other posts. needed to zero out first 512 bytes of hd to get it to see the ata drive)

Actually after reading through you config the difference between your setup and that of Wallabybob or in the thread I linked to is that you have LAN as a member of your bridge where as the others have LAN set AS the bridge. It seems odd that your setup doesn't work especially since 2.0 was supposed to moving away from LAN and WAN having special status. However I wouls suggest reconfiguring it accordingly. Steve

More digging indicates that this might be related to the fact our test environment is between 2 dynamic IP addresses and when dnswatch checks the addresses. As soon as racoon is restarted then the vpn comes up within 30 secs but reappears if we reset the link (and gain a new dynamic ip).  We are also testing with shared key rather than a cert.  Will have to transfer a cert and try that way. Andrew

Looks like my traffic and packets graphs died, but might have something to do with the install of the ipv6 stuff?? This error getting Mar 8 00:38:19 php: /status_rrd_graph_img.php: Failed to create graph with error code 1, the error is: ERROR: Could not parse color in ''/usr/bin/nice -n20 /usr/local/bin/rrdtool graph /tmp/wan-traffic.rrd-4year.png –start 1199080800 --end 1299566297 --vertical-label "bits/sec" --color SHADEA#eeeeee --color SHADEB#eeeeee --title "hostname - WAN :: Traffic - 3 years - 1 day average" --height 200 --width 620 DEF:wan-in_bytes_pass=/var/db/rrd/wan-traffic.rrd:inpass:AVERAGE DEF:wan-out_bytes_pass=/var/db/rrd/wan-traffic.rrd:outpass:AVERAGE DEF:wan-in_bytes_block=/var/db/rrd/wan-traffic.rrd:inblock:AVERAGE DEF:wan-out_bytes_block=/var/db/rrd/wan-traffic.rrd:outblock:AVERAGE DEF:wan-in6_bytes_pass=/var/db/rrd/wan-traffic.rrd:inpass6:AVERAGE DEF:wan-out6_bytes_pass=/var/db/rrd/wan-traffic.rrd:outpass6:AVERAGE DEF:wan-in6_bytes_block=/var/db/rrd/wan-traffic.rrd:inblock6:AVERAGE DEF:wan-out6_bytes_block=/var/db/rrd/wan-traffic.rrd:outblock6:AVERAGE CDEF:"wan-in_bits_pass=wan-in_bytes_pass,8,*" CDEF:"wan-out_bi I tried stop and starting rrd system, but that did not seem to clear it up.

Could you post some more details on your steps to reproduce the panic and to not panic?

@jimp: There isn't really an easy way to definitively check it like that. Really that file (libiconv.so.3 from your posts in other threads) should probably be on the base system I thought. It's required by quite a few things as listed on one of the package builders (not an exact list, but close…) Yes, that's why it corrupts the system and requires a new install. So my current theory is that some package under some circumstances replaces the system installed version, and after that all hell breaks lose. When installing the packages individually it seems that the dependencies are satisfied in the proper sequence, and the version that comes with the base system seems to remain unmolested. But during re-install or restore of a configuration somehow sooner or later things get wonky…

i added this silly rule to the top of my floating rules: ID Proto Source Port Destination Port Gateway Queue Schedule Description [BLOCK] TCP 127.0.0.1 * 127.0.0.1 80 (HTTP) * none shortly after adding this (~1-2 minutes) the states dropped from >11,000 to <1,000. http traffic is not being slowed to a crawl. so this is a really good workaround but perhaps this should get fixed. ermal, would you like me to just send the whole config file to you?

Please upgrade to the latest snap for all you say here. The only one that hsould remain valid is the default queue issue that i have in plan to solve soon.

Thanks! Somehow I managed to miss this post  ::)

whats also wierd is if I go to firewall/rules/ floating it shows that theres a rule for penalty box but it doesnt have the source IP that I set and when it shows the queue as being qOthersLow but there isnt actually a qOthersLow in the queues so I click on it and it opens up queues where it asks if I want to lan: Clone shaper/queue on this interface wan: : HFSC Clone shaper/queue on this interface heres screen shots of all of it update just as an added note when you have problems going through the wizard and it states the percentage problem it also shows everything as active but it isnt because you cannot modify any entrys till you uncheck and recheck enable penalty box at the top. Just figured I would throw that in because its just a ui bug that could prob be easily fixed. [image: snapshot2.png] [image: snapshot2.png_thumb] [image: snapshot3.png] [image: snapshot3.png_thumb]

That tells you nothing. pfSense is optimized to be a router, not an endpoint. So unless the traffic is sent to/from devices on interfaces, the benchmark would be pretty meaningless. It doesn't tell you how much traffic the box can pass because you also have the overhead of whatever utility is generating the traffic. You really need three systems - the router, a WAN system, and a LAN system, and you can run things like iperf between the WAN/LAN clients to test things and get better numbers.

There is not yet a solution for that. All of the packages are lumped together under the Packages permission. It's something we plan on addressing in 2.1 but it's too big of a change to squeeze into 2.0 yet.

Check the bug tracker. The watchdog timeouts are from the new yandex em driver. We may end up reverting them, as they are causing this and other issues.

Fixed: http://tinyurl.com/4jwbgyy

What browser are you using? That has been a known issue with the traffic graphs in the past, but not any other widgets I'm aware of.