Pfsense version in configuration

[efk]

Each configuration starts like so:

 <pfsense><version>8.0</version></pfsense>

I've just installed 2.0.1, 2.0.2, 2.0.3, and 2.1 and i assume this version refers to the version of FreeBSD it's based on. Is that correct? 2.0.x seem to say 8.0, and 2.1 says version 9.8.

In my $dayjob, i end up doing a lot of firewall configuration reviews, and I've received a couple pfsense configs recently. I cannot tell what specific version of pfsense any given configuration comes from. Would it be possible to seed the pfsense version into the configuration file?

Anyone else think this would be helpful?

[phil.davis]

<version>8.0</version>

That is an internal config format version, not related to the FreeBSD version or anything in particular. Upgrade code uses it to know what format the config currently is and then apply all subsequent config upgrade conversions since…
/etc/inc/upgrade_config.inc has the code that makes each upgrade conversion in turn - I guess looking at the end of this file on a particular pfSense version will tell you which internal config format version goes with which external pfSense version.

[efk]

2.0.1, 2.0.2, 2.0.3 all say version 8.0. PFsense 2.1 is version 9.8. Since these are internal versions, this number needs to get incremented with each release.

[phil.davis]

Good point - from 2.0.1 to 2.0.2 to 2.0.3 no changes were needed to the config file format, so no internal version increment.
Perhaps it would be useful to have the pfSense version explicitly set in the config file by code that runs at the end of the upgrade process?

[efk]

Yea, that would help guys like me that need to know what version of the OS are running when we're looking at other peoples configurations. Even if there are no major changes to the config format itself, default behaviors and settings of the OS change over time, and being able to track them to a version number is very important.

An example would be if someone made a default tunable change in 2.0.2, I wouldn't be able to tell if this configuration came from 2.0.1 or 2.0.2 and thus may give the customer bad advice or overlook a potential problem.

[jimp]

The version there refers to the format of config.xml itself. That format did not change between 2.0.x versions so you could take a config from 2.0.3 and put it on 2.0 and it would work the same. If we bumped that number on each version unnecessarily, then it would break the compatibility of the config between versions that really have the same format.

If you want to stuff purely informational items into config.xml on your own, feel free to come up with a simple script to insert (for example) the output of uname -a and /etc/version into $config somewhere and then call write_config(); Perhaps the routine that writes the revision metadata/info in write_config() itself might be a good place to put it.

I'm not convinced it's something we'd want to do for everyone by default though.

[efk]

I know how i can do this on my own devices, the problem lies when I get other peoples configurations. It seems that pfsense configurations are becoming more common for me, so that's why I reached out.

There are vendors that deemed it worthwhile to add the OS version to their configuration files, for example junos:

version 11.4R1.6;
groups {
    node0 {
        system {
            host-name example-srx220-node0;
        }
        interfaces {
...snip...

Cisco doesn't explicitly outline the version, but you can get a general ballpark because you'll see something like 12.2 in the configuration but you wont get the full version, featureset, etc.

So to try and shed a little more light, I do configuration reviews for people in a security context. I started writing a parser for pfsense configurations, and wanted to identify the OS based on the version so I could maintain a list of CVE's associated with that particular release of pfsenes. When i went to add support for an older version of pfsense, i found out that the version heading in the config doesn't specifically identify the OS and therefore my parser is dead on arrival.

[jimp]

In that specific context I could see how it would be useful to have it automated.

If the code showed up as a pull request on github it would probably be accepted. Ideally it should somehow be noted that it is informational only though because otherwise people might think that it means the config could only be restored on a system that had the same information. I'd say between the pfSense version, platform and "uname -a" it should tell you enough.

        <revision><time>1389273511</time>

                <username>admin@192.168.x.x</username>
                <detail-info-version><detail-info-platform><detail-info-uname></detail-info-uname></detail-info-platform></detail-info-version></revision> 

(Prefixing the fields with "detail" causes the parser to automatically wrap them in CDATA since we wouldn't want anything in those spots to potentially cause broken xml)

[efk]

What you're talking about sounds perfect. I don't have a development environment at home, but I'll see if this is something I can pull off. Thanks for your input.