6.3. Defining an interface

To create or edit interfaces, select the Interface category in the top-level icons - under the section headed "Ethernet interface (port-group/vlan) and subnets", you will see the list of existing interface top-level objects (if any), and an "Add" link.

The primary attributes that define an interface are the name of the physical port group it uses, an optional VLAN ID, and an optional name. If the VLAN ID is not specified, it defaults to "0" which means only untagged packets will be received by the interface.

To create a new interface, click on the Add link to take you to a new interface defintion. Select one of the defined port groups. If the interface is to exist in a VLAN, tick the vlan checkbox and enter the VLAN ID in the text field.

Editing an existing interface works similarly - click the Edit link next to the interface you want to modify.

An interface object can have the following child objects :-

6.3.1. Defining subnets

Each interface can have one or more subnets definitions associated with it. The ability to specify multiple subnets on an interface can be used where it is necessary to communicate with devices on two different subnets and it is acceptable that the subnets exist in the same broadcast domain. For example, it may not be possible to reassign machine addresses to form a single subnet, but the machines do not require firewalling from each other.

Note

As discussed in Section 6.1, an interface is associated with a broadcast domain ; therefore multiple subnets existing in a single broadcast domain are not 'isolated' (at layer 2) from each other. Effective firewalling (at layer 3) cannot be established between such subnets ; to achieve that, subnets need to exist in different broadcast domains, and thus be on different interfaces. An example of this is seen in the factory default configuration, which has two interfaces, "WAN" and "LAN", allowing firewalling of the LAN from the Internet.

You may also have both IPv4 and IPv6 subnets on an interface where you are also using IPv6 networking.

The primary attributes that define a subnet are the IP address range of the subnet, the IP address of the FB2900 itself on that subnet, and an optional name.

The IP address and address-range are expressed together using CIDR notation - if you are not familiar with this notation, please refer to Appendix B for an overview.

To create or edit subnets, select the Interface category in the top-level icons, then click Edit next to the appropriate interface - under the section headed "IP subnet on the interface", you will see the list of existing subnet child objects (if any), and an "Add" link.

Note

In a factory reset configuration, there are two temporary subnets defined on the "LAN" interface : 2001:DB8::1/64 and 10.0.0.1/24. These subnet definitions provide a default IP address that the FB2900 can initially be accessed on, regardless of whether the FB2900 has been able to obtain an address from an existing DHCP server on the network. Once you have added new subnets to suit your requirements, and tested that they work as expected, these temporary definitions should be removed.

To create a new subnet, click on the Add link to take you to a new subnet object defintion. Tick the ip checkbox, and enter the appropriate CIDR notation.

Editing an existing subnet works similarly - click the Edit link next to the subnet you want to modify.

The FB2900 can perform conventional Network Address Translation (NAT) for network connections / flows originating from all machines on a subnet (for example, one using RFC1918 private IP address space) by setting the nat attribute on the subnet object.

Tip

Behind the scenes, activation of NAT is on a 'per-session' basis, and the nat attribute on a subnet is really a shortcut for a session-rule using the set-nat attribute. If you wish to learn more about sessions and session-tracking, please refer to Chapter 7. If you have any need for firewalling, you'll need to refer to that chapter in due course anyway.

6.3.1.1. Source filtering

The interface has an option to source-filter traffic received from the interface. This means checking the source IP of all traffic that arrives.

Setting source filtering to true will only allow IPs that would be routed back down that interface. That is the most restrictive setting and only really makes sense for a LAN such as a customer connection, rather than a connection to another network, as it would impact any triangular routing. Using self is usually safer.

Setting source filtering to self will allow IPs where replies are routed somewhere off the FireBrick, but block any attempt to spoof a source address that is one of the FireBricks own IPs.

Setting source filtering to nowhere will block IPs where a reply would not router anywhere (i.e. blackhole, or nowhere/deadend). It allows packets where replies would be back to the FireBrick itself which is an unusual requirement.

Setting source filtering to blackhole is the least restrictive, blocking IPs where replies would go to an explicit blackholed route. Blackhole routes can be configured manually or via BGP using a specific community tag to define routes which are specificall invalid (without even an ICMP error).

Tip

The routing look up to check the source IP is normally done in the routing table of the interface. However, it is possible to set a source-filter-table which allows the check to be done in a different routing table. This usually only makes sense when used with the blackhole option. It allows a separate routing table to be used to define source filtering explicitly if needed.

Note

Link local IPv6 addresses starting FE80 are always allowed, as is the 0.0.0.0 null IP for DHCP usage. IPv6 addresses within 2002::/16 are treated as the embedded IPv4 address for filtering checks.

Obviously, having a firewall setting allows much more control over source address checking. These options are independant of firewall rules and mainly applicable to devices where firewalling is not available.

6.3.1.2. Using DHCP to configure a subnet

You can create a subnet that is configured via DHCP by clearing the ip checkbox - the absence of an IP address/prefix specification causes the FB2900 to attempt to obtain an address from a DHCP server (which must be in the same broadcast domain). It may help to use the Comment field to note that the subnet is configured via DHCP.

In its simplest form, a DHCP configured subnet is created by the following XML :- <subnet />

Tip

It is possible to specify multiple DHCP client subnets like this, and the FB2900 will reserve a separate MAC address for each. This allows the FB2900 to aquire multiple independant IP addresses by DHCP on the same interface if required.

6.3.1.3. Using SLAAC (IPv6 router announcements) to configure a subnet

For IPv6 you do not create a separate subnet, instead the interface level has an ra-client setting, which defaults to true. This allows an IPv6 address to be set up on the Interface if a suitable router accouncement is seen. The router announcement can also set up a gateway and DNS servers automatically.

Note that the gateway localpref is not something that can be configured, and defaults to 100X, 200X, 300X, or 400X depending on the priority setting in the router announcement. The X is based on the scope of the IPv6 address so a global scope has higher localpref.

If creating an IPv6 subnet and announcement on an interface you may want to disable ra-client in the interface settings.

Note

DHCPv6 client is not supported on interfaces yet. Gateway, address and DNS are expected to be set using SLAAC.

6.3.1.4. IPv6 prefix delegated subnets

The PPPoE configuration allows one or more interfaces to have prefix delegation, i.e. an IPv6 subnet configuraed automatically based on settings provided by youyr Internet Service Provider. This may be only one /64 network on one interface, but the configuration for PPPoE allows you to define which interface(s) and even select that none apply.

Once prefix delegation is set up, the assigend subnet is used to provide IPv6 addresses and gateway to devices on the interface using SLAAC.

6.3.2. Setting up DHCP server parameters

The FB2900 can act as a DHCP server to dynamically allocate IP addresses to clients. Optionally, the allocation can be accompanied by information such as a list of DNS resolvers that the client should use.

Since the DHCP behaviour needs to be defined for each interface (specifically, each broadcast domain), the behaviour is controlled by one or more dhcp objects, which are children of an interface object.

Address allocations are made from a pool of addresses - the pool is either explicitly defined using the ip attribute, or if ip is not specified, it consists of all addresses on the interface, i.e. from all subnets but excluding network or broadcast addresses, or any addresses that the FB2900 has seen ARP responses for (eg addresses already in use, perhaps through a device configured with a fixed static address).

The XML below shows an example of an explicitly-specified DHCP pool :

  <interface ...>
  ...
    <dhcp name="LAN"
          ip="172.30.16.50-80"
          log="default"/>
  ...
  </interface>

Tip

When specifying an explicit range of IP addresses, if you start at the network then the FB2900 will allocate that address. Not all devices cope with this so it is recommended that an explicit range is used, e.g. 192.168.1.100-199. You do not, however, have to be careful of either the FireBrick's own addresses or subnet broadcast addresses as they are automatically excluded. When using the default (0.0.0.0/0) range network addresses are also omitted, as are any other addresses not within a subnet on the same interface.

Every allocation made by the DHCP server built-in to the FB2900 is stored in non-volatile memory, and will survive power-cycling and/or rebooting. The allocations can be seen using the "DHCP" item in the "Status" menu, or using the show dhcp CLI command.

If a client does not request renewal of the lease before it expires, the allocation entry will show "expired". Expired entries remain stored, and are used to lease the same IP address again if the same client (as identified by its MAC address) requests an IP address. However, if a new MAC address requests an allocation, and there are no available IPs (excluding expired allocations) in the allocation pool, then the oldest expired allocation IP address is reused for the new client.

6.3.2.1. Fixed/Static DHCP allocations

'Fixed' (or 'static') allocations can be achieved by creating a separate dhcp object for each such allocation, and specifying the client MAC address via the mac attribute, or the client name using the client-name attribute.

The XML below shows an example of a fixed allocation. Note the MAC address is written without any colons, and is therefore a string of twelve hexadecimal digits (48 bits). This allocation also supplies DNS resolver information to the client.

  <interface ...>
  ...
    <dhcp name="laptop"
          ip="81.187.96.81"
          mac="0090F59E4F12"
          dns="81.187.42.42 81.187.96.96"
          log="default"/>
  ...
  </interface>

Tip

If you are setting up a static allocation, but your client has already obtained an address (from your FB2900) from a pool, you will need to clear the existing allocation and then force the client to issue a new DHCP request (e.g. unplug the ethernet cable, do a software 'repair connection' procedure or similar). See the show dhcp and clear dhcp CLI commands in Appendix J for details on how to clear the allocation. Chapter 20 covers the CLI in general.

You can also lock an existing dynamic allocation to prevent it being re-used for a different MAC address even if it has expired.

6.3.2.2. Restricted allocations

You can restrict a pool to apply only to devices with specific MAC addresses, client names or vendor class names using the mac, client-name and class attributes on the dhcp object. The client and class names can be specified using wildcard strings, where the characters '*' and '?' stand for any run of characters, and any single character, respectively. The value specified for the mac attribute can be a list of partial MAC addresses, where each item can be less than a full 6-byte address. Any device whose MAC's leading bytes match one of the items in the mac list is acceptable. [The fixed-allocation example above is actually a special case of this general method for restricting allocation pools, where a single MAC address was specified in full.]

For example, as discussed in Appendix C, the first three octets (bytes) of a MAC address identify the organization (often the end product manufacturer) which is registered to allocate that MAC address to an Ethernet device. By specifying only these first three bytes (six hexadecimal characters, no colon delimiters), in the mac attribute, you can ensure that all devices from the associated manufacturer are allocated addresses from a particular address pool. This is helpful if you have some common firewalling requirements for such a group of devices - for example, if all of your VoIP phones are from one manufacturer, as you can have appropriate firewall rule(s) that apply to addresses in that pool.

The following example illustrates this technique. It will match any devices which have MAC addresses beginning 00:04:13 or 00:0E:08, and which also have a vendor class name containing the string phone:

  <interface ...>
  ...
    <dhcp name="VoIP"
        ip="10.20.30.40-50"
        mac="000413 000E08"
	class="*phone*"
        dns="8.8.8.8"
        log="DHCP-Phones"
        comment="VoIP phones"/>
  ...
  </interface>

The algorithm used to determine which pools apply to a particular device is as follows:

  • If no restricted pools (ie those with one or more of the mac, client-name or class attributes present) match the device's properties, then all non-restricted pools apply.
  • If any restricted pools match the device's properties, then only restriced pools which match the device apply. Furthermore, a scoring system is used to select which of those pools to use based on how well the device's properties match. An exact match scores higher than any partial or wildcarded match and a MAC match scores higher than a client-name match, with a class-name match scoring the least. The score for a partial or wildcarded match is based on the number of bytes or characters which were explicitly matched.
  • Only the pool or pools with the highest score are considered.

Note

While this may seem rather complex, it achieves the intuitively-expected result in most cases - for example it allows a pool to be set up for a general class of device or a range of MAC addresses, and for more specific pool entries to be included which will take precedence for individual devices, eg with a full MAC address or a specific client-name.

6.3.2.3. Special DHCP options

For each pool, in addition to the common DHCP options to be supplied to the client device which you can configure using recognized attributes (eg gateway, dns, domain), you can also supply other DHCP options, specified as a string, IPv4 address or number, or even as raw data in hexadecimal. You can force sending of an option even if not requested.

For vendor-specific options (ID 43) you can either specify in hex as ID 43, or you can specify the code to use and set the vendor flag; this adds an option type 43 with the code and length for the option which can be string, IPv4 address, number, or hexadecimal.

6.3.3. DHCP Relay Agent

You can configure the FireBrick to operate as a DHCP/BOOTP Relay agent simply by setting the dhcp-relay in the interface object to the IPv4 address of the remote DHCP server.

If you also configure a DHCP allocation on the same interface, this is checked first, and if there are no suitable allocation pools or IP addresses available then the request is relayed. Normally you would configure either a relay or a pool and not both.

The top level dhcp-relay configuration allows you to configure the FireBrick to be the remote server for a DHCP/BOOTP Relay Agent. The relay attribute allows specific pools to be set up for specific relays. The table and allow allow you to limit the use of the DHCP Remote server to requests from specific sources - note that renewal requests come from the allocated IP, or NAT IP if behind NAT and not necessarily from the relay IP.

The allocation-table attribute allows for this pool of IPs to be placed in a separate table, thus allowing it to be independant from other DHCP allocations on the FireBrick and to allow different overlapping pools for different relay endpoints, which is not uncommon if the endpoints are behind separate NAT routers.