Networking-Blog

My WordPress Blog

Categories

FireBrick Weighted Guide

Weighted rules

Routing and Mapping rules can include a weighting factor between 0% and 100% which allows the rule to be applied randomly with a specific chance. This feature can be useful when load sharing traffic between different ISPs or different servers.

To use the feature you make a number of rules, each with the same criteria (IP, port/protocol, etc) and each with its required destination. You then set a weighting on each rule.

For example, if you had two ISPs, you may make two rules (after subnets) routing to each gateway and NATing your traffic. Each rule may have a weighting on 50% making half the sessions go via one ISP and half via the other. If you needed to bias the weighting, e.g. one was a 2Mb link and the other a 500Kb link, you might want to have the rules weigthed 80% and 20%. If you had four equal rules you could set 25%, 25%, 25% and 25% to give each an equal chance.

When setting up weighted rules you should follow these basic guidelines :-

  • Group your rules together. This improves efficience and makes it easier to read and manage
  • Ensure the rules all have the same criteria (same IP and ports and protocol to be checked)
  • Ensure the weightings add up to at least 100%. E.g. for three equal rules, use 34%, 34% and 34% (not 33%, 33% and 33%)

Fallback

If you make your rules dependant on a profile, for example a ping profile that checks that the corresponding server or ISP or router is working, then you can ensure that only rules which will work are considered. This is a very useful feature when using load sharing as it ensures that the load is shared between the working options.

The FireBrick will consider inactive rules that would otherwise match when trying to find a set of rules making at least 100%. This means that if you had, say, five options each of 20% and one was inactive then the remaining four would be considered equally as if they were all 25%. This means the set of rules is still applied as long as at least one of the rules is active. If all of the rules in a set are inactive then later rules are considered as normal.

Technical Reference

  • Each rule is considered in turn, and only rules which match the session are considered. Other rules that do not match have no affect
  • Where a matching rule is weighted under 100%, then later matching rules are considered until a total of at least 100% is found
  • In finding a total of 100%, inactive matching rules are counted
  • If there are no active rules in the set of matching rules that are found, then checking continues looking for the next match and possibly another set
  • If there are active rules in the set of matching rules, then one of these is picked randomly based on the weighting of active rules
  • In the routing rules, the subnet rules are checked as normal, so you should not make a set of weigthed rules span before and after the subnet rules
  • If the end of the rules is reached without a set being coimplete, e.g. 33%, 33% and 33%, then the rule set is not considered at all
  • Care should be taken to ensure rules add up to at least 100%. E.g. 33%, 33%, 33% and then a later 100% match would actually share traffic 4 ways, 33/199 for each of the first and 100/199 for the last. For three way, use 34%, 34% and 34%. This makes more than 100% but will ensure equal sharing. 33%, 33%, and 34% is obviously valid but gives the last rule a slight bias.
  • Care should be taken to ensute rules have the same critera, otherwise some sessions may only see some of the rules in a set and so the set not complete or the behaviour not be as intended.
  • In the routing rules, the default rule is not actually in the table, so does not complete a set. As such an incomplete set before the default rulle will simply mean all traffic goes via the default rule. This is different to behaviour in previous versions which would allow, for example, a single 50% rule and then the default rule. Such a combination would not always use the default rule.
FireBrick
No comments yet.

Tags: ,

by admin

FireBrick Shape Guide

Shaping rules

The FireBrick can be used to change the rate of traffic using speed lanes. The shaping rules define in to which speed lane each type of traffic is assigned. They operate much like filters. The first in-profile rule which matches the traffic in question is applied. If no rules match then the default master lane is used.

Name Allows you to give a name to this rule
Security Sets the security level of this rule and so defines who can view or edit the users details
Profile Defines the profile when this rule applies.
Source This allows you to specify one or more source interfaces from which the traffic may come
Target This allows you to specify one of more target interfaces to which the trafficmay be going
Lane This specifies the lane to be applied to the traffic
Both ways This makes the rule work both ways saving making two rules.
Source ports This allows a range of source ports to be specified. Applicable to TCP and UDP. Normally blank meaning any.
Target ports This allows a range of target ports to be specifiied. Applicable to TCP and UDP. Typically just one port for the specific protocol, e.g. 80 for WWW
Protocol This allows the specific protocol to be specified, or Any.
Port group Instead of using a source port range, target port range and protocol, then a named port group can be selected.
Source IP range Allows the range of source IPs to be specified, or blank for any.
Source IP group Instead of an IP range, a named IP group can be selected.
Target IP range Allows the range of target IPs to be specified, or blank for any.
Target IP group Instead of an IP range, a named IP group can be selected.

Technical Reference

  • Shaping rules are constantly rechecked in case profiles have moved traffic to a different speed lane. This can mean a few seconds delay in re-assigning traffic.
  • The target IP and ports are those before any NAT or mapping, altough the rule is actually applied at the end of the process of setting up a new session
  • Both ways operates on traffic from source IP, source Port and source interface to target IP, target port and target interface as well as from target IP, source Port and target interface to source IP, target Port, and source interface. I.e. the ports are not swapped as traffic is normally classified by target port regardless of direction of data.
  • Selecting Any protocol and no ports set means any protocol. Selecting Any with ports set means TCP or UDP only.
FireBrick
No comments yet.

Tags: ,

by admin

FireBrick Speed Guide

Speed lanes

The FireBrick can manage the rate at which traffic flows using speed lanes. Traffic is placed in a speed lane using the shaping rules. All traffic in any speed lane is controlled by that lane – the speed is for the total traffic in the lane.

Speed lanes allow control of the rate at which traffic flows from and to each possible interface. You can select the interface you wish to view/control, the default being the interface current set for the default gateway (normally WAN).

Settings

Name Specify a name for the speed lane, e.g. “slow”
Security Controls which users can view or edit this speed lane
Master Select a master speed lane which also applies to this traffic
Rate Min The minimum speed setting in Kbits/s
Rate Max The maximum allowed speed setting in Kbit/s or blank for no limit
Fast This means that this speed lane is not also limited by the master speed lane, but the master lane is affected by this traffic.
ACK Setting this means that the responses to TCP messages are priority and not delayed. They still affect the speed lane and so delay other traffic.
QOS This means that traffic with a fast type of service are priority and not delayed. They still affect the speed lane and so delay other traffic.
ms This allows a number of milliseconds latency to be added to all traffic to that interface via this lane.

The first speed lane is the default which is applied if there is no rule to allocate the traffic. It is also the default master speed lane of other lanes.

Traffic is assigned to a speed lane using the shaping rules, and the speed limits applied for that lane, but then the master speed lane is also applied. The master speed lane is usually used to allow the speed of an external internet feed (e.g. ADSL router) to be set, and allow some traffic to go in a lane marked fast to jump the queue.

This means that traffic may have up to 4 consecutive speed restrictions applied – from a lane and a master and to a lane and a master.

Statistics

If the clock is set, then various statistics are shown on the speed lanes…

Rate Set The currently selected rate. Where take is selected, the current rate being used is shown in brackets
Rate Now The instantaneous rate indication for the last whole second in KB/s or Kb/s.
Rate 5min The average rate over the last whole 5 minute period in KB/s or Kb/s
Day This The total transferred so far today, in MB
Day Last The total transferred in the last whole day, in MB
Month This The total transferred so far this month, in MB
Month Last The total transferred in the last whole month, in MB

Note that the rate set and now can be displayed in Kbits/s or Kbytes/s depending on UI settings.

Technical Reference

  • The Fast QOS flag works on packets with IP TOS (type of service) set to the value defined in the setup (default 160, typically for VoIP)
  • The Fast ACK flag applies to any TCP packets with no payload. It applies if the specific speed lane has Fast ACK set.
  • Traffic shaping operates by scheduling packets based on the time they would be sent if the link was the specified speed. This allows smooth operation with TCP and other protocols. Packets that queue jump (e.g. ACK or QOS) are counted and so slow later traffic hence maintaining the overall speed limits.
  • Where a master speed lane has a minimum speed set, and there is spare unused capacity below that setting, then that spare capacity is added to the current usage of all subordinate lanes (subject to specified min and max speeds on each lane). This allows the spare capacity to be shared out. As the spare capacity is used, the subordinate lanes will move down to their minimum setting. By setting the max to the same as the min on any lane you can stop spare capacity being taken like this.
  • Last day and Last month may be distorted if the FireBrick has been running for some time with the clock not set as these figures are updated on change of day or month.
  • It is important to realise that the speed lane applies to the total traffic in that lane. E.g. if you have a lane of say 64Kb/s, and put web traffic (TCP port 80) down it, then this does not mean that each web page will be 64Kb/s but that the total of all sessions on that lane is limited to 64Kb/s – the more simultaneous sessions the less each gets. As such, you can have multiple lanes at the same speed and assign different traffic to different lanes.
  • This allows simulation of long latency lines such as satellite links. Note that there is limited buffering capacity, so high bandwidth high latency links can result in packet loss. Latency settings are limited to a maximum of 5000ms and so not suitable for RFC1149 simulation.
  • Some internally generated packets are never subject to speed lanes, such as DHCP request/replies, pings for profiles, and tunnel keep alives.

Master speed lanes

Traffic is assigned to a single speed lane using the shaping rules. Each speed lane may then also list a master speed lane which is also applied. The idea behind this is that you may want to control various types of traffic which all then go via a simple feed (e.g. an ADSL line). The master speed lane allows you to then control the rate at which the traffic is actually sent overall. By limiting this you can avoid the external routers buffers filling. This means that traffic marked fast is able to jump the queue on the FireBrick and then not hit another queue in the external router. This is particularly useful for voice over IP over ADSL, for example.

  • Statistics record details of the traffic through the lane in each direction depending on the interface. They are also counted on the corresponding master speed lane.
  • The from interface statistics includes traffic that has been discarded because of the speed restriction. The to interface statistics only shows traffic which is being sent.
  • The statistics ar recorded as entries are recieved or placed in the queue, and so may show higher than the rate set even though the rate limiting is working perfectly.
  • Traffic that is QOS or ACK is unaffected (i.e. not delayed) by its speed lane or the master, but it does contribute to the usage of both and so slows other traffic.
  • Traffic that is Fast is affected by its own speed lane but not by the master. The master speed lane is however affected by the usage and so slows other traffic. I.e. traffic marked fast effectively stealths bandwidth from the master speed lane.
  • Latency added is added for the specific speed lane and the master speed lane for the from and to interface making a total of 20s latency possible.
FireBrick
No comments yet.

Tags: ,

by admin

FireBrick Address Mapping Guide

Address mapping

Address mapping allows a change to be made to the ports and IP addresses of traffic going via the FireBrick. This is the same principle as NAT, but allows more specific changes to be made. All new sessions are put through the address mapping table, and the first applicable entries is used.

Name Allows you to give a name to this rule
Security Sets the security level of this rule and so defines who can view or edit the users details
Profile Defines the profile when this rule applies
Source This allows you to specify one or more source interfaces from which the traffic comes from
Target This allows you to specify one of more target interfaces to which the traffic was originally being sent (after any routing)
Map traffic to This defines the new interface to which the traffic is to be sent
Weight For advanced use
Source ports This allows a range of source ports to be specified. Applicable to TCP and UDP. Normally blank meaning any.
Target ports This allows a range of target ports to be specifiied. Applicable to TCP and UDP. Typically just one port for the specific protocol, e.g. 80 for WWW
Protocol This allows the specific protocol to be specified, or Any.
Port group Instead of using a source port range, target port range and protocol, then a named port group can be selected.
Source IP range Allows the range of source IPs to be specified, or blank for any.
Source IP group Instead of an IP range, a named IP group can be selected.
Target IP range Allows the range of target IPs to be specified, or blank for any.
Target IP group Instead of an IP range, a named IP group can be selected.
New target port This allows the target port to be changed. Leave blank for no change
New source IP This allows the source IP to be changed. Leave blank for no change. Set to 255.255.255.255 to cause NAT.
New target IP This allows the target IP to be changed.

Technical Reference

  • Both stealth and routed traffic is considered, and any mapped traffic becomes routed.
  • Filters are applied before the traffic is mapped
  • If a mapping rule matches, then routing is re-done with the new target IP, ports, etc.
  • Speed lanes are applied to the pre-mapped IP and ports, but the mapped target interface
  • If there is mapping entry the the routing table is reconsidered
  • If a target IP range is specified (not an IP group) then the new target IP defines the value mapped for the first of the target range specified. The next is the new IP plus one and so on. i.e. a block of target IPs is remapped to a blank of new IPs. If this is not required then use an IP group to specifyc the range.
  • Setting the new interface to a partial interface, e.g. just WAN with no subnet selected, will restrict the routing rules considered to be on that interface.
  • Setting the new interface to Any will allow the routing rules to decide the new target interface
  • Setting the new source IP to 255.255.255.255 causes the FireBrick to use NAT, using an IP appropriate for the subnet on which is eventually sends the packet.
  • See Weighted rules for details on how to use the Weight option. This applies only with the bonding feature.
FireBrick
No comments yet.

Tags: ,

by admin

FireBrick Port Guide

Port/Protocol groups

In many places, such as traffic shaping, filtering, routes, etc, you can set a range of ports and protocols to define the type of traffic being referenced. Some types of traffic use a number of different ports and protocols but you would want to allow all of these in one filter or use them all in one route. Port groups allow sets of protocol/port combinations to be defined as a named port group and used instead of specific ranges in filters, routes, etc.

Name Give the group a meaningful short name as this is what is shown in the list when groups can be used.
Security This defines who can view or edit the group
Protocol This allows the specific protocol to be specified, or Any.
Source ports This allows a range of source ports to be specified. Applicable to TCP and UDP. Normally blank meaning any.
Target ports This allows a range of target ports to be specifiied. Applicable to TCP and UDP. Typically just one port for the specific protocol, e.g. 80 for WWW
Add Adds an entry to the group
Delete Deletes the individual entry from the group
Erase Erases the whole port group and all entries within it

FireBrick Tunnel Traffic

A default port group in the factory reset config is FireBrick tunnel traffic which uses UDP port 1.

Technical Reference

  • The security on a group does not affect whether a user can use the group.
  • You can add a blank Any entry but this is pointless as the whole group becomes Any and you could simply not use a group instead.
  • You cannot edit an entry, but you can add a new entry and then delete the old one.
  • You cannot reorder entries as the order does not matter.
  • The extra handling for ICMP types as applicable to filters does not apply within port groups
  • If port ranges are specified with protocol Any then this means TCP or UDP as ports only apply to these
FireBrick
No comments yet.

Tags: ,

by admin

FireBrick Filters Guide

Filters

Filters are the way that the FireBrick provides firewall protection. The FireBrick tracks every session, and applies filters when that session starts. Once checked against the filters, the session is then allowed even if the filters later change. Filters are considered in order until one matches, and then the filter rule applied to the session.

Name Allows you to give a name to this rule
Security Sets the security level of this rule and so defines who can view or edit the users details
Profile Defines the profile when this rule applies
Source This allows you to specify one or more source interfaces from which the traffic may come
Target This allows you to specify one of more target interfaces to which the trafficmay be going
Action This defines the main action which applies, Allow, Drop, Bounce or Reject as described belwo
Source ports This allows a range of source ports to be specified. Applicable to TCP and UDP. Normally blank meaning any.
Target ports This allows a range of target ports to be specifiied. Applicable to TCP and UDP. Typically just one port for the specific protocol, e.g. 80 for WWW
Protocol This allows the specific protocol to be specified, or Any.
Port group Instead of using a source port range, target port range and protocol, then a named port group can be selected.
Source IP range Allows the range of source IPs to be specified, or blank for any.
Source IP group Instead of an IP range, a named IP group can be selected.
Target IP range Allows the range of target IPs to be specified, or blank for any.
Target IP group Instead of an IP range, a named IP group can be selected.
Timeouts For advanced use
TOS For advanced use
Blink Causes the ALERT light to blink every time this filter matches.
Flash Causes the ALERT light to start blinking if this filter matches. It blinks until reset.
Log Causes the filter to be logged in the internal log
Syslog Causes the filter to be logged to an external syslog server
Email Causes the filter to be logged to email
Quick setup Shows this filter on the quick setup menu
Suspend Causes this filter to be ignored, like profile Not 24/7.
SYN For advanced use
Bypass For advanced use
End-log Causes logging of the end of the session regardless of the size of the session

Actions

The actions define what happens to the session. Only Allow casues a session to be created.

Allow The traffic is allowed and the session created. All corresponding reply traffic and further traffic on the same session is allowed automatically even if the filters later change.
Drop The packet is dropped / ignored
Reject The packet is dropped, and an ICMP admin prohibited filter error message returned to the sender
Bounce The packet is dropped and a valid response is sent to try and annoy the senders system. This is not a counter attack though.

Statistics

If the clock is set then a number of per filter statistics are available. These are a total of traffic both ways through the sessions associated with each filter.

Rate Now The instantaneous rate indication for the last whole second in KB/s or Kb/s.
Rate 5min The average rate over the last whole 5 minute period in KB/s or Kb/s
Day This The total transferred so far today, in MB
Day Last The total transferred in the last whole day, in MB
Month This The total transferred so far this month, in MB
Month Last The total transferred in the last whole month, in MB

Note that the rate set and now can be displayed in Kbits/s or Kbytes/s depending on UI settings.

Technical Reference

  • The timeouts, if not blank, define the initial and ongoing timeout for the session in seconds. If blank then defaults are used depending on the traffic. For UDP the default is a long initial timeout and short ongoing timeout. For TCP it is a short initial timeout and long ongoing timeout. The initial timeout is the session timeout before any reply has been received. The ongoing timeout is the session timeout after any reply packet has been received.
  • If not blank, the TOS mask and value can be set to allow the traffci to be checked for TOS value. The TOS value is ANDed with the mask and check against the value. Note that the TOS of the initial packet in a session is checked only.
  • If SYN is set then a TCP session will only match this filter if it has SYN and not ACK set.
  • Bypass cuases the filter to be applied as normal, but does not allow a session to be created. This allows per packet rather than sessions based filtering if required. This is much slower but can be used where a machine is, for example, deliberately port scanning through a FireBrick and so many sessions would not timeout for a long time.
  • End log will cause logging as per the log large sessions settings in the main setup menu, which may not be the same as those of the filter.
  • If filters are moved, then statistics for on-going sessions may become distorted.
  • For the Bounce action, the packet is dropped, but for ICMP pings a ping response is generated, and for TCP connections a SYN+ACK response is generated. This simulates a valid connection. The TCP response has a window size of 0 which will lock up some TCP stacks. The responses are also randomly slow (around 300ms) and so lower priority compared with real traffic. The bounce mode is intended to cause annoyance to a would be attacker.
  • If no filter matches, the default filter is used as specified in the setup menu.
  • Before the default filter there is an implicit filter allowing LAN to FireBrick port 80 and allowing FireBrick to any traffic. Explicit filtering rules can however block this default behaviour if required.
  • Filters are applied after routing is done (as filters used the target interface that has been decided by the routing rules).
  • Filtering is done before address mapping and so any IPs and ports apply before the addresses are changed.
  • Filtering is done before NAT is applied
  • Filtering is also done before traffic shaping.
FireBrick
No comments yet.

Tags: ,

by admin

FireBrick Setup Manual Guide

Setup

The setup function consists of a number of general setup facilities that can be selected from a sub menu.

Save config

This allows the current configuration of the FireBrick to be saved on your local PC. Selecting save config will normally cause your browser to pop up with a save box allowing you selected where to save the config. The default filename is the serial number of your FireBrick, allowing you to save many configs in one directory without risk of overwritting a different one. Once saved, the config can be reloaded in to the same or a different FireBrick. It is recommended that after any major changes you save your config

Clear Alert

If an alert is set (using Flash in any filters) then this stays set and the ALERT light continues to flash until you clear it using this link. The date/time is shown as when the alert was first set (if the clock is set).

Upload/Restore

This allows one of three types of files to be uploaded. Simply select the required file using the Browse button and click Send.

F A flash file can be obtained from the FireBrick software web site. Uploading this will reprogram your FireBrick with a new version of software and usually then require the loading of a W file. The FireBrick will stop operating for up to a minute while flashing new softwate.
W A web file contains all of the user interface (web pages) allowing you to manage your FireBrick. Without this you will see a User Interface Required page where you can load any of these 3 file types. Normally, for English web pages the file ends in WEN. You must load the version expected, or load a new flash file or config.
Config A saved configuration file can also be loaded. This will completely replace the previous configuration with the new configuration.

LEDs

The LEDs (lights) over each port can be controlled in a number of different ways depending on your preference. There are 6 pre-defined combinations, a cycling lights option and the option to choose the yellow and greed LED functions directly. When cycling lights are selected the 4 ports on the right cycle the LEDs left/right/left all the time.

Ports

The Ports menu allows settings for all 5 ports to be controlled. With the 5PORT option the port configuration can be selected. Without the 5 port option, the WAN/LAN reverse can be selected. For normal use the settings should all be left on Auto.

Name Interfaces are normally called WAN or LAN, but you can set the name yourself.
Crossover Normally the FireBrick can be connected using a straight or crossover lead to a hub/switch or a computer directly. This allows specific select of the crossover mode (MDIX is a normal switch/hub connection and MDI is a normal PC connection).
Speed Normally the FireBrick detects 10base-T or 100base-T automatically, but the port can be fixed to only one speed.
Duplex Normally the FireBrick detects Full or Half duplex mode, but the port can be fixed to only one mode.
Disable Causes the port to be disabled, allowing no traffic in or out.
Throttle Causes the speed of traffic in and out to be cut to 128Kb/s. This is not traffic shaping but a crude packet limit which can be useful for network debugging.
B/Limit Causes the speed of any broadcast traffic (or mulicast or flooded unicast) traffic to be limited to 128Kb/s. This can help track down and limit broadcast storms or loops and is mainly useful for network debugging.
Long Ethernet cables are meant to only run 100m max. This option allows 10base-T sensitivity to be increased to allow use over longer cables (at your own risk).
Test This causes a line test of the port (see below)
Reverse This allows the WAN and LAN side to be reveresed. The change takes affect when you reset the FireBrick

Line test

The line test will take the port out of action for a few seconds and perform a time domain reflectometry measurement on the cable. The results are indicated on the right of the table when the tests are complete and remain visible until next reset/power cycle. This type of test can be effective on cables over 3m in length but the results should always be considered only an approximate indication.

If a cable is connected to a correct hub or switch or computer at the far end then the test simply indicates connected. If the cable is broken or shorted then this is indicated along with the distance.

Name/etc

This allows the identity of the FireBrick to be set.

Name This names the FireBrick. Use a short name, usually related to the site name. To avoid problems with email, etc, use domain valid characters (a-z, A-Z, 0-9, and hyphen).
Domain This provides a domain name. Again, use domain valid syntax. This is used for DHCP and with the name for emailed messages. Put your valid internet domain.
Administrator Put the name of the administrator. This is for your own reference, but also reported if SNMP is enabled.
Location Put the location. This is for your own reference, but also reported if SNMP is enabled.
SNMP Community If this is not blank, then SNMP is enabled. Put the community name required, usually just public. Remember that you can use filters to restrict access to SNMP or any services on the FireBrick if required.
SNMP options The ifDesc option causes the SNMP ifDesc to be a simple unique number (the SNMP interface index in the OID) rather than a description. This is because some tools expect it to be unique (e.g. cfgmaker for mrtg)

Gateway

This defines the general gateway IP address and interface. It is used if there are no matching routes or subnets.
The recommendation is to make this a subnet and not set a gateway address as such – the subnet can then have the gateway defined, which could be by DHCP.

Bonding

For full details see the bonding section. This allows up to two pseudo gateways to be specified, and up to four real gateways to be used in their place on a cyclic basis.

Stealth

This is not how you give the FireBrick and IP address. You can speficy the LAN stealth address on which the FireBrick will answer even for traffic passing through it. The FireBrick effectively hijacks traffic to this address. You can also set an address for the FireBrick to borrow on the WAN when setting it’s clock, etc. This is normally the adderss of a machine on the LAN, and the FireBrick hijacks the replies to it’s requests which would otherwise go back to that machine.

Disable ARP Stops ARPs being sent automatically from one interface to another – this stops most stealth operations being possible in normal operation
Disable subnet broadcasts Stops subnet broadcasts (i.e. last address in subnet) being treated as stealth
Disable local broadcasts Stops local broadcasts (i.e. 255.255.255.255) being treated as stealth
Disable all stealth Disables all stealth operation

Time

The FireBrick sets and maintains its clock from the internet. To set the time the FireBrick will need a gateway and IP (or stealth WAN IP) so as to be able to send time requests to the internet. The default settings are correct for UK and UK summer time.

Server Specify the IP of the time server to try, normally 217.169.0.1
Backup Specify a second time server to use if the first does not respond, normally 217.169.0.2
Time offset Select the base time zone, e.g. for UK it is UTC+0
Summer time Select if it is summer time, although this is normally set automatically.
Start summer time Select the date and month, the Sunday on or after which the clocks go forward one hour. You can select manual to stop summer time being adjusted automatically. The time changes at 1am winter time.
End summer time Select the date and month, the Sunday on or after which the clocks go backwards one hour.
Profile The time is set every hour normally, although exactly when in the hour moves about deliberately. This profile allows this to be restricted to set the clock less often. On power up / restart, the clock is not set and so it continually tries until the clock is set, ignoring the profile selected.

Syslog

The FireBrick has an internal log, and can also log to a syslog server. This allows the IP and syslog type to be set.

Server IP Specify the IP of the syslog server
Port Specify the syslog port (normally 514)
Type Select the syslog type, local0 to local7
Optional Interface Specify the interface or interface and subnet on which the syslog is to be sent, otherwise normal routing rules apply
Optional Source IP Specify the IP from which syslogs are sent – can be any IP as there is no reply to a syslog. Normally set automatically. Using a subnet for the interface sets the IP of that subnet
Optional Gateway IP Specify the gateway IP to use. Normally set automatically. Setting a subnet for the interface sets the IP using the DHCP defined gateway for that subnet.

DNS

The FireBrick acts as a DNS relay, and uses DNS itself. This address defines the DNS server it uses.

Log/Filter Options

This allows defaults and options to be defined relating to logging and filtering. See filters for a description of Blink, Flash, Log, Syslog, and Email.

Default filter This defines the default filter action if no other filters are matched.
Event Certain events in the FirebBrick are logged as an “Event”. This controls if/how such things are logged. Generally an event is something that happens that is non critical.
Alert Alerts are normally more important events that are critical.
Debug Debug messages are general additional detailed information.
Stats Stats are generated automatically every 5 minutes showing usage of each filter and speed lane and interface.
Login OK If a user login is successful it is logged using these options
Login Bad If a user login fails, it is logged using these options
DHCP OK If a DHCP address is allocated (rather than renewed, which is a debug message), then these options are used.
DHCP Bad If a DHCP operation fails (e.g. no addresses left) then it is logged using these options.
Ping scan If a ping based profile goes on or off line it is logged using these options.
Tunnel state Log of tunnel state change (up/down), but does not exclude state changes for tunnels in “Timeout keep alive” mode as they would happen all the time.
Large sessions Sessions where more than a specified amount of data is transferred are logged at the end of the session using these options.
Email server This defines the IP of the email server to use to send emailed log entries
Test server This sends a test email
From address This defines the address from which the email is sent.
To address This defines the address to which the email is sent.
Holdoff Emails are not sent on the first emailable log event happening, there is an initial holdoff (in seconds) so that related events will appear in the same email. Once sent, there is then an additional holdoff which is mainly to limit the number of emails that can be sent when there is a recurring emaillable event.
Profile Emails are only sent during a selected profile.
QOS TOS value This allows the specific TOS (type of service) value that is considered to be priority traffic in bonded tunnels and speed lanes. This defaults to 160 which is typical for SIP phones. If using VoIP (Voice over IP) then ensure that you set all phones and links to use the same TOS and set the appropriate value here.

UI Options

Some general UI options can be set which affect the overall operation of the UI.

IP display/range Various options allowing you to change the way IP addresses and in particular ranges of addresses are displayed.
Number grouping This allows numbers to be shown with no grouping,or commas/dots or spaces every three digits from the right.
Decimal point This allows numbers with a decimal point to use a dot or a comma
Speed Select if you prefer to see speeds as KBytes/s (one decimal place) or Kbits/s
Date format The date format can be an ISO format (YYYY-MM-DD), UK (DD-MM-YYYY), US (MM-DD-YYYY) or full, e.g. nth Month YYYY
Protocol input The protocol selection in various places is normally TCP, UDP or ICMP only. This allows a full selection of all 254 protocols, or an input box to enter a protocol number.
Warning music There is normally a tune played on a suitably configured PC which is trying to login to a FireBrick without the correct username or password. This can be disabled.

Security

See security for a more detailed description of the security model. This allows the general security settings for control of all of the main icons to be specified.

Features

See features for a more detailed description. This allows the current and availabel features to be listed, and the FireBrick to be updated with new features.

On a new FireBrick you should configure internet access and DNS and time setting, and then select Install Assigned Features to ensure you have the full set of features provided with yoru FireBrick installed.

Technical Reference

  • The name and domain are used in the HELO of outgoing emails, and so should be set using domain valaid characters to avoid problems with some mail servers. Similarly the from and to email addresses need to be entered carefully.
  • Emailed logs include the first message logged on the end of the subject line. This can be useful if emailing an SMS gateway.
  • When cycling LEDs mode is used, the extra dot links control the phase of the lights. FireBricks connected using the WAN port and all set in the mode will synchronise themselves to product a dramatic effect.
  • When cycling LEDs mode is used, the left hand port used LED mode 5.
  • As soon as internet access from the FireBrick is possible (i.e. IP, gateway, etc) the clock may set and this will usually cause the logged on user to be logged off as the time jumps forward.
  • If a port is set all manually (no auto) then auto negotiaton is disabled. This allows operation with some types of router which do not understand auto negotiation or have it disabled. You should ensure any manual settings agree with the settings at the other end to avoid problems.
  • LED modes for SPEED and DUPLEX are lit for 100Mb/s and Full duplex.
FireBrick
No comments yet.

Tags: ,

by admin

FireBrick Status Information

Status/information

The FireBrick contains a number of useful information and diagnostic tools as follows:-

Status

WAN/LAN This shows the state of the port, green if it is connected, and the speed and duplex mode
Serial Number This is also shown on the top left.
Base MAC This is the base MAC address used by the FireBrick. The FireBrick uses different MACs depending on the subnet.
Time now The current time, if set. Note that the setup/UI options allow the format of the time to be changed
Clock last set The time when the clock was last set. The clock is normally set every hour.
Running since The time when the FireBrick was last reset. Shown if the clock is now set.

DHCP

This lists all of the DHCP addresses the FireBrick has allocated, the time they are due for renewal (2 hours after they were issued), the MAC address and the machine name. Where there was no machine name you can set one manually by entering a name in the input box and pressing return.

The FireBrick tries to keep the same address for each device, and will only re-use an address if it is available and is the oldest (i.e. not used for the longest). You can manually clear an allocation by clicking on the interface.

ARP

This lists the FireBrick current ARP table, listing the interface, IP address and MAC address of any currently active IPs communicating with the FireBrick. If the MAC is all 0’s then the device is not (or has not yet) responding and may be turned off or disconnected.

MAC

The MAC report shows the MAC addresses seen currently on each interface. Against the MAC the interface name is listed. This allows teh specific prot to be identified. The MAC list includes addresses sent by the FireBrick as well, and these are marked with the FireBrick’s name and not a port name,

Sessions

The session list shows all currently active protocols, and also links for ALl, 1MB, and 10MB. The All link shows all current sessions, whilst 1MB and 10MB show sessions that have currently transferred more than 1MB or 10MB respectively. Selecting a protocol shows all sessions using that protocol.

The session table starts with an S for Stealth and R for Routed and then the protocol name. Clicking on the protocol kills the session.
Next, it shows the interface, IP(s), Port(s) and amount of data send from one end, and the same for the other end of the session. Normally there is only one IP and Port on each, but where NAT applies or address mapping is used there may be two IPs and/or ports listed.
Finally, it shows what filter and speed lane is applied to that session.

Log

The log contains everything marked log on the general log/filter setup or specific filters. If the clock is set then the log shows the time of each entry. There is space for over 1000 log entries, and the oldest entry is lost as new ones are added.

Selecting log shows the log on a page and keeps that page open watching the log in real time.

Selecting recent shows the log in the same way, but starting from only 5 minutes ago.

Selecting save shows the log but does not follow changes live and clears the log once displayed. This is useful for saving the log or clearing it.

Counters

The counters section shows counters for various statistics recorded against each port. These are mainly used for debugging network problems.

The core counters relate to traffic to/from the internal FireBrick routing/filtering core.

The change in the last second is also shown, which can be used to see instantaneous throughput on ports, etc.

Technical Reference

  • Note that the status shows the names of the ports which could be WAN and LAN1-4, or LAN and WAN1-4 if the LAN/WAN reverse option applies, or could be any names you have given if you have the 5PORT option.
  • The status of a port can show negotiated or not. If negotiated then this means that auto-negotiation was used. There are also notes for errors such as polarity reversed (where the wires within a pair are swapped). Some hubs/switches are wired incorrectly and show this, but this normally means the cable is incorrect. Polarity reversal is automatically compensated for. Other faults include jabber which means a faulty bit of equipment or cable, and remote fault which is a special flag in the auto negotiation to tell uss that the other end is seeing a fault in what we are sending.
  • The MACs used are the Base MAC plus the subnet number, or plus 31 if no subnet can be found. This allows different subnets to act as DHCP clients on the same LAN if necessary, each getting a different address.
  • When using stealth the MAC report can be a bit confusing. e.g. Traffic from the LAN to WAN shows as LANn on the LAN side, and as FireBrick on the WAN side because the FireBrick will have received it from LANn on the LAN and sent with the MAC unchanged out on the WAN.
  • Counters are 32 bit wrapping numbers.
FireBrick
No comments yet.

Tags: ,

by admin

FireBrick Profile Guide

Profiles

FireBrick profiles are a very powerful feature. Most settings on the FireBrick have a profile, which is by default 24/7 (always active). There are standard profiles for 24/7, 9-5M-F and 2amSun. Additional profiles can be based on time, or pinging an address, or manually switch on the main dragon page along with quick filters.

Name Allows you to name the profile. It will then appear against most other items with that name and with Not that name.
Security Defines the security level controlling which users can view or edit this profile.
Profile Allows this profile to depend on another profile, either AND or OR another [not] profile. If unsure, leave as AND 24/7
Mode The profile can be time based, or manually controlled, ping based or checking tunnel state.
Alert LED This allows the RED alert LED on the front of the FireBrick to be affected by the profile automatically.
Re-route If this is set and a profile changes, traffic is re-evaluated for possible re-routing if routing rules are based on this profile.
Ping address If a ping profile, this is the address to ping
Ping TTL This allows the time to live to be set on the pings.
Optional Interface Allows you to specify an interface or interface and subnet via which pings are to be sent, otherwise normal routing rules apply. This is also used for tunnel state mode to specify the tunnel.
Optional Source IP Allows you to specify the source IP for the ping. This is normally set automatically, and setting a subnet/interface (above) will set for that subnet specifically
Optional Gateway IP Allows you to specify the gateway IP for the ping. This is normally set automatically, and setting a subnet/interface (above) will the DHCP gateway for that subnet
24/7 Ticking this causes all hours of all days to be set on
As above This allows one day to be set the same as the previous
9 to 5 This forces a day to be set for 9am to 5pm
Clr/24 The clr option causes the whole day to be cleared, and the 24 option causes the whole day to be set on
Hours Each hour can be set on or off specifically. This affects timed profiles, and also when pinging is done.

The profile types are:-

Timed The profile is based on the time of day and day of week – you can select on an hour by hour basis. If the clock is not set then the state (active/inactive) of the profile does not change.
Enabled The profile is permanently enabled, the time settings are not relevant. During the selected times, the profile appears as a check box on the login screen allowing to to be changed to disabled.
Disabled The profile is permanently disabled, the time settings are not relevant. During the selected times, the profile appears as a check box on the login screen allowing it to be changed to enabled.
Ping The profile is based on pinging an IP address which can be via a specific interface and gateway and also from as specific source addree. Pings are done during the enabled times.
Tunnel state The profile reflects the state of the tunnel specified in the optional intergace. A specific tunnel must be selected.

Technical Reference

  • Ping profiles cause a ping to be sent every second to the specified destination. If there is no response for 5 seconds, then the profile is down. Pings continue every second, and if there is one response then the profile is up.
  • Avoid making profile inter dependance loops – it will not crash or hang the FireBrick but will have unpretictable results.
FireBrick
No comments yet.

Tags: ,

by admin

Firebrick Subnets Guide

Subnets

The FireBrick can operate like any conventional network device with an IP address and netmask. However, the FireBrick can have multiple addresses and be on multiple networks at the same time even on the same physical network. The subnets allow the network address to be defined as well as DHCP and other settings.

Name This allows the subnet to be given a name, but default it uses the name of the interface. The choice of name is important when used with the DHCP restrict feature
Security This sets the security level and controls who can view or edit this subnet
Profile The subnet can be subject to a profile, allowing the subnet to be visible part time
Interface This defines on what interface the subnet operates
IP address This specifies the IP address of the FireBrick on this subnet. As such it cannot be the network or broadcast address for the subnet
Subnet Mask This defines the subnet mask applicable.
DHCP Client If selected then this subnet is a DHCP client, and most settings will be overridden when the FireBrick obtains an address by DHCP. To make a subnet DHCP you do not need to fill in the IP or netmask or any other details.
Stealth Set this if there is a subnet on the other side of the FireBrick with the same IP range and traffic is to pass through by stealth.
NAT Set this if this a subnet using a private address range and address translation is to be used
VLAN ID For advanced use
Allocation IP range To make the subnet act as a DHCP server, an address or range of addresses can be specified. This sets the range of addresses that can be allocated.
DNS servers As a DHCP server, you can specify the DHCP server to issue. Leave blank for the FireBrick to act as a DNS relay. As a DHCP client, this shows the DHCP servers the FireBrick received.
Gateway This is the gateway applicable for any traffic routed to this subnet.
As a DHCP client, this is filled in automatically.
As a DHCP server, this is given out as the gateway, or if blank then the FireBricks IP is given out instead.
BOOTP server IP For advanced use
BOOTP filename For advanced use
Exclude gateway Setting this means the FireBrick does not issue a gateway address as a DHCP server, and does not accept one as a client.
Exclude Time server Setting this means the FireBrick does not issue a time server address as a DHCP server, and does not accept one as a client.
Exclude Syslog server Setting this means the FireBrick does not issue a syslog server address as a DHCP server, and does not accept one as a client.
Exclude DNS server Setting this means the FireBrick does not issue a DNS server address as a DHCP server, and does not accept one as a client.
Exclude Domain Setting this means the FireBrick does not issue a Domain name as a DHCP server, and does not accept one as a client.
Backup DHCP Setting this means the FireBrick will not answer the first time for any DHCP client, allowing another server to answer normally and making the FireBrick a fallback server.
Don’t check For advanced use
DHCP restrict For advanced use
DHCP Mirror For advanced use

Technical Reference

  • The FireBrick uses a difference MAC address on each subnet, and so can be a DHCP client multiple times on the same interface.
  • Subnets that are on an inactive profile do not answer ARPs for their IP, but previous ARPs may remain cached by other machines for a short period allowing traffic to be routed via the FireBrick after a profile becomes inactive.
  • When a subnet is made active the FireBrick sends an ARP announcement.
  • The FireBrick treats the network address on a subnet as a valid IP and not as a broadcast IP
  • The subnet mask can be entered as a dotted quad (e.g. 255.255.255.0) or as a bit count (e.g. 24). It is normally displayed as a bit count.
  • As a DHCP client the FireBrick sends its name and the subnet name concatenated with a space between as the subnet name.
  • If stealth is set then the FireBrick will answer traffic for its IP, but other traffic on this subnet can be passed through the FireBrick (subnet to filtering) in stealth mode. If not set, then traffic for any of the IPs on this subnet are considered to be on that subnet and not passed through as stealth. In particular, this affects stealth transmission of ARP requests.
  • The NAT setting causes any traffic from the subnet to be NATed if there was not an explicit route used to direct the traffic. If an explicit route is used then the NAT setting for that route applies. Note that this means traffic between two private subnets using subnet based routes will NAT if the subnets are set to NAT even though this may not be necessary if both networks use the FireBrick as a gateway.
  • The DHCP range can be one address, a range, or an IP and mask or IP and bit count.
  • DHCP allocations check that the address to be allocated is no in use by another machine (using an ARP) and abort if it is. As such addresses can be marked as in use in the status/DHCP report and not actually allocated. This avoids duplicate IPs.
  • DHCP allocates are for 2 hours with 1 hour renewal, but allocations are persistent – using the same address each time unless all addresses were exhausted.
  • As a DHCP client the FireBrick normally checks the address it was offered is not already in use (using ARP) and rejects it if another machine is using the address. This can be disabled with the Don’t check option, and is relevant if something is proxy ARPing an entire block, for example. (e.g. cable modem services in some parts of Colombia).
  • The BOOTP server and filername are sent in DHCP and BOOTP responses and allow network boot devices to obtain the information necessary to load.
  • The FireBrick supports the use of a /31 (255.255.255.254) subnet mask to create a point to point link as per RFC3021. In this case the FireBrick can be either of the two addresses, and will ARP for the other address. Not all equipment is compatible with this mode of operation and so you should always test correct operation in such cases.
  • The FireBrick also supports /32 (255.255.255.255) subnet mask. This means that the FireBrick will ARP for any other address, but that routing will be have to specifically directed to the subnet using routing rules.
  • Note that the DHCP gateway is used when any routing sends traffic toa subnet without specifying a gateway – this allows per subnet gateways. It is set when used as a DHCP client.
  • A more detailed description of routing is shown here.

DHCP restrict

The DHCP restrict mode allows the DHCP server to give different ranges of addresses to different machines on the network based on the name or MAC of those machines. The addresses could be on different subnets completely, or you could have multiple subnet entries with the same IP and netmask each with specific ranges to allocate on that subnet.

If a machine wanting an address quotes a name or MAC which starts with the restrict prefix or any subnet, then it can only have addresses from such subnets. If its name or MAC does not start with the restrict prefix of any subnet then it cannot use any subnet that has a restrict prefix set but can use any others that are unrestricted (restrict prefix is blank).

This is all within the restriction of subnets that are DHCP servers on the same interface (and same VLAN if using VLAN subnets). If you have VLAN subnets then that would normally a better way to manage allocations than using DHCP restrict.

The matching with the restrict prefix requires that the name quoted when requesting an address, of the full hex MAC address (no spaces or colons) starts with the prefix specified.

DHCP mirror

The DHCP mirror feature is specifically designed for cable modem situations where a single IP is available on the WAN using DHCP, but multiple machines may be required on the LAN using private addresses and NAT. In such cases it is often useful to have at least one machine on the LAN have the external IP address and not use NAT. This is simple enough except for the fact that the external address may change.

Typical use means that you set a WAN subnet as a DHCP client, and have a LAN subnet as private addresses DHCP server, but also have a LAN subnet set with DHCP mirror of the WAN subnet. This second LAN subnet is typically set to use DHCP restrict so that it only applies to one machine matching the subnet name (the machine that is to use the external address).

When the WAN gets an IP by DHCP, the mirroring LAN subnet is changed so that the FireBrick has the external gateway address, and it allocates only one DHCP address which is that received on the WAN. An address mapping entry can then be used to map traffic for the FireBrick on its WAN to the LAN hence passing through the external traffic (still subject to filtering).

When the WAN address changes, the mirroring LAN changes. The expiry on the mirroring LAN is set so as to be 10 seconds after the WAN and hence ensure a smooth change of IP on the LAN side as well.

VLAN subnets

VLAN subnets allows the FireBrick to operate with an external VLAN tagging network switch. Any traffic sent to a subnet with a VLAN ID will be tagged with that VLAN ID, and this can be used on the switch to direct the traffic to specific ports. This allows groups of actual ports to be assigned to different subnets.

This is particularly useful with DHCP as it allows different ports to get different address ranges. Routing can also be used to direct traffic to specific VLAN subnets.

Using VLANs on a network switch also means that separate groups of ports can be separated, hence forcing any traffic between them via the FireBrick and hence subject to filtering rules.

Note that filtering rules apply based on the actual interface, not the VLAN, but can specify IP ranges or groups to allow control of traffic between specific groups of ports.

If VLAN subnets is not available, all VLAN tags are dropped and ignored by the FireBrick, even in stealth mode.

FireBrick
No comments yet.

Tags: ,

by admin