Tunnels can currently only be created between FireBrick®s. The tunnel carries an encryption code so that it cannot be tampered with or forged, but it not encrypted for secrecy. The tunnel uses UDP which should survive going through other routers and translation, but one end must be on a fixed IP.
The tunnel set up is as follows :-
| Security | Who can edit/view this tunnel |
| Name | Name the tunnel |
| IP | Set the IP address of the far end - blank for any allowed |
| Secret | A secret - blank for no secret |
| Reference | Set the tunnel number at the far end |
| Profile | When the tunnel applies |
| MTU |
You can safely leave this at it's default - it controls
the maximum packet size used |
| Don't segment |
This forces the packets sent to fit in the maximum
segment - use for special applications |
| Send Keep-Alives |
This makes the tunnel send a small message every
second to ensure the tunnel stays running. Useful when tunnelling through another router which is performing address translation |
| Expect Keep-Alives |
This causes a log event when the tunnel starts and
stops working - i.e. it expects the regular messages from the other end. If
they stop then the tunnel will forget any dynamic IP address that the other
end may have been using. |
At each end you must create a tunnel. The reference at each end must be the tunnel number at the other, and the secret must be the same at both ends.
One end, and ideally both ends, must have the IP address of the other. It is possible for one end to have no IP address - in this case it cannot start communications on the tunnel. Once it has received some information on the tunnel and confirmed it is valid then it will note the IP address it came from and use that for all replies. This allows for one end being on a dynamic address.
The routing rules then have a To address which is of the form Tunnel(name) allowing you to specify what traffic goes down a tunnel. Ensure you create routing rules for addresses at the far end of the tunnel (at each end).
Remember that stealth packets do not go through the routing rules, and also that proxy ARP will only be useful if the addresses are on the network at the source end. i.e. the FireBrick® should be configured as a gateway for tunnel routes to work or should be routing a part of the addresses on a LAN using proxy ARP.
Notes:
Tunnels are normally signed but not hidden. This means your traffic may
be visible to others if someone can snoop the network between the tunnels,
but they cannot forge communications or change the contents. If you leave
the secret blank at both ends then the tunnel is unsigned. This means it
is simply a way of mapping IP addresses and privides no security other than
checking the IP address the packets came from. In some situations this is
quite adequate security.