In the case of maintenance so it can be. However, in the development program must continue to be developed. Including working with the developer tool severity. Because it could not be denied again that the device will be very hard to support the performance of the software itself. However, the funding from the side at the minimalist

http://doc.pfsense.org/index.php/Why_does_autoupdate_report_a_new_version_on_the_newest_snapshot%3F

Yes as what you want to use ain't affected by a snapshot upgrade.

Thanks a lot, DNS is working now with the right static route settings for the failover DNS gateway.

Thanks a lot. Do work now with the rule to send traffoc to the right gateway.

Yes i do not use the same address subnet on the LAN. I've changed the adresses here for safety. 192.168.1.254:80 is the PFsense BOX LAN interface. This is strange isn't it ? There is no port forwarding of this port on my box. I suspect that something is going wrong somewhere. Perhaps inside the filter himself. The GUI slow downs on some pages like general setup (when changing a DNS address for example) or firmmware update are strange as well. No error messages. When the GUI is slow, there is no system slow down.

Everyone is entitled to make a mistake once and a while, this is my chance to shine :) I did not realize the backup/restore option was so easy to use and dummy proof.  Once again you guys have thought of everything. Amazing!

This is the problem with complex setups. Developpers often do not have at hand the testing network to be able to test. This is specially the case with OpenVPN, IPv6, MultiWAN, MultiLan, ML-PPP, vlans, bonding, QinQ, and other advanced setups. And professional users can't put beta or alpha software on a production platforme. I tried to put 2.0 alpha on production but reverted to 1.2.3. 2.0 has very nice features, all that was missing inside 1.2. It is a good mix of the good ideas of zeroshell, the PFsense interface, and FreeBSD.

1.2.3-PRERELEASE-TESTING-VERSION built on Tue Mar 17 15:43:07 EDT 2009 DNS forwarding works

Forget PPPoe for multiwan. The best setup is to have the modem in half bridge mode, where it gives you an external IP directly. The first thing i do is putting the modems in DHCP spoofing mode, and Pfsense in DHCP mode, so that you can get the external IP and gateway IP. Next i switch the pfsense wan interfaces to static mode, and enter manually the adresses. This avoid DHCP headach like getting a 10.0.0.138 IP when the link is down at the DSL side.

@jits: @dotdash: NAT rules create a matching firewall rule by default (unless you uncheck the box). If you change the NAT rule, you have to manually change the firewall rule. Okay. I understand now. Can I play devil's advocate for a minute? If I create a NAT rule, PFsense will auto create a firewall rule, but if I edit that same NAT rule, I then have to manually edit the related firewall rule. This leaves room for error doesn't it? Would it be too much trouble for PFsense to keep track of changes in NAT rules and update the firewall rules accordingly? or at the very least, remind me that I need to modify the related firewall rules? This behavior seems trivial and expected, but it's not. It's like my uncle who gave me a remoteless tv for my birthday, when for years remote tv's were in vogue. His reply…I don't want you getting too lazy now! At the end of the day, PFsense still gets the job done and that's what counts. Thanks. It's much like how if you delete a NAT rule it doesn't delete the firewall rule. Perhaps a warning on the NAT create screen that reminds you "This won't automatically edit or remove this firewall rule, only create it.." or, we can add this to the documentation…..

It was shut off on purpose. I don't recall the exact reasoning, and I can't find the commit in the logs, but I remember seeing it happen. The devs figured that since they have the compatibility options in the kernel for FreeBSD 6, the packages shouldn't break on an upgrade even after a big version update. Plus it takes quite a while to finish on a system with any good number of packages, which made testing snapshots a chore. I think the dashboard is the only one that really "breaks" on an update, and it's pretty minor anyhow. The dashboard itself is sort of a hack anyhow :)

A fix for this is in commit re1f27ca. The next snapshot should be OK.