ICMP Errors

The FireBrick can generate ICMP packets for a number of reasons.

Firewall

Packets that reach a "Reject" filter cause and ICMP error to be generated. This indicates a host unreachable error 13 (admin prohibited filter). Such packets are delayed by a random amount of time to reduce load as a result of attacks.

Pings to a "bounce" filter result in ping responses, but these are also delayed.

Closed ports

Packets for the FireBrick for which there is no internal handling (or port map) result in a port unreachable ICMP error. The exception to this is TCP traffic, which indicates a RST. Such ICMP packets are delayed by a random amount of time to reduce load as a result of port scans.

Ping response

The FireBrick will generate ping responses to a ping to one of its addresses. These packets are not delayed.

TTL

The FireBrick will count down TTL if acting on a routed packet, and can generate an ICMP TTL Expire error. These packets are not delayed.

Fragment failure

If a fragment cannot be made for a packet which needs to go via a smaller MTU (e.g. down a tunnel with DF bit set), then a Cannot Frag error is returned. This is not delayed.

ARP failure

If the FireBrick is unable to identify the MAC address for a routed packet, it will return a "host unreachable" error. This is not delayed.

Source IP address

ICMP errors are normally sent from the router that generated them, and as such the FireBrick is expected to identify itself. Many types of error result only from routed connections, and so the FireBrick will have a suitable address.

The FireBrick will use its normal rules to work out a suitable source address, and if that fails will not send the error. This means that "reject" is often ineffective in a complete stealth mode as the FireBrick has no IP to quote in the reject message.

  1. If the FireBrick is sending the packet to an address on a subnet, then that subnet is used as the IP
  2. If not, and the FireBrick has a stealth IP on the interface in question, that is used
  3. If not, the packet is not sent

Contents

The packet contents includes, as per ICMP protocol, details of the original packet including the IP header and up to 8 bytes of payload. If the packet was processed via NAT or port mapping, then this is reversed as normal, including changing the payload IPs, ports and checksums, so as to ensure the recipient can associate the packet with a session correctly.