| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
Address Resolution Protocol (ARP) allows the mapping of a network layer protocol (OSI layer 3) address to a data link layer hardware address (OSI layer 2). In data networks it is used to resolve an IPv4 address into its corresponding Ethernet address. ARP operates at the OSI layer 2, data link layer, and is encapsulated by Ethernet headers for transmission.
A host in an Ethernet network can communicate with another host only if it knows the Ethernet address (MAC address) of that host. Higher level protocols such as IP make use of IP addresses which are fundamentally different from a lower level hardware addressing scheme like the MAC address. ARP is used to retrieve the Ethernet MAC address of a host by using its IP address.When a host needs to resolve an IPv4 address to the corresponding Ethernet address, it broadcasts an ARP request packet. The ARP request packet contains the source MAC address, the source IPv4 address and the destination IPv4 address. Each host in the local network receives this packet. The host with the specified destination address, sends an ARP reply packet to the originating host with its MAC address.
The ARP Cache in network equipment, such as switches and firewalls, is an important component in the implementation of ARP. It consists of a dynamic table that stores the mappings between IP addresses and Ethernet MAC addresses.
cOS Core uses an ARP cache in exactly the same way as other network equipment. Initially, the cache is empty at cOS Core startup and becomes populated with entries as traffic flows.
The typical contents of a minimal ARP Cache table might look similar to the following:
| Type | IPv4 Address | Ethernet Address | Expires |
|---|---|---|---|
| Dynamic | 192.168.0.10 | 08:00:10:0f:bc:a5 | 45 |
| Dynamic | 193.13.66.77 | 0a:46:42:4f:ac:65 | 136 |
| Publish | 10.5.16.3 | 4a:32:12:6c:89:a4 | - |
The explanation for the table contents are as follows:
The first entry in this ARP Cache is a dynamic ARP entry which tells us that IPv4 address 192.168.0.10 is mapped to an Ethernet address of 08:00:10:0f:bc:a5.
The second entry in the table dynamically maps the IPv4 address 193.13.66.77 to Ethernet address 0a:46:42:4f:ac:65.
The third entry is a static ARP entry binding the IPv4 address 10.5.16.3 to Ethernet address 4a:32:12:6c:89:a4.
The Expires Column
The third column in the table, Expires, is used to indicate how much longer the ARP entry will be valid for.For example, the first entry has an expiry value of 45 which means that this entry will be rendered invalid and removed from the ARP Cache in 45 seconds. If traffic is going to be sent to the 192.168.0.10 address after the expiration, cOS Core will issue a new ARP request.
The default expiration time for dynamic ARP entries is 900 seconds (15 minutes). This can be changed by modifying the advanced setting ARP Expire.
The advanced setting ARP Expire Unknown specifies how long cOS Core will remember addresses that cannot be reached. This limit is needed to ensure that cOS Core does not continuously request such addresses. The default value for this setting is 3 seconds.
Example 3.31. Displaying the ARP Cache
The contents of the ARP Cache can be displayed from within the CLI.
Command-Line Interface
Device:/> arp -show
ARP cache of iface lan
Dynamic 10.4.0.1 = 1000:0000:4009 Expire=196
Dynamic 10.4.0.165 = 0002:a529:1f65 Expire=506
Flushing the ARP Cache
If a host in a network is replaced with new hardware and retains the same IP address then it will probably have a new MAC address. If cOS Core has an old ARP entry for the host in its ARP cache then that entry will become invalid because of the changed MAC address and this will cause data to be sent to the host over Ethernet which will never reach its destination.After the ARP entry expiration time, cOS Core will learn the new MAC address of the host but sometimes it may be necessary to manually force the update. The easiest way to achieve this is by flushing the ARP cache. This deletes all dynamic ARP entries from the cache and forces cOS Core to issue new ARP queries to discover the MAC/IP address mappings for connected hosts.
Flushing can be done with the CLI command arp -flush.
Example 3.32. Flushing the ARP Cache
This example shows how to flush the ARP Cache from within the CLI.
Command-Line Interface
Device:/> arp -flush
ARP cache of all interfaces flushed.
Hash tables are used to rapidly look up entries in the ARP Cache. For maximum efficiency, a hash table should be twice as large as the entries it is indexing, so if the largest directly connected LAN contains 500 IP addresses, the size of the ARP entry hash table should be at least 1000. The administrator can modify the ARP advanced setting ARP Hash Size to reflect specific network requirements. The default value of this setting is 512.
The setting ARP Hash Size VLAN setting is similar to the ARP Hash Size setting, but affects the hash size for VLAN interfaces only. The default value is 64.
Handling Unsolicited ARP Message Handling
The default behavior of cOS Core is that it will ignore ARP responses that it has not sent out queries for. This is to make "ARP spoofing" difficult. However, in certain situations, ignoring these unsolicited messages can cause problems.For example, an external server cluster may share an IP address and when one server takes over from another server, the IP address needs to become associated with a different ARP address. In this situation, the requirement is for cOS Core to update its ARP cache when the cluster sends out gratuitous ARP messages to surrounding equipment.
To have cOS Core respond to all ARP messages and ARP queries, the following changes are required:
The above settings with further explanations can be found in Section 3.5.4, ARP Issues and Settings. This topic is also discussed further in the Clavister Knowledge Base at the following link:
Overview
cOS Core supports the publishing of IP addresses on interfaces other than the one the IP address is actually connected to. This can optionally be done along with a specific MAC address instead of the publishing interface's MAC address. cOS Core will then send out ARP replies for ARP requests received on the interface for the published IP addresses. This feature is referred to in cOS Core as ARP Publish.Usage
ARP publish may be used for a variety of reasons, such as the following:To give the impression that an interface in cOS Core has more than one IP address.
This is useful if there are several separate IP spans on a single LAN. The hosts on each IP span may then use a gateway in their own span when these gateway addresses are published on the corresponding cOS Core interface.
Another use is publishing multiple addresses on an external interface, enabling cOS Core to statically address translate traffic to these addresses and send it onwards to internal servers with private IPv4 addresses.
A less common purpose is to aid nearby network equipment responding to ARP in an incorrect manner.
Methods of Enabling ARP Publishing
ARP publishing is enabled in one of the following ways:An ARP object can be created for any interface by defining a single address which is to be ARP published on that interface.
When a static route is created for an IPv4 address or network, the route option called Proxy ARP can be used to publish the address or network on all or selected interfaces.
Using ARP objects, single IP addresses only can be published one at a time. However, the Proxy ARP feature can publish entire networks. It also provides a single step to publish on all interfaces.
Proxy ARP is covered in Section 4.2.6, Proxy ARP and is not discussed further in this section.
The type of ARP object. As explained above, this can be one of:
The local physical Ethernet interface for the ARP object.
The IP address for the MAC/IP mapping.
The MAC address for the MAC/IP mapping. If it is omitted, the MAC address of the Ethernet interface is used.
The three publishing mode options for ARP objects of Static, Publish and XPublishare further explained next.
A Static ARP object inserts a mapping into the cOS Core ARP cache which connects a specified IP address with the associated Ethernet interface's MAC address.This mode is not for publishing the address for external devices but rather for telling cOS Core itself how to reach external devices. A static ARP entry tells cOS Core that a specific IP address can be reached through a specific interface using a specific MAC address. This means, that when cOS Core wants to communicate with the address, it consults the ARP table static entries and can determine that it can be reached at a specific MAC address on a specific interface.
The most frequent use of static ARP objects is in situations where some external network device is not responding to ARP requests correctly and is reporting an incorrect MAC address. Some network devices, such as wireless modems, can have these problems.
It may also be used to lock an IP address to a specific MAC address for increasing security or to avoid denial-of-service if there are rogue users in a network. However, such protection only applies to packets being sent to that IP address. It does not apply to packets being sent from that IP address.
Publish and XPublish Modes
With Publish and XPublish modes, the ARP object creates an association between an IP address and a MAC address for publishing on the interface to external devices.If the MAC address is not specified, the MAC address of the associated Ethernet interface is used.
The Difference Between Publish and XPublish Modes
To understand the difference between Publish and XPublish it is necessary to understand that when cOS Core responds to an ARP query, there are two MAC addresses in the Ethernet frame sent back with the ARP response:The MAC address in the Ethernet frame of the Ethernet interface sending the response.
The MAC address in the ARP response which is contained within this frame. This is usually the same as (1) the source MAC address in the Ethernet frame but does not have to be.
These are shown in the illustration below of an Ethernet frame containing an ARP response:
The Publish option uses the real MAC address of the sending interface for the address (1) in the Ethernet frame.
In rare cases, some network equipment will require that both MAC addresses in the response (1 and 2 above) are the same. In this case XPublish is used since it changes both MAC addresses in the response to be the published MAC address. In other words, XPublish "lies" about the source address of the ARP response. If a published MAC address is the same as the MAC address of the Ethernet interface, it will make no difference if Publish or XPublish is selected, the result will be the same.
ARP and Neighbor Discovery
Neighbor Discovery with IPv6 is the equivalent of ARP with IPv4. For this reason, ARP and neighbor discovery are combined in The graphical interface to cOS Core uses the same dialog to add either one. Neighbor Discovery is discussed further in Section 3.2, IPv6 Support.Example 3.33. Defining an ARP/Neighbor Discovery Object
This example will create a static mapping between IPv4 address 192.168.10.15 and Ethernet address 4b:86:f6:c5:a2:14 on the lan interface:
Command-Line Interface
Device:/> add ARPND Interface=lan
IP=192.168.10.15
Mode=Static
MACAddress=4b-86-f6-c5-a2-14InControl
Follow similar steps to those used for the Web Interface below.
Web Interface
This section presents some of the advanced settings related to ARP. In most cases, these settings need not to be changed, but in some deployments, modifications might be needed.
A complete list of all ARP advanced settings can be found in the separate cOS Core CLI Reference Guide under the object name ARPNDSettings.
ARP requests and ARP replies containing multicast or broadcast addresses are usually never correct, with the exception of certain load balancing and redundancy devices, which make use of hardware layer multicast addresses.The default behavior of cOS Core is to drop and log such ARP requests and ARP replies. This can, however, be changed by modifying the advanced settings ARP Multicast and ARP Broadcast.
It is possible for a host on a connected network to send an ARP reply to cOS Core even though a corresponding ARP request was not issued. This is known as an unsolicited ARP reply.According to the ARP specification, the recipient should accept these types of ARP replies. However, because this could be a malicious attempt to hijack a connection, cOS Core will, by default, drop and log unsolicited ARP replies.
This behavior can be changed by changing the advanced setting Unsolicited ARP Replies to the value Accept (this setting is found in the Web Interface in Network > ARP/Neighbor Discovery > Advanced Settings).
ARP Requests
The ARP specification states that a host should update its ARP Cache with data from ARP requests received from other hosts. However, as this procedure can facilitate hijacking of local connections, cOS Core will normally not allow this.To make the behavior compliant with the RFC-826 specification, the administrator can modify the setting ARP Requests. Even if this is set to Drop (meaning that the packet is discarded without being stored), cOS Core will reply to it provided that other rules approve the request.
Changes to the ARP Cache
A received ARP reply or ARP request can possibly alter an existing entry in the ARP cache. Allowing this to take place may allow hijacking of local connections. However, not allowing this may cause problems if, for example, a network adapter is replaced since cOS Core will not accept the new address until the previous ARP cache entry has timed out.The advanced setting Static ARP Changes can modify this behavior. The default behavior is that cOS Core will allow changes to take place, but all such changes will be logged.
A similar issue occurs when information in ARP replies or ARP requests could collide with static entries in the ARP cache. This should not be allowed to happen and changing the setting Static ARP Changes allows the administrator to specify whether or not such situations are logged.
cOS Core can be configured for handling ARP queries that have a sender IP of 0.0.0.0. Such sender IPs are never valid as responses, but network units that have not yet learned of their IP address sometimes ask ARP questions with an "unspecified" sender IP. Normally, these ARP replies are dropped and logged, but the behavior can be changed by modifying the setting ARP Query No Sender. By default, cOS Core will require that the sender address at Ethernet level should comply with the Ethernet address reported in the ARP data. If this is not the case, the reply will be dropped and logged. The behavior can be changed by modifying the setting ARP Match Ethernet Sender. An IP collision occurs when two devices, connected via a network, are trying to use the same IP address. cOS Core detects collisions where it finds that a packet arriving at an interface has a source IP address which is the same as the IP assigned to that interface.The setting ARP IP Collision controls how cOS Core responds to such events. The default behavior is to drop any packets with colliding IP addresses. The setting allows the additional action of sending out gratuitous ARPs. These gratuitous messages have the effect of resetting the ARP caches of switches and other network equipment so that the firewall becomes the presumed owner of the IP addresses. However, it is possible that the external device using the colliding IP address might also itself respond with such gratuitous ARPs because it also has detected a collision.
Note that it is possible to initiate the generation of gratuitous ARPs from an individual cOS Core interface using the CLI command:
Device:/> ifstat -restart <interface-name>This is also discussed in an article in the Clavister Knowledge Base at the following link:
https://kb.clavister.com/324735679
ARP issues with network comminication through WiFi access points can show up as the log event arp_resolution_failed being generated by cOS Core. This is often related to the configuration of some WiFi access points where they no longer forward ARP requests to clients.A detailed discussion of this topic can be found in an article in the Clavister Knowledge Base at the following link:
It is possible to use a feature called the neighbor cache to get additional information about both IPv4 and IPv6 devices that are communicating with the firewall. This cache takes information from both the IPv4 ARP cache and the IPv6 neighbor discovery cache and supplements it with additional details about connected devices.
The neighbor cache contents can be viewed in one of the following ways:
Using the Web Interface
The Web Interface can display the cache in table form by going to:
Status > Sub Systems > Neighbor Devices.
Using the CLI
The CLI command neighborcache will display the cache in table form.
Using the REST API
The REST API can be used by software running on an external computer to retrieve the contents of the cache in JSON format. This is discussed further in the separate cOS Core REST API Guide.
Values Displayed from the Neighbor Cache
The following values can be retrieved from the neighbor cache:Interface
This is the local cOS Core interface that is connected to the external device.
MAC Address
This is the MAC address of the external device. However, in the Web Interface this value can either be a numeric MAC address of the name of the first Ethernet Address object in the local configuration which contains the same MAC address as the device.
For an Ethernet Address object name to be displayed instead of the numeric MAC address, the administrator must create such an object in the configuration with the relevant MAC address. These objects are discussed further in Section 3.1.3, Ethernet Address Objects.
As explained at the end of this section, in the CLI the MAC address and any matching address book objects are displayed separately.
Vendor
The name of the vendor, normally a company name, that is usually associated with the MAC address.
IPv4 Address/IPv6 Address
The IPv4 or IPv6 address of the external device.
Authenticated User
If cOS Core authentication took place when the device connected then this will be the username that was used with the authentication process.
DHCP Hostname
This value may be included if the external device was allocated its IP address by cOS Core acting as a DHCP server. The hostname will be the name sent by the external device in its DHCP request for an IP address. If it did not send a name in the request, the hostname value will not be included.
Status
This can take the value Active or Inactive depending on whether any recent traffic was seen to or from the device.
Timeout
If the status is Inactive then this is the number of seconds since the last traffic was seen. In the Web Interface, this value is shown alongside the status in minutes and seconds.
Additional Information from Device Intelligence
The standard output from the neighbor cache can be extended using the device intelligence feature. This provides more detailed information about individual devices, however, it must be explicitly enabled. How to do this, along with a detailed description of the feature, can be found in Section 3.5.6, Device Intelligence.Using the neighborcache CLI Command
The neighborcache command can be used in the CLI to show the information listed above. However, the command with no options does not show all values. For example:Device:/> neighborcache
Contents of Active Neighbor Cache [Active:1]
Idx Iface HW Address IP4 Address State Timeout Vendor
--- ------ ----------------- --------------- -------- ------- ------
1 wan 00-50-8B-E9-46-5E 203.0.113.5 Active 0 Mega Corp.
2 lan 40-45-D1-61-02-7B 192.168.188.1 Inactive 171954 ClavisterDevice:/> neighborcache -usersDevice:/> neighborcache -namesAll the neighborcache command options can be found in the separate cOS Core CLI Reference Guide.
It should be noted that the neighbor cache is fully synchronized between the nodes in a cOS Core high availability cluster. This means that should an HA failover occur, all the information in the cache at the time of the failover is immediately available in the new active cluster node.Overview
The Device Intelligence feature in cOS Core provides additional device information in the display of the neighbor cache contents (described in Section 3.5.5, The Neighbor Cache). This extra information more precisely identifies the type of device in the neighbor cache by providing details such as hardware manufacturer and operating system.The device intelligence feature is also sometimes referred to as device fingerprinting and the term "fingerprinting" will be used sometimes in this section to describe the process of device identification.
The Device Fingerprint Database
cOS Core implements device intelligence by looking up the "fingerprint" of a device in the device database provided by the fing™ company. This database is running on a server accessed over the Internet via the Clavister Service Provider Network (SPN), so Internet access is normally needed with at least one public DNS server configured in cOS Core for FQDN lookup.As an alternative method of SPN access when direct Internet access is not possible, cOS Core can instead make use of an HTTP proxy. Setting up this proxy feature for all types of SPN access is described in Appendix A, Subscription Based Features.
Types of Devices
Fingerprinting cannot be applied to all device entries in the neighbor cache. The entries that can be fingerprinted are any of the following:IPv4 DHCP clients where either cOS Core is the DHCP server or it is acting as a DHCP relayer for the client to an external DHCP server.
DHCPv6 clients where cOS Core is the DHCPv6 server.
Device Intelligence Requires a Subscription
Device intelligence is a feature which requires the current cOS Core license to allow it. This is discussed further in Appendix A, Subscription Based Features. If the license does not allow it, or the subscription for the feature has expired, the device intelligence information will be missing from the neighbor cache output. The device intelligence feature is not enabled in the default cOS Core configuration and must be explicitly switched on by the administrator. Doing this is described below in Example 3.34, “Enabling Device Intelligence”.Example 3.34. Enabling Device Intelligence
This example shows how the device intelligence feature is enabled (by default, it is disabled).
Command-Line Interface
Device:/> set Settings MiscSettings DeviceIntelligence=YesInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
Information Provided by Device Intelligence
The following details about a client can be provided by the device intelligence feature:Name - The local name assigned to a device. For example, Dave's Computer.
Vendor - The device manufacturer. For example, Apple.
Type - The type of device. For example, mobile, tablet, computer, TV, VOIP phone.
Model - The device mode. For example, MacBook PRO.
OS - The OS that the device is running. For example, Android.
Direct Methods of Viewing Device Intelligence Information
The following methods can be used to view the device intelligence output:Using the Web Interface
To see all the current device intelligence information in the Web Interface, display the neighbor cache by going to Status > Neighbor Cache.
Using the CLI
To display all the device intelligence in the CLI, the neighbor command with the -devinfo option is used. Some example output is shown below where there is a single device in the neighbor cache which has been fingerprinted:
Device:/> neighborcache -devinfo
Contents of Active Neighbor Cache [Active:1]
Idx Iface HW Address IP4 Address Vendor Type
--- ----- ----------------- ----------- ------- -------------
1 If1 10-01-00-13-E9-53 0.0.0.0 Apple Domain Server
Model OS
----------- -----------
MacBook Air OS XNote that the above command will only display IPv4 clients. In order to display only the IPv6 clients, the -ip6 option can be used:
Device:/> neighborcache -devinfo -ip6It is not possible to display IPv4 and IPv6 clients at the same time.
Viewing device information using the above two methods will not display all the information available from the device intelligence database. However, the log messages generated by the device intelligence feature will do this and this is discussed next.
Viewing Device Information in Log Messages
For each device in the neighbor cache that causes a fing database query, two device_identified log messages will be generated and at the following times:When the device sends out a IPv4 DHCP or DHCPv6 request.
This is when the initial fing database lookup is done. Below is an example: device_identified log message generated by this event.
prio=Info id=08800001 rev=1 event=device_identified action=none if=eth3 zone=AlfaZone hostname="eth100000ab4312" srcmac=10-00-00-AB-43-12 device_ip4= device_ip6= device_type="Mobile" device_vendor="Private" device_type="MOBILE" device_type_name="Mobile" device_type_group_name="Mobile" device_os_name="Android" device_brand="Sony" device_model="Xperia" device_rank=68
When the client receives the requested IPv4 or IPv6 address
When the client receives the requested IP address, another device_identified log message is generated. This is identical to the initial log message described above, except that the IP address is now allocated. This is shown below where the IPv4 address has now been assigned.
prio=Info id=08800001 rev=1 event=device_identified action=none if=eth3 zone=AlfaZone hostname="eth100000ab4312" srcmac=10-00-00-AB-43-12 device_ip4=203.0.113.5 device_ip6= device_type="Mobile" device_vendor="Private" device_type="MOBILE" device_type_name="Mobile" device_type_group_name="Mobile" device_os_name="Android" device_brand="Sony" device_model="Xperia" device_rank=68
The following should be noted about the above log messages:
The log messages include all the fields that are available from the device intelligence database. Only some of these are displayed when looking at the neighbor cache with either the Web Interface or CLI.
There is never a "no match". However, some fields may be left without a value when the device intelligence server is unable to determine a value. For example: device_type="".
Performing Ad Hoc Vendor Lookups with enetvendor
cOS Core provides a CLI command to perform an ad hoc vendor lookup for any MAC address. For example:Device:/> enetvendor -hw=40-84-93-15-04-67
Vendor: Clavister AB