Tunnels

Tunnels provide a means of accessing remote networks and creating a virtual private network (VPN) to other FireBricks.
Once a tunnel is created it becomes available in the routing rules as a destination, allowing traffic to be routed down a tunnel.

Routing

Creating a tunnel does not automatically say what traffic is to be sent down a tunnel – you will need to make a routing rule to specify this. Typically you will have a range of addresses which you know are at the far end of the tunnel, and will make a route sending those addresses down the tunnel.

Filtering

Creating a tunnel does not automatically allow the traffic through the FireBrick. You will need to consider what traffic you wish to allow from or to the tunnel. In many cases all traffic from Tunnel to LAN or from LAN to tunnel will be wanted, and so two filters will need to be added to allow such traffic.

The tunnel traffic is wrapped up in another packet to send over the internet to the other FireBrick. This traffic needs to be allowed. The FireBrick can is allowed to send traffic (unless a filter explicitly blocks it), but it will not automatically allow such traffic. To allow tunnelled packets through, create a filter allowing traffic to interface FireBrick on UDP port 1 (or use the FireBrick Tunnel Traffic port group).

Keep alives

Every second the FireBrick can send a small packet to the far end, which is a keep alive. This packet allows the far end to confirm the tunnel is all working. Both ends send these, and this is how the tunnel is shown as UP or DOWN. Normally keep alive packets are sent if they are being received, or if the far end has a fixed IP address. However there are other options. Master causes keep alives to always be sent. Slave causes them to only be sent if being received. Timeout causes them to be sent if there has been any traffic in the last minute – this is useful when operating on diulup/ISDN links allowing the link to drop if there is no activity.

Security

The authentication secret can be used to authenticate packets sent. This secret is used to digitally sign packets so the far end can be sure they are authentic and have not been changed in any way. You have to enter the same secret at each end.

If a secret has not been set, then the packets are not authenticated. However, the far end fixed IP is still checked, and this can be adequate security for most purposes.

There is an overhead to digitally signing and checking all of the packets sent, which can mean slower throughput. To reduce this effect the FireBrick will normally send unsigned data packets once the tunnel is established both ways. These are checked to be from same IP address as the previous (authenticated) keep alive packets recently received. There is an option Auth-All which forces all of the transmitted packets to be digitally signed. In this mode, the receiving FireBrick checks all packets so they cannot be spoofed by someone else and sent unsigned. This also applies automatically if the FireBrick at the other end is an older model (older software or a Plus or SoHo) and cannot accept unsigned packets.

Note that tunnel traffic is not encrypted.

Tunnel status

If the tunnel receives keep alive messages or any data it will shows as UP. If not then it shows as DOWN. In some cases you may see UP/DOWN where the FireBrick receives data from the far end, but the far end is not receiving data from this FireBrick. If a tunnel is not UP, then it is normally excluded from consideration as part of a tunnel set – the exception is when Timeout keep alive mode is used as you cannot be sure if the tunnel is UP or DOWN as it may simply have timed out. There are also tunnel set statistics (used with Bonding) which show the ordering of packets received, and how effective packet reordering is.

Technical Reference

• FireBrick tunnels work using a FireBrick Lightweight Tunnelling Protocol which works with other FireBricks and for which there is also an open source linux implementation.
• Tunnelled packets are sent from and to UDP port 1. Address mapping rules can be used to change this if necessary.
• FireBrick tunnels will work via NAT and reply to the port from which traffic was sent.
• It should be noted that if two ends of a tunnel are set correctly with specified IPs and send keep alives enabled, then there is no need to set an incoming filter to allow UDP port 1 as the traffic from the other end appears as replies to the outgoing traffic and so matches the session.
• The MTU defines the size of packet that can always reach the far end without being fragmented. On most networks this can be set to 1500. It cannot be set below 576. Any packet that would be too big once encapsulated is broken up first and sent in shorter tunnel packets. This is obviously less efficient.
• The Limit option will drop/reject any packets that are to big to send within the MTU when encapsulated. An ICMP can’t fragment error is returned
• The Fix option causes the MSS in any TCP SYN packets to be adjusted if too high so that it will fit the MTU specified when encapsulated. This makes the tunnel more efficient. You should set this at both ends as it only affects MSS settings on SYN packets sent in to the tunnel.
• The local end IP can be set. This is rarely necessary, but in some cases it can be useful as it is checked at the far end to match the far end IP.
• If all tunnels in a set are inactive then the traffic goes to the originally routed tunnel only (i.e. as if there was not tunnel set), if it is enabled by profiles.
• With bonded tunnels, sessions reported in the session table relate to the tunnel the traffic was routed to, the redirect to another tunnel is done at the last stage when the traffic is sent down the tunnel and does not affect session tracking.
• QOS and Reorder relate to packet reordering on bonded tunnel sets, see below
• The bonding bias can be used to adjust the relative load of each tunnel in a set, e.g. 1, 1/2. 1/3, 1/4, etc. This is intended for mixed speed bonded sets, and its usefulness is somewhat experimental.
• A tunnel is treated as down if no packets of any sort for 5 seconds, or no keep alives for 12 seconds.
• Tunnel bonding
• With the bonding feature it is possible to select a set of  tunnels which work together. When traffic is sent to any tunnel in a set, it is actually sent down one of the tunnels to share out the load. This means you can make use of multiple internet links connecting two FireBricks and send traffic down multiple links at once for a higher overall throughput.Note that you should set MTU, Fix, and other settings the same for all of the tunnels in a set to avoid any unexpected behaviour.If any of the tunnels are disabled (based on profile) or not active (expect keep-alives is set but none received) then it is omitted from the set and the traffic spread between the working tunnels in the set.

  When bonding channels to achieve high speeds you must also consider the impact of windows size and speed/latency. Your TCP settings may need tuning to make the best use of a fast link to the internet.

• Packet reordering
• It is a fundamental principle of Internet Protocol (IP) that there is no guarantee packets will all arrive, arrive in order nor be duplicated. The higher protocols must handle this. For example, TCP is able to retransmit dropped packets and ignore duplicate packets. Unfortunately, not all protocols and applications work well when packets are reordered. Two key examples are that (a) some TCP stacks are much less efficient in the face of packet reordering so giving lower than expected throughput, and (b) some voice over IP systems do not handle packet reordering well resulting in distorted speech on a call.Packet reordering in a FireBrick can happen as a result of the bonding features. These are typically used to send packets down multiple internet links. The difference in packet sizes alone can therefore result in packets arriving in a different order. Differences in the latency on each link can also have an impact.To address this the FireBrick has two features.
• The first (now deprecated) is the QOS option. This affects the sending of traffic down a bonded set. Any traffic that matches the programmed TOS value in the FireBrick will not be bonded but will stick to the tunnel to which it was routed, load balancing other traffic around it. This is normally used to address VoIP issues by making calls stick to one or other link. Typically a load sharing routing rule set is used to send traffic to one of the links in a bonded set so some calls go down one link and some down another, etc. If traffic is sent to a link that is unusable (down by profile or keep alive) then the bonding is enabled again for that traffic until the link is usable.
• The second option is Reorder. This affects the receiving of packets on a bonded set. Packets arriving out of order are held until the missing packets are received (within limits). This can be less efficient if there are dropped packets, and so it is recommended that speed lanes be used to minimise any risk of dropped traffic between bricks. The result is that most, if not all, of the received packets come out of the FireBrick in the correct order. When this is used effecively, the QOS option becomes redundant and so is deprecated. Note that this will not work if the far end is a FireBrick which does not have the Reorder option available (i.e. older software).
• Note that reordering is only available with both bonding and traffic shaping. Its use without shaping traffic to avoid inter-brick packet loss is not recommended as the far end will wait several packets before confirming a missed packet is in fact missed, hence hindering performance.
• FireBrick Lightweight Tunnelling Protocol
• The tunnelling protocol uses UDP port 1 packets, with one of two packet formats (single and multi-segment). In each format the first byte in the UDP payload is of the form SFPPVVV where S indicates the packet is signed, F indicates the last segment, PP indicates the part (0, 1 or 2) and VVVV is the version (2). The second byte is a tunnel reference – which tunnel at the far end to use, and starts from 1.For signed packets, a 16 byte MD5 signature is at the end of the packet. This is a signature of the whole UDP payload up to this signature, followed by the secret. The signature covers the UDP payload only so does not include IP or port numbers as they could change in transit via NAT, etc.For packets that will fit in the sending MTU, the packet is sent in one go. In this case the tunnel reference is followed by the data in the packet, and then 30 bytes (before any MD5 signature) of header data. To reassemble the packet, simply move 30 bytes from the end to the start of the packet. This is a light weight tunnelling system which does not involve moving much data in the packet (only 30 bytes). These packets have F=1 (final) and PP=0 (first part).

  For packets that will not fit, then the next two bytes after the tunnel reference are a cycling packet reference. Then there are up to 512 bytes of data. The packet may be in 2 parts (F=0/PP=0 and F=1/PP=1) or 3 parts (F=0/PP=0, F=0/PP=1, and F=1/PP=2) all with the same packet reference. All but the final packet are exactly 512 bytes. This is not as efficient because data has to be moved in the packet, and the 2 or 3 parts have to be reassembled. All segments in a packet are expected to arrive within 2 seconds.

  For keep alive packets, F=0/PP=3 and one byte follows the tunnel reference with flags 000TRSU1. U mean the tunnel is up (i.e. sending end is seeing incoming keep alives). S means the sending end expects to continuously send keep alives (i.e. master or auto when far end is fixed IP). T means the sending end will send unsigned payload packets. R means the sending end can accept unsigned payload packets.

  The IP header ID field should be contiguously increasing in the low byte on all packets sent to the same tunnel set so as to ensure the Reorder option works correctly.

  Debug level logging on the FireBrick will report if there are any unexpected tunnel packets received, etc.