Tunnels
53
i.e. the first packet to be sent is routed down the first tunnel in the set, each subsequent packet is routed down
the subsequent tunnel in the set, and the (N+1)'th packet (where N is the number of tunnels in the set) is again
routed down the first tunnel. This provides the ability to obtain aggregated bandwidths when each tunnel is
carried over a different physical link, for example, such as using multiple ADSL or VDSL (FTTC) connections.
Note
Using tunnel bonding to aggregate access-network connections such as ADSL or VDSL to provide a
single 'fat pipe' to the Internet requires there to be another FB105 tunnel end-point device to terminate
the tunnels. Ideally this 'head-end' device is owned and operated by your ISP, but it is also possible to
use a head-end device hosted by a third party, or in a datacentre in which you already have equipment.
ISPs that can offer tunnel-bonding for Internet access include Andrews & Arnold [http://aa.net.uk]
and Watchfront [http://www.watchfront.co.uk].
To form a bonded tunnel set, simply specify the
set
attribute of each tunnel in the set to be a value unique
to that set. Although not required, you would typically use a
set
value of 1 for the first set you have defined.
You can defined multiple bonded sets by using different values of the
set
attribute in each set.
11.1.6. Tunnels and NAT
If you are using NAT in your network, it may have implications for how to successfully use FB105 tunnelling.
The issues depend on where (on what device) in your network NAT is being performed.
11.1.6.1. FB6000 doing NAT
If you have a bonded tunnel set implementing a single logical WAN connection, then the FB6000 will typically
have multiple WAN-side IP addresses, one per physical WAN connection. If you are using the FB6000 to NAT
traffic to the WAN, the real source IP address of the traffic will be translated by the NAT process to one of
the IP addresses used by the FB6000.
When this NAT'd traffic is carried via a tunnel, it will be the source address of the tunnel payload packet that
is modified.
Whatever address is used, reply traffic will come back to that address. In order to ensure this reply traffic is
distributed across the tunnel set by the far-end tunnelling device, the address used needs to be an address that
is routed down the tunnel set, rather than one associated with any particular WAN connection.
In order to handle this scenario, the
internal-ip
attribute can be used to define which IP address is used
as the source IP address of the tunnel payload packets.
**TBC do you therefore need at least a /32 public IP that is used by the brick, and is not associated with any
specific WAN connection? So far I have seen NAT used only where there is also a block of public IPs routed
down the tunnel set.**
11.1.6.2. Another device doing NAT
If you are using another device that is performing NAT (for example, a NAT'ing ADSL router) and that device
is on the route that tunnel wrapper packets will take , you may have to set up what is generally called port
forwarding on your NAT'ing router.
If the FB6000 is behind a NAT router, it will not have a public IP address of its own which you can reference
as the far-end IP address on the other end-point device. Instead, you will need to specify the WAN address of
the NAT router for this far-end address. Whether you need to setup a port forwarding rule on your NAT router
depends on whether the FB6000 behind the router has a far-end IP address specified in tunnel definition(s),
as follows :-
• If it does, then it will be sending tunnel wrapper packets via the NAT router such that a session will have
been created in the NAT router by the session tracking functionality that is used to implement NAT (this
