| 6.3. Defining an interface | ||
|---|---|---|
 | Chapter 6. Interfaces and Subnets |  |
| 6.3. Defining an interface | ||
|---|---|---|
| | Chapter 6. Interfaces and Subnets | |
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 :-
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.
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.
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.
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.
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 can be useful for restricting customer connections to only originate traffic from their assigned IP addresses.
Setting source filtering to blackhole is less restrictive. It allows IPs to which there is a valid route
even if to a different interface. If the IP is routed to a black hole or a dead end or not in the routing table then it is not
accepted.
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.
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.
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 />
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>
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.
'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>
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 21 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.
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:
mac, client-name
or class attributes present) match the device's properties, then all non-restricted pools apply.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.
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.
| |  | |
| 6.2. Defining port groups |  | 6.4. Physical port settings |