FireBrick routing, mapping and filtering
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.