Profiles

The FireBrick can operate as a PPPoE client. This is typically used to connect to an internet service provider, either via a suitable PPPoE modem, bridging router, or direct connection.
As part of our dive into specific features of the FireBrick, in this article, we are going to look at ‘Profiles’.

The FireBrick manual describes profiles as:

A profile is a two-state control entity – it is either Active or Inactive (“On” or “Off”, like a switch). Once a profile is defined, it can be referenced in various configuration objects where the profile state will control the behaviour of that object. – FireBrick Manual

Off and on-Able

Nearly every element in the configuration of a FireBrick can be controlled with a profile. Once a profile is configured, it will be shown in the ‘profile’ dropdown all over the configuration interface.

Profiles can be a manual control switch – and will then appear as a button on the FireBrick’s web interface. You can then enable or disable parts of the configuration manually. These can even be controlled by external scripts.

More from the manual…

A profile’s state is determined by one or more defined tests, which are performed periodically. If multiple tests are specified, then the overall test result will be pass only if all the individual test results are pass.
Assuming the profile’s state is Active, then when the overall test result has been ‘fail’ for a specified duration, the profile transitions to Inactive.

Similarly, once the overall test result has been ‘pass’ for a specified duration, the profile transitions to Active. These two durations are controlled by attributes and provide a means to ‘filter’ out short duration ‘blips’ that are of little interest.

Profiles can be logically combined using familiar boolean terminology i.e. AND, OR and NOT, allowing for some complex profile logic to be defined that determines a final profile state from several conditions.
When considering the state of another profile, it is the previous second’s state that is considered – i.e. profile states are all updated in one go after considering all profiles.

By combining profiles with the FB2900‘s event logging facilities, they can also be used for automated monitoring and reporting purposes, where profile state changes can be e-mailed directly from the FB2900.
For example, a profile using a Ping test can be used to alert you via e-mail when a destination is unreachable.
The profile logic tests are also done based on the defined interval.

What can set a profile

A profile can be based upon many things, and they can also be combined with AND, OR, NOT logic to make create more powerful functions.

A profile can be set by:

  • being hardcoded in the config – either on or off
  • a ‘control switch’, accessed via the FireBrick’s UI or by external scripts
  • a time range – including year, month, date, hours, minutes, seconds
  • if a physical port or group of ports are up
  • if the FireBrick has a route to a specific IP
  • if the FireBrick is a master in a VRRP configuration
  • if an FB105 tunnel is up
  • if a specific PPP session is up
  • if a 3G dongle is up
  • if a specific L2TP link is up
  • if a specific IP answers pings

What can a profile control

Most configuration elements can be controlled with a profile, and the status LED can be controlled too! If you want your LED to go blue at night and green during the day, then this is possible! More useful things can be controlled though.

This is not an exhaustive list, as there are lots of things, but here are the main elements that can be controlled with a profile:

  • Automatic software updates (eg, only update overnight)
  • Admin users (eg, specific users can only access the FireBrick UI during working hours)
  • Other profiles (eg, use AND, OR, NOT logic to combine profiles)
  • Traffic shaping (eg have shaping rules apply only during ‘peak’ times)
  • Ports, subnets, DHCP ranges, VRRP, PPP etc can call be controlled
  • Firewall rules (eg, only enable certain traffic in/out during set times)
  • VoIP carriers (eg use a different carrier at off-peak times)
  • L2TP, FB105, IPsec tunnels and EAP users
  • Routing such as static routes, BGP, OSPF, routing overrides, blackhole routes can all be enabled or disabled
  • Upstream DNS servers, RADIUS servers, Log targets
  • DNS hostname entries

A simple example

Here is an example of a simple ICMP ping. We create a profile called PingGateway, set the IP we want to ping, and that’s it.
We can now see the status of the profile and can use this profile in our configuration.
Perhaps we can change the routing to use an alternative gateway if the ping stops and set the LED to be red.

Typically, profiles are used to create fail-over logic so that backup routes to the internet are used in the event of the main internet connection failing.
As you can see, with profiles and your imagination, a lot of automated logic can be applied to make a FireBrick configuration dynamic and adapt to changes in its environment.

Scripting

As with many things in the FireBrick, it is possible to script access to profiles. The control switches are a particularly useful example of this as it allows external scripts to control if a profile is active or inactive.

Example:

curl –user name:pass ‘http://1.2.3.4/profile?set=profilename’

Further information in the manuals.