Note that saving the config also clears the log.
To upgrade the FireBrick® you must first download the software file(s) from http://software.FireBrick.co.uk/ and store these on your computer. You can then select the upload option and select the file to upgrade your FireBrick®. The upgrade process can take up to a minute during which time the red light will flash rapidly and all of the LAN hub lights will flash. When they stop the FireBrick® is upgraded.
You must not interrupt the power during the upgrade. If you do you could end up with a dead FireBrick® (see Don't Panic).
An upgrade will not normally change your configuration or reset statistics or DHCP tables, but this depends on the versions you are using. Always check your configuration carefully after an upgrade. It is usually a good idea to save your config before upgrading, as downgrading later may not preserve your config fully.
Once the main (F) file is loaded, you will need to load the user interface file (e.g. WEN for English). WIthout this the FireBrick® still operates, but cannot be configured.
Note that uploading also clears the log.
Options include a bar graph mode which uses the 8 lights as a usage level indicator - lighting more lights from the left. When in a wall of FireBrick®s this allows network usage per FireBrick® to be seen at a glance.
Another option is a cycling lights option. Note that selecting this does cause a harmless local network packet to be sent on the WAN connection every 1.5 seconds, which would not go out to the internet. If you have a wall of FireBrick®s you can select cycling lights on all of them at once and you will be able to see what this network packet is used for...
The gateway only affects routed traffic, and not stealth traffic, so if it is not set the FireBrick® will work in stealth mode and will only communicate with local networks. It is important to set the gateway address when the FireBrick® is being used as a router (with or without NAT) and is treated as a gateway itself by local computers. It is also important to set this when the FireBrick® needs to know the time of day itself and the time server is on an external machine (as it will be if the default time server is used).
If the FireBrick® is a DHCP client on the specified interface then the gateway is normally set automatically. To remove the gateway, set the address to 0.
You can change the address that is intercepted, but it is unlikely you will ever need to. If you have given your FireBrick® a real IP address then you may not want to allow any interception, in which case set this address to 0. Please test access to the configuration pages using a real IP address before you do this as you might otherwise be completely locked out (see Don't Panic).
You can also set an address for the WAN stealth operation. This is an address that the FireBrick® borrows for things it sends to the internet itself, such as time requests. It is only necessary if you are not giving the FireBrick® one of your real IP addresses, in which case it should be set the the address of a computer on your network which will normally be switched on. The FireBrick® only borrows this address for specific communications such as time setting requests, and will not normally interfere in any way with the operation of the machine whose address is borrowed. If you do not set this address, or set it incorrectly, then some functions will not work in stealth mode (such as time setting from an external server).
Note: Setting the stealth IP is not the way to give the FireBrick® an IP address. If you want the FireBrick® to be on your network with a normal IP address, use the subnets menu.
In order for the time setting to operate the FireBrick® must know a route to the internet (set the default gateway route) and if it has no IP of its own then it must have one defined (stealth WAN IP address). Once this is set the FireBrick® can set the time automatically. The status screen will show if the time is set.
The default time servers are time-a.nist.gov and time-b.nist.gov, two US government time servers.
The time server uses standard internet RFC868 time protocol on UDP port 37. It sets the time once per hour at an arbitrary time during the hour. You can configure a time profile to restrict this to certain times of day and days of week if you prefer (useful if you have an ISDN router and intranet access costs call charges). On power up the time is also set. If the FireBrick® cannot set the time it will keep trying for 2 minutes, and then give up for about an hour before trying again. Once the time is actually set will it stick to the time profile you have selected.
Note that you may find you are logged out as soon as the clock is set for the first time (e.g. just after setting the gateway). This is normal - the FireBrick® thinks you have been logged in for 30 years and times you out!
Once you have a syslog server set up you can set the syslog IP address for that server. This will log various system messages from the FireBrick®. You can set network filters to generate logs when specific traffic is rejected or accepted.
If the FireBrick® is a DHCP server then it gives its own address as the DNS server, and relays requests to the real DNS server.
The stealth controls allow you to turn off various aspects of stealth operation. These are for advanced use. If you are using the FireBrick® only as a router, you can turn off stealth completely.
The default filter controls the logging of sessions that do not match any other filter, and importantly, this also controls whether the session is allowed or not.
A number of other system events can cause logging :-
| Event | General event (e.g. FireBrick power up) |
| Alert | Unexpected event (e.g. duplicate IP seen on network) |
| Debug | Additional information, particularly DHCP and unexpected ARP events |
| Login OK | When someone logs in |
| Login Bad | When someone fails to log in |
| DHCP OK | Normal DHCP events, such as allocation of an IP address |
| DHCP Bad | Problem DHCP events, such as duplicate IP, unable to set an address, etc |
| Ping scan | Machines going on and off line as a result of profile monitoring |
| Large sessions | Sessions where more than a specified amount of traffic was transferred |
You can also set the server IP address for emailing (where filter/log option Email is selected). You can set the from and to address of the email, and some hold off times. The first time is a hold off before sending an email - allowing other emailable log events to be included in the email. The second is a hold off after the email - allowing you to ensure you don't get a flood of emails. You can also restrict emails to certain time periods. Note that once within the time period, any emailable entries in the log are emailed, even if caused outside the time period - but this would all be in one email to catch up with the log. The log has a finite size, and data may be lost from the log if the delay before sending is too long.
| Pad IP to three digits | If set, all IPs are padded to 3 digits, e.g. 001.002.003.004 instead
of 1.2.3.4
Also, ranges are shown in full, e.g. 192.168.001.000-192.168.001.255 instead of 192.168.1.0-255 Note, you cannot normally type such address in to a computer as it may see them as octal. |
| Number grouping | All numbers over 1000 can be grouped with a comma, dot, or space. e.g.
23,656,232 instead of 23656232
This makes logs showing amounts of data transferred easier to read. |
| Decimal point | When decimal values are shown, the decimal point can be a point or a comma |
| Date format | The date can be ISO (2000-02-28), US (2/28/2000), UK (28/2/2000) or full (28th February 2000) |
| Protocol input | You can select protocols on filters, etc, using a basic pull down menu giving the choices Any/ICMP/UDP/TCP, a pull-down menu giving a full list of protocols, or an input box in which to type the protocol number. |