This is a general description of the way in which the FireBrick
establishes and routes a new session.
What is a session?
The FireBrick tracks sessions. These are a set of packets in each
direction that belong together. The initial packet will start the
session and then there are replies and further packets in the same
session.
In the case of TCP, there is a specific sequence of packets to
establish, maintain and drop a session. The FireBrick tracks this from
the initial SYN packets through to the final FIN packets.
In the case of UDP, the FireBrick tracks corresponding replies back to
the same port and IP from the same port and IP as the initial packet,
and uses timeouts to end the session.
In the case of ICMP, replies are tracked, like echo replie to echo
requests, and also ICMP errors are tracked as part of the initial
session to which they relate.
In the case of other protocols, the session is tracked based soley on
the source and target IP addresses, which places some restrictions on
using NAT with protocols like GRE.
The FireBrick will route the initial packet in a session based on
routing rules, and will apply filters and mapping rules. The replies
undo any mapping or NAT and are routed back. The first reply packet is
routed within some constraints so that it will head for the same
interface as the original packet, for example.
What order are things done?
The order things are done is as follows - this is also the same order
in which the routing, filtering and mapping icons are shown above.
Routing rules are applied. This defines the interface to which
the packet is to be sent - which is necessary to for filtering and
mapping
Filtering is done. This is done before mapping as mapping will
potentially lose some information (i.e. many ports could be mapped to
one, etc)
Mapping is done, potentially changing the IPs and ports
If mapping was done, then this may mean routing is re-applied
Routing rules
Routing is the process or working out which interface, sub interface
(e.g. subnet or tunnel) and gateway (for ethernet interfaces). For
tunnels the traffic goes to the specified tunnel, and there is no need
for a gateway. For routes to ethernet interfaces (e.g. LAN/WAN) there
needs to be a gateway address for any traffic to an address
off subnet.
Routing is done by looking through the routing rules in order and
trying to match the traffic to the routing rule. This can mean checking
ports and protocols even. At the point that subnets are routed, the
subnets are checked in order for an address on one of the subnets. Then
the routing rules resume. Ultimately if there is no match, the default
routing rule is applied.
In some cases there is already some routing information. This applies
when routing the initial reply of a session, but also when traffic like
pings, tunnels, etc, have some inforation specified such as an
interface. Where an interface is know, the routing and subnet rules are
only considered if they route to that interface.
Routing can mean sending traffic to a specific interface. It can
further mean specifying a specific subnet. It can also mean specifying
a specific gateway for an ethernet interface.
The normal recommendation is to route traffic that is for the ethernet
to a specified subnet, and not specify a gateway. If the routing comes
outs as being a subnet and no gateway, then the routing could be to an
IP on that subnet - in which case ARP is used. If not, then the gateway
sepcified in the subnet config (under DHCP server) is used. Failing an
ARP is done for the off-subnet target IP address. ARPs are done
from the FireBricks IP/MAC on that
subnet.
Routing to a subnet and not specifying a gateway but allowing the
subnet specific gateway to be used helps avoid duplication. This is
very useful when the external subnets are allocated by DHCP and so the
gateway can be changed. This is particularly useful when multiple
subnets are used for multiple external interfaces and tunnels are set
to go to specific subnets with DHCP gateways.
If routing is to an ethernet interface with no gateway or subnet then
the FireBrick will ARP for the off-subnet
address. It may use its stealth address as the source for the ARP and
the base MAC address. This is not ideal, and a gateway or subnet should
be specified.
If routing to an ethernet interface with a gateway but no subnet
specified, then the subnets are checked for the first subnet containing
the gateway address, and this is used.
NAT
NAT simply means that the source IP is changed to that of the
FireBrick. The FireBricks IP will depend on wheich subnet it is sending
traffic to. If to a tunnel, then the tunnel can set the NAT IP to be
used, else the NAT is applied when leaving the far end brick via an
ethernet interface. This means the source IP is set at the last stage,
after mapping, and so filtering on the source IP is not possible.
NAT is applied if the routing rule is to the default gateway or matched
a subnet, and the source subnet has NAT selected. Failing that NAT is
applied if the explicit routing rule used has NAT set. This means that
any explicit routing rule that is used without NAT ticked will not use
NAT even if the source is a subnet that has NAT ticked. Sometimes this
means different explicit routing rules for traffic from some addresses
than others even if the destication is the same, as one set may need
NAT and one set may not.
Filtering rules
Filering rules simply match the assigned source and target interface
(from the routing rules), IPs, ports, etc, and decide if the session is
allowed. If allowed, all replies are allowed and further traffic within
the session.
Mapping rules
Mapping rules are then applied, and again work on similar critera to
filtering. They then change the target interface, source and/or target
IPs and/or ports. If changing the source IP then a new source port is
assigned. Setting the new source IP of 255.255.255.255 has special
meaning and makes the FireBrick apply NAT.
Key points
We recommend that all subnets are set up with IP and mask, but
also with a gateway applicable for that subnet. This allows routing to
the subnet without having to specify the gateway address again in the
routing rules.
Any explicit rules used for routing must consider NAT as it will
not be automatically applied unlike routes to subnets or the default
gateways
The order routing, filtering and mapping are applied are the same
as the icons on the top of the config, routing -> filtering ->
mapping.
