ok thanks for the clarification!

you were right, same problem with the latest snapshot. Keep up the good work! ;)

Check the snapshot server shortly. I can't make any guarantees about the quality, but they should at least be building now… Serial only at the moment though. If they work I'll flip the logic in the builder so the amd64 ones default to vga.

@jimp: The x86 version sees more testing, due to its wider user base, but these days there isn't much difference between them except the architecture. You probably can't access all of your RAM on x86 though, so x64 may be the way to go. I confirm… I was also setting-up CARP between a x86 and x64 version of pfSense 2.0-RC1 (both latest build)... no problems at all... wow...

I didn't bump the version number of the package, but if you reinstall that package (From System > Packages, on the Installed Packages tab, click the 'pkg' button) it should pull in the changes.

OK, just checking. I've had a couple other people whose configurations have failed to restore that worked when the OpenVPN section was removed, but there was no obvious incorrect entries in the config either.

Depends on what you mean by multiple lines.  I have a small block of IP addresses ( one physical line ), and I just use IP aliases for all the IPs.  If you mean multiple physical lines, I have not seen that with the same gateway.  I do have another location with two physical lines from different hosts using a switch in front of pf; but that is different than your situation.

Read the note on the client export page. You need to have users, and user certificates, and the user certificates need to be made from the same CA used by the OpenVPN server.

Yeah, open a ticket on redmine.pfsense.org - it will need some further review, because that same file is used for PPTP, PPPoE server, and L2TP - so the change doesn't only impact PPTP.

That is the cleanest solution, make a rule above that that has a gateway of 'default'.

I replied to your support ticket with the answer, but since you posted it here I'll give a quick reply here as well: The source of "any" on the NAT rule is probably to blame. Change that to your LAN subnet, or your internal subnet(s), and it should be OK.

Hi jim, you where right! I removed the packages manually and maybe I forgot something. Today I started with a clean download. Seemed to work at fist glance - but at least the PPPoE config / VLAN Config / OpenVPN did not import. But now I can start testing it at least ;)

That would certainly explain it all. Kind of glad it turned out to be dying hardware instead of a driver issue. Bad for you (but at least you can RMA) but it means others with that chip aren't out of luck.

That's all from snort, not sure how that got mixed into the output of the OpenVPN client export. config/snort/snort.inc: exec('/usr/usr/bin/killall snort'); config/snort/snort.inc: exec('/usr/usr/bin/killall -9 snort'); config/snort/snort.inc: exec('/usr/usr/bin/killall barnyard2'); config/snort/snort.inc: exec('/usr/usr/bin/killall -9 barnyard2'); config/snort/snort_interfaces_global.php:              exec("/usr/usr/bin/killall snort"); config/snort/snort_interfaces_global.php:              exec("/usr/usr/bin/killall -9 snort"); config/snort/snort_interfaces_global.php:              exec("/usr/usr/bin/killall barnyard2"); config/snort/snort_interfaces_global.php:              exec("/usr/usr/bin/killall -9 barnyard2");

The actual packages themselves need to check if they are being run at bootup and account for that. http://redmine.pfsense.org/issues/53

Hello ballerh3, Yes. It works now. Thanks. kmnair

I would also temporarily disable the port forward, and reset all states.

loadbalance/multi-wan: http://forum.pfsense.org/index.php/topic,28121.0.html proxy: http://forum.pfsense.org/index.php/topic,33895.0.html this forum has a search function :)

As it turns out, resetting both of the bridge tuneables to "default" caused my problem to go away. I currently have my bridging setup similar to as in my original post and even the WOL problem seems to have cleared up as well. I think the lesson here is that system tuneables can have great effect on how things in pfSense can or can not work. Perhaps when adding a bridge to a new system the php code should check the value of these two bridging tuneables and give at least a warning to the users about how bridging is affected by them?