Very good explanation. I couldn't say it better :-)

Yes, edit /etc/inc/system.inc - change the "15" to "3". That will happily survive reboots.
Of course, when you update your pfSense software to a new version then you will get a new /etc/inc/system.inc and have to apply the edit again. Ideally, don't hack too many scripts on an installation - you have to keep a record of what you did and make sure to re-do it after every upgrade. It is better if the parameters that users want to set are available on the GUI. Maybe go to Redmine and submit a feature request.

Those surely need synchronization.
Though its a more cleanup that needs to be done.
There really is no reason to use so many tags for the same thing and just need to unify those tags to just one 'item'.

But surely someone needs to do the heavy work and upgrade code behind.

The others are leftovers missed from devs. Its better to report this issues through redmine.pfsense.org.

The lawsuit was resolved in Feb 2012 - see http://en.wikipedia.org/wiki/Tz_database#2011_lawsuit - so at least that is not an issue. The TZ database is now managed by IANA, so it has a well-defined public life! The Wiki page has the link to "Official IANA sources" at http://www.iana.org/time-zones but for pfSense we will normally just want to use whatever version is distributed with FreeBSD from time-to-time, so these official pages are an interesting reference, but there is usually no need to actually get the source data from there.
I will open a ticket today.

It depends on where the code is being used.  If it is a web gui or console program, the output should go there.

It depends on what is in your overlay. That error might suggest that you had customized beastie.4th somehow but it failed to build properly.

As far as I know things in the builder are OK, we build images for customers almost daily and they have been OK.

I had to go in the admin settings and re-save on the default columns setting, then it came back.

I could swear I brought over the robots.txt when I upgraded it this last time, but apparently not. :-)

@jimp:

We've been trying to track that down but there is an easy workaround,

cd /usr/ports/sysutils/cdrtools; make install clean

Then go back to doing the build

Thank you @jimp

@Aydin:

i think you need this:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html

No.

xogoc: you'll have to script your change to firewall_rules_edit.php and then trigger a filter reload.

you can try this (in turkish forums):

http://forum.pfsense.org/index.php/topic,41243.0.html

maybe you need change freebsd package name in url..

If you want 2.0.1 exactly, use RELENG_2_0 then edit pfsense-build.conf and change the PFSENSETAG to RELENG_2_0_1

That said, using RELENG_2_0 is fine. We only include beneficial safe fixes in the RELENG_2_0 branch so at the moment that gets you what may eventually be 2.0.2 (if we ever decide to release another 2.0.x release before 2.1 is out)

I wanted a set as well but it seems my country is not listed in the registration page :(

@ermal:

check interface link negotiation or force it to the configured speed!

You're right! I've found it by myself, autonegotiation wins in this case, forcing speed and duplex can cause troubles.

Now I'm on 2.0.1, at last!

Thanks
A.

maybe this month..  :)

http://forum.pfsense.org/index.php/topic,44583.msg233413.html#msg233413

I think what you want is XMLRPC. As far as I know, there is no reference for it. There is a DevWiki but I didn't see any info there on XMLRPC. There are some packages that use it for config sync, and of course pfSense itself uses it for config sync. I don't know what else it supported but I would like to know as well.

In 2.0+ you can create users in the user manager and control exactly which pages they have access to but there aren't any ACLs on things like firewall rules to where it would owned by a user. You would probably have to keep track of this in your own application; maybe use the description of the firewall rule to store some info that's parseable to you (@@ownerid=45261903@@) just an example.

No, just standard unix host template. I'm not graphing anything exotic.

If you want to graph pf bits, check out the pf mib
http://files.pfsense.org/jimp/BEGEMOT-PF-MIB.txt

Well - that's the quickest fix ever! I have downloaded the pFsense 2.0.1 2GB nanobsd image and written it to a Sandisk Ultra 2GB CompactFlash card. It fits - success. The size is now less than 2,000,000,000 decimal bytes, so hopefully it will forevermore fit on anyone's definition of a 2GB card. Thanks.

AFAIK setfib does multiple routing tables, it doesn't do multiple arp tables. You still can't have the same IP+MAC on two interfaces with multiple routing tables unless they can also separate based on interface.

ECMP lets you talk to the same destination via multiple paths, which is better for that scenario.

Ahh, I'm glad I found your posts! Coming from a Linux background I just assumed it was natural to be able to apply a nat rule to all interfaces and so thought I was totally ignorant as I tried to figure out how to make pfSense do it!
(I'm still using 2.0-RELEASE (i386) built on Wed Sep 14 00:39:34 EDT 2011 –- Is the feature I need already available?)

In any case, I agree - supporting groups for NAT, or multiple interface selection for nat, or even just an ALL interface option in nat (That should be easy if pf is anything like iptables) would be really great.

My scenario is relatively simple and normal for a small ISP:

We have several vlans bringing in customer traffic from different geographical locations, and a vlan for our server room, for example:

10.0.0.0/16: IPs for our server room - mail, web, etc.
10.1.0.0/16: East side of town
10.2.0.0/16: West side of town
10.3.0.0/16: Center of Town (You get the idea..)

Let's say the public IP is 4.4.4.4.

All vlans come into the pfSense box which then nats out through a real public IP. (Actually several real public IPs.)

So obviously some of our servers - like our main webpage and email servers - need to be reached by all users -- regardless of whether they are at home or traveling -- we configure their mail clients to connect to 4.4.4.4 (via domain name) and it should just work whether they be at home or work or anywhere in the world.

The problem is we have to add a forward rule for pop3s (port 995)  not only on the WAN interface for the mail server, but also on each and every customer access vlan interface.

So if we have a web, a mail, a DNS server, a backup DNS and mail server, each with several ports listening, we could end up with having to add a lot of rules.

So yes, being able to apply a NAT rule to a group or to ALL would be a most splendid and powerful feature!

Thanks a million for a great product and keep up the good work!

~Jesse