ETUN or Ether IP tunnels are described in RFC3378. It uses IP protocol 97 and enables ethernet-level communication between physical ports on remote FireBricks. You can think of an ETUN as a cable connecting an ethernet port on one FireBrick to the Ethernet port on another FireBrick. Apart from the latency and MTU restrictions, it’s as if you have a cable between two remote networks.
To configure an ETUN between two FireBricks, you will need a dedicated physical port and public IPs on each FireBrick and then tell the FireBrick of the opposite end IP address.
In the example below, we’ll assume we already have our FireBricks on line – perhaps they have PPP on a DSL line or some sort of leased line service – it doesn’t really matter as long as each side has a public IP address. We’ll be using the SFP port on both FireBricks, but you can use any of the ports.
Note: ETUN probably won’t traverse NAT very well, hence needing public IP addresses. You can set the ETUN up using IPv6 addresses instead. The example below is using IPv4 though. (MTU improvements for establishing the tunnel over IPv6 are planned for the 1.55 software release.)
Configuration
Left side
Local public IP = 192.0.0.1
port config:
<port name=”etunSFP” ports=”5″/>
Tunnel config:
<etun name=”etun2right” eth-port=”etunSFP” ip=”192.0.1.1″/>
Right Side
Local public IP = 192.0.1.1
port config:
<port name=”etunSFP” ports=”5″/>
Tunnel config:
<etun name=”etun2left” eth-port=”etunSFP” ip=”192.0.0.1″/>
In this example, a machine on the left side will be able to obtain an IP via DHCP from the DHCP server on the Right side and will see be as if it’s on the Right side’s LAN.
The two ETUN’ed ports will behave as if they were two ports on a single link layer 2 hub or switch, apart from the extra latency introduced by the carrier network traversal.
It is important to note that *all* ethernet packets are transported.
This includes ethernet broadcast packets, ARP packets and also any non-IP traffic (eg IPX, old NetBIOS/NetBEUI etc) so care should be taken to ensure that such traffic does not overload the carrier network. In addition, the extra latency may cause problems with devices expecting LAN-speed responses – for example, switches running LACP.