Stealth


The FireBrick can operate in stealth mode - which basically means it is invisible. Obviously it cannot be completely invisible, otherwise it would be no good as a firewall. The key part of stealth mode is that devices on one side of the FireBrick can send packets to devices on the other side of the FireBrick without knowing the FireBrick is there - i.e. using MAC addresses as normal. To do this the FireBrick propagates ARP requests and replies, allowing devices on one side to locate devices on the other side as normal. All IP packets passing through the Firebrick are subject to its normal session tracking, filtering, and port mapping rules.

As such the FireBrick is transparent subject to the following caveats :-

  1. Runt, overlong, bad CRC, and otherwise deformed frames are dropped
  2. 802.3 style ethernet packets are changed to standard ethernet packets (removal of 802.3 headers)
  3. Packets which are not IP or ARP (request and reply) are discarded. In particular, this means IPX and NETBEUI are not passed through the FireBrick
  4. As the FireBrick has two half duplex 10baseT interfaces, this can result in additional collisions and packet loss when running at very high throughputs (e.g. 900KB/s+) which means the FireBrick is not quite the same as having a hub.
  5. The FireBrick maintains a MAC cache, recording which side of the FireBrick each MAC has been seen. Packets which are known to be destined for MAC addresses on the same side that they were received are dropped. This is much the same has having a switching hub in front of the FireBrick.
  6. ARP requests and replies are specially processed
  7. All IP packets are subject to session tracking, filtering, and port mapping rules
  8. The FireBrick introduces around 1ms additional delay, depending on packet size, with an extra 2ms to 3ms on the initial packets in a session.
  9. The FireBrick intercepts traffic to a specific stealth IP address per interface, allowing the http://my.FireBrick.co.uk/ set up pages to operate.

ARP request propagation

In order for the FireBrick to operate in a stealth mode, it is necessary for ARP requests to be passed from one interface to another. This then allows devices on each interface to address devices on the other interface by MAC address as if the FireBrick was not there and they were on the same LAN.

After factory reset the FireBrick is in a full stealth mode. This means ARP requests are passed to the other side. However the FireBrick can operate in a partial stealth mode where it has some subnets defined. The subnet defines the IP and netmask to be used on a specific interface, and the FireBrick can have many subnets defined. Subnets can be marked as stealth. Note that subnets are subject to profiles, so may only be operational at certain times.

The exact rule for passing ARP requests is described in ARP handling.

ARP reply propagation

As devices will normally cache ARP replies regardless of whether they requested them, incorrect propagation of ARP replies could cause ARP poisoning (i.e. incorrect ARP data in ARP caches). As described in ARP handling, ARP requests that are passed through are session tracked, and only valid replies passed back.

Broadcast packet propagation

A broadcast packet is one sent to the broadcast MAC address.

If the target IP is the network or broadcast IP of a subnet on the interface from which the packet was received, and the subnet is not marked stealth, then the FireBrick considers this a packet for itself and does not propagate it.

If the target IP is 255.255.255.255 and either we have no IP on a DHCP client subnet, or there is no source IP, or we have a subnet where the source IP is within the subnet, then the FireBrick considers the packet for itself and does not propagate it.

Otherwise broadcast packets are propagated subject to global stealth controls.

TTL/Routing

When packets are propagated in stealth mode, they are not treated as routed packets and as such the routing rules in the FireBrick do not apply. Routing only applies where the FireBrick must decide where to send a packet, but stealth packets already have an identified target MAC address and so do not require routing.

Packets to the FireBrick itself (by MAC, or broadcast MAC as above) are treated as routed, although port mapping can be used to force a stealth packet to be routed. Only routed packets will cause the TTL to be counted down and a time exceeded ICMP to be generated if this reaches zero.

Stealth intercept address

The FireBrick has a stealth address which is pre-programmed for the LAN interface. This is by default 217.169.0.1 which is a public IP address assigned to the FireBrick and so should never clash with any other network.

This address is used to allow communication with a stealth FireBrick. The FireBrick will answer ARP requests on the LAN for this address, and accept traffic to this address (even stealth traffic) from the LAN. Both explicit and implicit filtering rules allow this traffic for web page configuration of the FireBrick. This address can be changed, but this is not normally necessary.

The address has a public DNS entry of my.firebrick.co.uk, which allows configuration using a web browser to this address. On the internet this address has a page explaining that you have not reached your FireBrick, in case it is used when a FireBrick is not in place. Formerly the FireBrick had 62.190.255.253, and this is now old.firebrick.co.uk, allowing access to older FireBricks which have not been reconfigured with the new address.

When answering TCP traffic on this address, the FireBrick will use the external router MAC address in its replies, hence remaining in complete stealth mode.

There is also an option for a WAN stealth address. This is an address which is only used where the FireBrick must generate traffic on the WAN and where no subnet exists. This is typical of a full stealth configuration, and allows the FireBrick to initial time setting requests, and even send emails. The address much be the address of a machine on the LAN so that traffic for the address will reach the FireBrick from the WAN side. Also the address must be of a machine that is power on so that the router on the WAN can ARP the address as the FireBrick does not presume to reply for the machine.

Apart from intercepting specific replies to its active outgoing requests, the FireBrick does not otherwise interfere with traffic to the address it is borrowing.

Stealth controls

Global controls in the log/filter options allow stealth to be disabled :-
  1. The default passing through of ARP requests can be disabled. i.e. only ARPs within explicit stealth subnets are passed through.
  2. The passing through of subnet broadcast packets can be disabled.
  3. The passing through of local broadcast (255.255.255.255) packets can be disabled.
  4. The passing of any stealth packets can be completely disabled (stopping all of the above as well).
In all cases, such disabled packets are dropped silently before any filtering or logging.