Routing


Routing is the process whereby the FireBrick works out where to send a packet. This involves working out which interface to send the packet to (WAN, LAN, Tunnel, Itself) and for ethernet interfaces, which MAC address to send the packet to.

For ethernet, the MAC address is based on an IP address - either of the destination of the packet (if on the same subnet as the FireBrick) or of the router/gateway which will pass on the packet to its destination. ARP is used to find the MAC from the gateway IP address.

Routing only applies where the FireBrick needs to find where a packet must go. A stealth packet already has a destination interface (the other side from which it came) and a destination MAC (as received). As such, stealth packets are not routed (see port mapping for details of how to force routing of stealth packets).

Pre routing

Before routing is done, all packets (received or to be sent) arrive in the routing queue. These may possibly have a pre-decided target interface (e.g. TCP replies from the FireBrick itself go back the the source interface, etc.

Packets from tunnels or serial links are set for target unknown and the routing decides. Packets from the ethernet interfaces has the following choices :-

  1. Checking by target MAC, packets that are for the same interface on which they arrive are dropped
  2. Checking by target MAC, packets for the other interface are set for that interface, marked as stealth and marked as cross interface.
  3. Checking by target MAC, packets for unknown targets are set to the other interface and marked as stealth
  4. Packets for a broadcast MAC are checked if they are to be propagated or handled by the FireBrick as per the stealth rules.
  5. Packets for the FireBrick's MAC on the interface they arrive are checked if they are for the for the FireBricks IP on that interface, and if so directed to the FireBrick itself, otherwise they are set to unknown allowing unrestricted routing

Routing

To decide where a packet has to go, the FireBrick considers the following, in order. Packets may have a target interface pre-decided (as above), in which case only rules setting that interface are considered, and these rules may set the gateway (for ethernet interfaces) or specific sub-interface (for tunnels/serial).
  1. Packets for the FireBrick itself do not have any further routing as they can only end up for the FireBrick itself.
  2. The routing table, in order. Each route is checked for a match, considering the source and destination IP addresses and the source interface. The first match is used. If the target interface is already decided, then only routes to that interface are considered. The routing entry found will define the destination interface and may also define a destination gateway address. The routing entry can also set the NAT option. The target can be any in which case the target interface is not set and further routes are considered (useful to set NAT addresses, or force proxy ARP without affecting routing decisions).
  3. At a configurable point during routing, routes to the subnets are checked. This is at the end by default.
  4. If no route was found (other than target any) or the route was to a subnet, then the subnets are checked to see if the packet is from a subnet for which NAT is defined. The first subnet matched is checked for the NAT option. (See address translation for how this is used). Either routes or subnets can set the NAT option.
  5. If no gateway is yet defined then routing to a subnet is considered again. If a destination interface has been defined, then the search is restricted to subnets on that interface. The first subnet encompassing the destination IP is considered - setting the gateway as the target IP directly.
  6. If there is still no gateway, then the default route is considered. If the destination interface has already been decided, then this is only considered if it is on the same interface. The default gateway and interface are set.
  7. If there is still no gateway, and the packet is destined for an ethernet interface, then the target IP is assumed to be the gateway.
  8. Having established a gateway, the subnets are checked to identify which subnet the packet is being sent on based on the gateway address. A gateway would normally have to be on a valid subnet for the FireBrick to be able to send ARPs for the gateway. This check also confirms if the destination is the network or broadcast address of a subnet, in which case it is sent to the broadcast address. It is also checked if the destination is the FireBrick's own address on the subnet, in which case it is destined for the FireBrick itself.
  9. If no valid target interface can be established, then the packet is dropped
This means that the routing tables are the highest priority. If a routing rule exists for a packet, then this decides the target interface and gateway and also determines if NAT applies. Only if there is no route, are routing via subnets considered, and only if there are no matching subnets is the default gateway considered.

Some types of routed packets may have the interface and possibly the gateway predefined (profile pings for example). In this case only rules with the same target interface are considered in the routing. Similarly, routing rules can set a target interface without a gateway, in which case subnets and possibly the default route is considered if it has a matching target interface.

For non ethernet interfaces (e.g. tunnels), the sub-interface (which tunnel) is specified in the routing rules. In such cases no gateway is needed as gateways are an ethernet feature.

Stealth IP handling

The FireBrick has two stealth IP addresses, one for each interface. By default there is only one defined, for the LAN, which is the address of my.FireBrick.co.uk. This is used to allow access from the LAN to the FireBrick web config pages. If a packet is received on the LAN for this address, then the FireBrick will answer any ARP for this and will accept traffic to this address as to the FireBrick.

Traffic to the WAN stealth is not handled in the same way - it is not accepted as traffic to the FireBrick itself and does not answer ARP requests. However, this is used as the reply address for outgoing traffic from the FireBrick for functions such as time setting - so a machine on the LAN side should reply to ARPs, and the FireBrick will then intercept these replies as part of the session tracking.

Interaction with session tracking

A packet may be stealth or routed. Only non stealth packets are subject to routing. At the start of a session, the first packet is considered, and routed if not stealth. It is then checked against the port mapping. If port mapping applies then the packet is made routed regardless.

If this first packet ends up as a routed packet then the session is marked as routed. All packets through the session, forward and reverse, are then changed to non stealth.

The session holds the routing information (target interface, and gateway for ethernet). The first reply packet that is not stealth causes routing to be done on the reply - constrained to the known target interface (where the original packet in the session came from) and the gateway recorded for future non stealth packets.

Routed sessions are shown on the session display page with an R next to the protocol.

Interaction with port mapping

Port mapping applies on the initial forward packet after routing, but will cause routing to b re-applied after the port map (possibly restricted by the target interface of the port map). This is then the routing applied to all forward packets in the same session.

In the reverse direction the portmapping is reversed before the routing of the reverse packet is decided. Again, the routing is only done on the first packet in that direction and that routing used for all further reverse packets in the same session.

MTU

Ethernet interfaces operate with the full 1500 byte MTU, but some interfaces are smaller (such as tunnels which are 1455 to allow for tunnel headers). Serial interfaces may also negotiate a smaller MTU. As the packet is sent to the target interface, it is checked against the MTU.

If the packet is too large and has DF set, then it is dropped and an ICMP fragmentation error returned. Otherwise it is fragmented, dividing in to reasonably equal size blocks to minimise re-fragmentation later. This does involve additional copying of data which is not normally necessary and so does add some small additional latency. Generally it is best to try and avoid fragments.

If the packet is already a fragment then it is fragmented further regardless of the DF bit.

Weighted routing

Each route can be assigned a percentage, default 100%. This is used to determine the chance of a packet being routed via a specific route. This might be used to route different traffic via different gateways. The decision is made when the route is determined - i.e. when the session is established. All traffic on a session then follows that route (as it must, because a different route probable uses different IP addresses and NAT).

The way it works is that each routing decision, a number is picked (pseudo random) from 0 to 99. As each route is considered, if it is valid in all other respects then the percentage is checked. If the percentage is more than the number picked then the route is taken as normal. If the percentage is less than or equal to the number then the number is decreased by that percentage.

This means you can make two routes each marked 50%, and matching traffic will always go down one or the other. Similarly you could have three routes marked 40% 30% 30%. You can obviously leave the last route at 100% if you wish.

Multiple gateway load sharing

The FireBrick Plus allows for multi-gateway load sharing. To use this you will need multiple external gateways such as multiple ADSL lines. If these are on different subnets then you should set each as a subnet on the FireBrick. Pick a gateway address on the subnet for the external link on which you want the replies to arrive (e.g. if you had a 2Mb and 500K ADSL you would want to use an address on the subnet for the 2Mb line). This should be an unused address, and can be the subnet network address as it is simply used to tell teh firebrick to use the multi-gateway list. Then complete up to 4 gateways.

When any traffic is directed to the gateway that is the default gateway, it will have its gateway changes at the last moment, on a per packet basis, to one of the 4 gateways you have listed in a simple cycle. This allows you to bond multiple uplinks on ADSL lines for example.