SonicOSX 7 Match Objects

Download PDF
Technical Documentation > SonicOSX 7 Match Objects > Addresses

Addresses

Address objects (AOs) allow for entities to be defined one time, and to be re-used in multiple referential instances throughout the SonicOS interface. While more effort is involved in creating an address object than in simply entering an IP address, address objects were implemented to complement the management scheme of SonicOS, providing the following characteristics:

  • Zone Association – When defined, host, MAC, and FQDN AOs require an explicit zone designation. In most areas of the interface (such as access rules) this is only used referentially. The functional application are the contextually accurate populations of address object drop-down menus and the area of VPN access definitions assigned to users and groups. When AOs are used to define VPN access, the access rule auto-creation process refers to the AO’s zone to determine the correct intersection of VPN [zone] for rule placement. In other words, if the host AO, 192.168.168.200 Host, belonging to the LAN zone was added to VPN access for the Trusted Users user group, the auto-created access rule would be assigned to the VPN LAN zone.
  • Management and Handling – The versatile family of address objects types can be easily used throughout the SonicOS interface, allowing for handles (for example, when defining access rules) to be quickly defined and managed. The ability to simply add or remove members from address groups effectively enables modifications of referencing rules and policies without requiring direct manipulation.
  • Reusability – Objects only need to be defined once, and can then be easily referenced as many times as needed.

For example, take an internal web server with an IP address of 67.115.118.80. Rather than repeatedly typing in the IP address when constructing access rules or NAT policies, you can create a single entity called My Web Server as a host address object with an IP address of 67.115.118.80. This address object, My Web Server, can then be easily and efficiently selected from a drop-down list in any configuration screen that employs address objects as a defining criterion.

Types of Address Objects

As there are multiple types of network address expressions, there are multiple address object types, as shown in the below table.

Type Definition
Host Defines a single host by its IP address and zone association. The netmask for a host address object is automatically set to 32-bit (255.255.255.255) to identify it as a single host. For example, My Web Server with an IP address of 67.115.118.110 and a default netmask of 255.255.255.255.
Range Defines a range of contiguous IP addresses. No netmask is associated with range address objects, but internal logic generally treats each member of the specified range as a 32-bit masked host object. For example, My Public Servers with an IP address starting value of 67.115.118.66 and an ending value of 67.115.118.90. All 25 individual host addresses in this range are included in this address object.
Network Similar to range objects in that they include multiple hosts, but rather than being bound by specified upper and lower range delimiters, the boundaries are defined by a valid netmask. Network address objects must be defined by the network’s address and a corresponding netmask. For example, My Public Network with a network address of 67.115.118.64 and a netmask of 255.255.255.224 would include addresses from 67.115.118.64 through 67.115.118.95. As a general rule, the first address in a network (the network address) and the last address in a network (the broadcast address) cannot be assigned to a host.
MAC Allows for the identification of a host by its hardware address or IPv4/IPv6 MAC (Media Access Control) address. MAC addresses are uniquely assigned to every piece of wired or wireless networking device by their hardware manufacturers, and are intended to be immutable. MAC addresses are 48-bit values that are expressed in 6-byte hex-notation. For example, My Access Point with a MAC address of 00:06:01:AB:02:CD. MAC addresses are resolved to an IP address by referring to the ARP cache on the security appliance. MAC address objects are used by various components of wireless configurations throughout SonicOS, such as SonicPoint or SonicWave identification, and authorizing the BSSID (Basic Service Set Identifier, or WLAN MAC) of wireless access points detected during wireless scans. MAC address objects can also be used to allow hosts to bypass Guest Services authentication.
FQDN Allows for the identification of a host by its IPv4/IPv6 Fully Qualified Domain Name (FQDN), such as www.sonicwall.com. FQDNs are be resolved to their IP address (or IP addresses) using the DNS server configured on the security appliance. Wildcard entries are supported through the responses to queries sent to the DNS servers.

About Address Groups

SonicOS has the ability to group address objects and other address groups into address groups. Address groups can be defined to introduce further referential efficiencies. Address groups can contain any combination of host, range, or network address objects. For example, My Public Group can contain the host address object, My Web Server, and the range address object, My Public Servers, effectively representing IP addresses 67.115.118.66 to 67.115.118.90 and IP address 67.115.118.110.

Dynamic address objects (MAC and FQDN) should be grouped separately, although they can safely be added to address groups of IP-based address objects, where they will be ignored when their reference is contextually irrelevant (for example, in a NAT policy).

Address groups are automatically created when certain features are enabled, such as a Radius Pooladdress group when the Enable Local Radius Server option is enabled in WLAN zone configuration, and are deleted when the feature is disabled.

About UUIDs for Address Objects and Groups

A UUID (Universally Unique Identifier) is a 36-character string (32 alphanumeric characters and four hyphens) that is used to uniquely identify address objects and groups, among other entities, on SonicWall network security appliances. The SonicOS UUID is a system-generated, read-only internal value with these properties:

  • A UUID is a unique representation of a SonicOS entity across the network.
  • A UUID is generated at creation of an entity and removed at the deletion of the entity. It is not reused once it is removed.
  • When an entity is modified, the UUID stays the same.
  • UUIDs are regenerated after restarting the appliance with factory default settings.

By default, UUIDs are not displayed. UUID display is controlled by internal settings. For more information about internal settings, contact SonicWall Technical Support.

When displayed, UUIDs appear in the tables for each object or group type.

UUIDs facilitate the following functions:

  • You can search for an address object or group by UUID with the global search function of the management interface.
  • If an object or group object with a UUID is referenced by another entity with a UUID, you can display the reference count and referring entities by mousing over the Comment column on the Addresses page under Object.

Address Objects screen

Address Groups screen

Common Features

The screen Address Objects and Address Groups contains these common functions and each table contains the same column headings.

The bottom of each table displays the number of entries in the table.

Common Functions

Function Description
Search Type in a search string to display only those entries containing the string. The search string is case insensitive.
View Select Default to display only system-created default entries, Custom to display only custom entries, or All to display all entries. By default, the view type is selected as All.
IP Version Select IPv4 to display only IPv4 entries, IPv6 to display only IPv6 entries, or IPv4 & IPv6 to display all entries. By default, the IP version is selected as IPv4 & IPv6.
Add Click to add an address object or address group.
Delete Select Delete to delete selected custom entries from the table. Default entries cannot be deleted.
Delete All Select Delete All to delete all custom entries from the table. Default entries cannot be deleted.
Resolve All Select Resolve All to resolve all MAC or FQDN entries in the table.
Purge All Select Purge All to remove out-of-date information from all MAC or FQDN entries. For MAC address objects, this is ARP information, and for FQDN address objects it is DNS TTL values.
Refresh Click Refresh to refresh the table display.

Common Column Headings

Column Heading Description
Checkbox

Click to select a custom entry.

Default address objects and default address groups cannot be deleted.
# The number of the entry in the table. This number changes depending on whether the column is sorted by ascending or descending order. The Address Groups screen has a small triangle that allows you to expand or collapse the group entry.
Name

The unique name of the address object or address group entry. If an address group entry is expanded, this column shows:

  • The unique name of each member of the address group.
  • No Entries, if the address group does not contain members.
Details Shows the details of the address object: applicable addresses or mask. For an address group entry, this column is blank; an expanded entry, however, shows the details of the members of the group.
Type Shows the address object type, such as Host, Network, Range, MAC Address, or FQDN. For an address group, the type is Group; an expanded entry shows the type of each member.
IP Version Shows the IP version of the address object or address group member: IPv4, IPv6, or Mixed.
Zone Shows the assigned zone of the address object or address group member.
Class Shows whether the address object or address group is Default (system defined) or Custom (user defined).
Comments

Mouse over the Comment icon to display pop-up information with details about the entry:

  • Address Object - Displays this information:

    • Name of the address object

    • Referenced By: – What references the address object and the number of times it has been referenced. If the address object has not been referenced, this section will state 0.

    • Groups : – List of groups to which the address object belongs.

    • Configure : – When you mouse over on the address object Edit and Deleteicons for individual entries are displayed. Only custom address objects can be deleted; only custom entries and some default entries can be edited. If an entry cannot be edited or deleted, the icon(s) are dimmed.
  • Address Group - Displays this information:

    • Name of the address group

    • Referenced By: – What references the address group and the number of times it has been referenced. If the address group has not be referenced, this section will state 0.

    • Groups : – List of groups to which the address group belongs.

    • Configure : – When you mouse over on the address group Edit and Delete icons for individual entries are displayed. Only custom address groups can be deleted; only custom entries and some default entries can be edited. If an entry cannot be edited or deleted, the icon(s) are dimmed.

Sorting the Entries

The Address Objects and Address Groups screens display tables for easy viewing of address objects and address groups.

You can sort the entries in the table by clicking on the column header. The entries are sorted by ascending or descending order. The arrow to the right of the column entry indicates the sorting status. A down arrow means ascending order. An up arrow indicates a descending order (alphabetical A-Z or numeric starting from zero at the top).

Default Address Objects and Groups

The Default view displays the default address objects and address groups for your firewall. Selecting the Default view on one screen selects it for both screens. Default address objects entries cannot be modified or deleted although some default address groups can be. Therefore, on the:

  • Address Objects screen, the Edit and Delete icons are dimmed.
  • Address Groups screen, the Edit icon for most entries and the Delete icon for all but a few entries are dimmed. Those entries that can be edited or deleted have the requisite icons available.

Default Pref64 Address Object

To support the NAT64 feature, SonicOS provides the default network address object, Pref64. It is the original destination for a NAT64 policy and is always pref64::/n. You can create an address object of Network type to represent all addresses with pref64::/n to represent all IPv6 clients that can do NAT64; for example:

A well-known prefix, 64:ff9b::/96, is auto created by SonicOS. For further information about Pref64, see Policy > NAT Rules section.

Default Rogue Address Groups

SonicOS provides two default address groups for rogue wireless access points and devices.

  • All Rogue Access Points
  • All Rogue Devices

When Wireless Intrusion Detection and Prevention (WIDP) is enabled, SonicWave appliances can act as both an access point and as a sensor detecting any unauthorized access point connected to a SonicWall network. Detected rogue access points can be automatically added to the All Rogue Access Points address group, and detected rogue devices added to the All Rogue Devices address group. For information about enabling options related to rogue access points, see Configuring Advanced IDP in the SonicOS 7 Connectivity administration documentation.

Adding an Address Object

An address object must be defined before configuring NAT policies, access rules, and services.

To add an address object

  1. Navigate to Objects > Addresses > Address Objects page.

  2. On the Address Objects screen, click Add at the top of the page to display the Add Address Object dialog.

  3. In the Name field, enter a descriptive, unique name for the network address object.

  4. Select the zone for the address object from the Zone Assignment drop-down list.

  5. Select one of the following from the Type drop-down list and fill in the associated fields that display when you select the Type:

    • Host, enter the IP address in the IP Address field.

    • Range, enter the starting and ending IP addresses in the Starting IP Address and Ending IP Address fields.

    • Network, enter the network IP address and netmask (such as 255.255.255.0) or prefix length (such as 24) in the Network and Netmask/Prefix Length fields.

    • FQDN, enter the domain name for the individual site or range of sites (with a wildcard ‘*’) in the FQDN Hostname field. Optionally, select Manually set DNS entries and enter the time-to-live in seconds in the TTL (120 ~ 86400s) field. The minimum value is 120 and the maximum is 86400 seconds.

    • MAC, enter the MAC address (such as 00:11:f5:1b:e3:cf) in the MAC Address field. By default, Multi homed option is selected.

  6. Click Save.

Editing Address Objects

Only custom address objects and certain default address objects can be edited.

To edit an address object

  1. Navigate to Objects > Addresses > Address Objects page.
  2. In the Configure column on the Address object, click Edit icon. The Edit Address Object window is displayed, which has the same settings as the Add Address Object window (refer to Adding an Address Object).
  3. Click OK.

Deleting Address Objects

Only custom address objects can be deleted.

To delete a custom address object

  1. Navigate to Objects > Addresses > Address Objects page.
  2. In the Configure column on the Address object, click Delete icon.
  3. In the confirmation dialog box, click OK to delete the address object.

To delete one or more custom address objects

  1. Navigate to Objects > Addresses > Address Objects page.
  2. Select the checkboxes for the entries to be deleted.
  3. Click Delete at the top of the page.
  4. In the confirmation dialog box, click OK to delete the address objects.

To delete all custom address objects

  1. Navigate to Objects > Addresses > Address Objects page.
  2. Select Delete All at the top of the page.
  3. In the confirmation dialog box, click OK to delete all the custom address objects.

Purging MAC or FQDN Address Objects

Purge is used to remove out-of-date ARP or DNS information from MAC or FQDN address objects.

To purge all MAC or FQDN address objects

  1. Navigate to Objects > Addresses > Address Objects page.
  2. Click Purge Allat the top of the page.

Creating Address Groups

As more and more address objects are added to the firewall, you can simplify managing the addresses and access policies by creating groups of addresses. Changes made to the address group are applied to each address in the group. Address groups can contain other address groups as well as address objects.

To add an address group

  1. Navigate to Objects > Addressespage.
  2. Click the Address Groups tab at the top of the page.

  3. On the Address Groups screen, click Add to display the Add Address Group dialog.

  4. Create a descriptive, unique name for the group in the Name field.

  5. Select the desired address objects or groups from the list and then click the right arrow. The selected items move into the list on the right. Press the Ctrl or Shift key to select multiple items.

    To remove an item from the group, select the item in the right column and click the left arrow. The selected item moves from the list on the right to the list on the left. To remove all the items from the group, click un-select all items icon.

  6. Click Save.

Editing Address Groups

Only custom and some default address groups can be edited; only custom address groups can be deleted.

To edit an address group

  1. Navigate to Objects > Addressespage.
  2. Click the Address Groups tab at the top of the page.
  3. In the Configure column on the Address Group, click Edit icon. The Edit Address Group window is displayed.
  4. To change the name, edit the Name field.

  5. Select the desired address objects or groups from the list and then click the right arrow. The selected items move into the list on the right. Press the Ctrl or Shift key to select multiple items.

    To remove an item from the group, select the item in the right column and click the left arrow. The selected item moves from the list on the right to the list on the left. To remove all the items from the group, click un-select all items icon.

  6. Click Save.

Deleting Address Groups

Only custom address groups can be deleted.

To delete a custom address group

  1. Navigate to Objects > Addresses > Address Groups page.
  2. In the Configure column on the Address Group,click Delete icon.
  3. In the confirmation dialog box, click OK to delete the address group.

To delete one or more custom address groups

  1. Navigate to Objects > Addresses > Address Groups page.
  2. Select the checkboxes for the entries to be deleted.
  3. Click Delete at the top of the page.
  4. In the confirmation dialog box, click OK to delete the address groups.

To delete all custom address groups

  1. Navigate to Objects > Addresses > Address Groups page.
  2. Select Delete All at the top of the page.
  3. In the confirmation dialog box, click OK to delete all the custom address groups.

Working with Dynamic Address Objects

From its inception, SonicOS has used address objects to represent IP addresses in most areas throughout the user interface. For information about address object types, refer Types of Address Objects.

SonicOS supports two types of dynamic address objects:

  • MAC – SonicOS resolves MAC AOs to an IP address by referring to the ARP cache on the firewall.
  • FQDN – Fully Qualified Domain Names, such as ‘www.reallybadWebsite.com’, are resolved to their IP address (or IP addresses) using the DNS servers configured on the firewall. Wildcard entries using ‘*’ are supported through the gleaning of responses to queries sent to the sanctioned DNS servers.

Key Features of Dynamic Address Objects

The term Dynamic Address Object (DAO) describes the underlying framework enabling MAC and FQDN AOs. By transforming AOs from static to dynamic structures, access rules can automatically respond to changes in the network.

The below table provides details and examples for DAOs.

Dynamic Address Objects: Features and Benefits
Feature Benefit
FQDN wildcard support

FQDN address objects support wildcard entries, such as *.somedomainname.com, by first resolving the base domain name to all its defined host IP addresses, and then by constantly actively gleaning DNS responses as they pass through the firewall. For example, creating an FQDN AO for *.myspace.com will first use the DNS servers configured on the firewall to resolve myspace.com to 63.208.226.40, 63.208.226.41, 63.208.226.42, and 63.208.226.43 (as can be confirmed by nslookup myspace.com or equivalent). As most DNS servers do not allow zone transfers, it is typically not possible to automatically enumerate all the hosts in a domain. Instead, the firewall looks for DNS responses coming from sanctioned DNS servers as they traverse the firewall. So, if a host behind the firewall queries an external DNS server that is also a configured/defined DNS server on the firewall, the firewall parses the response to see if it matches the domain of any wildcard FQDN AOs.

Sanctioned DNS servers are those DNS servers configured for use by firewall. The reason that responses from only sanctioned DNS servers are used in the wildcard learning process is to protect against the possibility of FQDN AO poisoning through the use of unsanctioned DNS servers with deliberately incorrect host entries. Future versions of SonicOS might offer the option to support responses from all DNS server. The use of sanctioned DNS servers can be enforced with the use of access rules, as described later in Enforcing the Use of Sanctioned Servers on the Network.

To illustrate, assume the firewall is configured to use DNS servers 4.2.2.1 and 4.2.2.2, and is providing these DNS servers to all firewalled client via DHCP. If firewalled client-A performs a DNS query against 4.2.2.1 or 4.2.2.2 for vids.myspace.com, the response is examined by the firewall and matched to the defined *.myspace.com FQDN AO. The result (63.208.226.224) is then added to the resolved values of the *.myspace.com DAO.

If the workstation, client-A, in the example above had resolved and cached vids.myspace.com before the creation of the *.myspace.com AO, vids.myspace.com would not be resolved by the firewall because the client would use its resolver’s cache rather than issuing a new DNS request. As a result, the firewall would not have the chance to learn about vids.myspace.com unless it was resolved by another host. On a Microsoft Windows workstation, the local resolver cache can be cleared using the command ipconfig /flushdns. This forces the client to resolve all FQDNs, thereby allowing the firewall to learn them as they are accessed.

Wildcard FQDN entries resolve all hostnames within the context of the domain name, up to 256 entries per AO. For example, *.sonicwall.com resolves www.sonicwall.com, software.sonicwall.com, and licensemanager.sonicwall.com, to their respective IP addresses, but it does not resolve sslvpn.demo.sonicwall.com because it is in a different context; for sslvpn.demo.sonicwall.com to be resolved by a wildcard FQDN AO, the entry *.demo.sonicwall.com would be required, which would also resolve sonicos-enhanced.demo.sonicwall.com, csm.demo.sonicwall.com, sonicos-standard.demo.sonicwall.com, and so on.

Wildcards only support full matches, not partial matches. In other words, *.sonicwall.com is a legitimate entry, but w*.sonicwall.com, *w.sonicwall.com, and w*w.sonicwall.com are not. A wildcard can only be specified once per entry, so *.*.sonicwall.com, for example, is not functional.
FQDN resolution using DNS FQDN address objects are resolved using the DNS servers configured on the firewall in the Network > DNS page. Since it is common for DNS entries to resolve to multiple IP addresses, the FQDN DAO resolution process will retrieve all of the addresses to which a host name resolves, up to 256 entries per AO. In addition to resolving the FQDN to its IPs, the resolution process will also associate the entry’s TTL (time to live) as configured by the DNS administrator. TTL will then be honored to ensure the FQDN information does not become stale.
MAC address resolution using live ARP cache data When a node is detected on any of the firewall’s physical segments through the ARP (Address Resolution Protocol) mechanism, the firewall’s ARP cache is updated with that node’s MAC and IP address. When this update occurs, if a MAC address objects referencing that node’s MAC is present, it will instantly be updated with the resolved address pairing. When a node times out of the ARP cache due to disuse (for example, the host is no longer L2 connected to the firewall) the MAC AO will transition to an unresolved state.
MAC address object multi-homing support MAC AOs can be configured to support multi-homed nodes, where multi-homed refers to nodes with more than one IP address per physical interface. Up to 256 resolved entries are allowed per AO. This way, if a single MAC address resolves to multiple IPs, all of the IP will be applicable to the access rules, etc., that refer to the MAC AO.
Automatic and manual refresh processes MAC AO entries are automatically synchronized to the firewall’s ARP cache, and FQDN AO entries abide by DNS entry TTL values, ensuring that the resolved values are always fresh. In addition to these automatic update processes, manual Refresh and Purge capabilities are provided for individual DAOs, or for all defined DAOs.

Enforcing the Use of Sanctioned Servers on the Network

Although not a requirement, it is recommended to enforce the use of authorized or sanctioned servers on the network. This practice can help to reduce illicit network activity, and will also serve to ensure the reliability of the FQDN wildcard resolution process. In general, it is good practice to define the endpoints of known protocol communications when possible. For example:

Create address groups of sanctioned servers (for example, SMTP, DNS)

  • Create access rules in the relevant zones allowing only authorized SMTP servers on your network to communicate outbound SMTP; block all other outbound SMTP traffic to prevent intentional or unintentional outbound spamming.

  • Create access rules in the relevant zones allowing authorized DNS servers on your network to communicate with all destination hosts using DNS protocols (TCP/UDP 53).

    Be sure to have this rule in place if you have DNS servers on your network, and you will be configuring the restrictive DNS rule that follows.

  • Create access rules in the relevant zones allowing firewalled hosts to only communicate via DNS (TCP/UDP 53) with sanctioned DNS servers; block all other DNS access to prevent communications with unauthorized DNS servers.

  • Unsanctioned access attempts will then be viewable in the logs.

Using MAC and FQDN Dynamic Address Objects

MAC and FQDN DAOs provide extensive access rule construction flexibility. MAC and FQDN AOs are configured in the same way as static address objects, that is from the Object > Addresses > Address Objects page. Once created, their status can be viewed by a mouse-over of their appearance, and log events will record their addition and deletion.

Dynamic address objects lend themselves to many applications. The following are just a few examples of how they may be used.

Blocking All Protocol Access to a Domain using FQDN DAOs

There might be instances where you wish to block all protocol access to a particular destination IP because of non-standard ports of operations, unknown protocol use, or intentional traffic obscuration through encryption, tunneling, or both. An example would be a user who has set up an HTTPS proxy server (or other method of port-forwarding/tunneling on trusted ports like 53, 80, 443, as well as nonstandard ports, like 5734, 23221, and 63466) on his DSL or cable modem home network for the purpose of obscuring his traffic by tunneling it through his home network. The lack of port predictability is usually further complicated by the dynamic addressing of these networks, making the IP address equally unpredictable.

Since these scenarios generally employ dynamic DNS (DDNS) registrations for the purpose of allowing users to locate the home network, FQDN AOs can be put to aggressive use to block access to all hosts within a DDNS registrar.

A DDNS target is used in this example for illustration. Non-DDNS target domains can be used just as well.

Assumptions

  • The firewall is configured to use DNS server 10.50.165.3, 10.50.128.53.
  • The firewall is providing DHCP leases to all firewalled users. All hosts on the network use the configured DNS servers above for resolution.
  • The DSL home user is registering the hostname, moosifer.dyndns.org, with the DDNS provider DynDNS. For this session, the ISP assigned the DSL connection the address 71.35.249.153.
    • A wildcard FQDN AO is used for illustration because other hostnames could easily be registered for the same IP address. Entries for other DDNS providers could also be added, as needed.
Step 1 – Create the FQDN Address Object:
  1. Navigate to Objects > Addresses > Address Objects page.

  2. Click Add and create the following FQDN address object:

    When first created, this entry will resolve only to the address for dyndns.org, for example, 63.208.196.110. When a host behind the firewall attempts to resolve moosifer.dyndns.org using a sanctioned DNS server, the IP address(es) returned in the query response will be dynamically added to the FQDN AO.

Step 2 – Create the Access Rule:
  1. Navigate to Policies > Access Rules page.

  2. Click Add and create the access rule:

    Any protocol access to target hosts within that FQDN will be blocked, and the access attempt will be logged.

Using an Internal DNS Server for FQDN-based Access Rules

It is common for dynamically configured (DHCP) network environments to work in combination with internal DNS servers for the purposes of dynamically registering internal hosts – a common example of this is Microsoft’s DHCP and DNS services. Hosts on such networks can easily be configured to dynamically update DNS records on an appropriately configured DNS server (for example, see the Microsoft Knowledgebase article How to configure DNS dynamic updates in Windows Server 2003 at http://support.microsoft.com/kb/816592/en-us).

The following illustrates a packet dissection of a typical DNS dynamic update process, showing the dynamically configured host 10.50.165.249 registering its full hostname bohuymuth.moosifer.com with the (DHCP provided) DNS server 10.50.165.3.

In such environments, it could prove useful to employ FQDN AOs to control access by hostname. This would be most applicable in networks where hostnames are known, such as where hostname lists are maintained, or where a predictable naming convention is used.

Controlling a Dynamic Host’s Network Access by MAC Address

Since DHCP is far more common than static addressing in most networks, it is sometimes difficult to predict the IP address of dynamically configured hosts, particularly in the absence of dynamic DNS updates or reliable hostnames. In these situations, it is possible to use MAC address objects to control a host’s access by its relatively immutable MAC (hardware) address.

Like most other methods of access control, this can be employed either inclusively, for example, to deny access to/for a specific host or group of hosts, or exclusively, where only a specific host or group of hosts are granted access, and all other are denied. In this example, we will illustrate the latter.

Assuming you had a set of DHCP-enabled wireless clients running a proprietary operating system which precluded any type of user-level authentication, and that you wanted to only allow these clients to access an application-specific server (for example, 10.50.165.2) on your LAN. The WLAN segment is using WPA-PSK for security, and this set of clients should only have access to the 10.50.165.2 server, but to no other LAN resources. All other wireless clients should not be able to access the 10.50.165.2 server, but should have unrestricted access everywhere else.

Step 1 – Create the MAC Address Objects:
  1. Navigate to Objects > Addresses > Address Objects page.

  2. Click Add and create the following MAC address objects (multi-homing optional, as needed).

  3. Once created, if the hosts are present in the firewall’s ARP cache, they will be resolved immediately, otherwise they will appear in an unresolved state in the Address Objects table until they are activated and are discovered through ARP:

  4. Create an address group for the handheld devices:

Step 2 – Create the Access Rules:
  1. Navigate to Policies > Access Rules page.

  2. Click Add and create four access rules with the settings shown in the below table.

    Sample access rules
    Setting Access Rule 1 Access Rule 2 Access Rule 3 Access Rule 4
    Allow / Deny Allow Deny Allow Deny
    From Zone WLAN WLAN WLAN WLAN
    To Zone LAN LAN LAN LAN
    Service MediaMoose Services MediaMoose Services Any Any
    Source Handheld Devices Any Handheld Devices Any
    Destination 10.50.165.2 10.50.165.2 Any Any
    Users allowed All All All All
    Schedule Always on Always on Always on Always on

The MediaMoose Services service is used to represent the specific application used by the handheld devices. The declaration of a specific service is optional, as needed.

Bandwidth Managing Access to an Entire Domain

Streaming media is one of the most profligate consumers of network bandwidth. But trying to control access, or manage bandwidth allotted to these sites is difficult because most sites that serve streaming media tend to do so off of large server farms. Moreover, these sites frequently re-encode the media and deliver it over HTTP, making it even more difficult to classify and isolate. Manual management of lists of servers is a difficult task, but wildcard FQDN address objects can be used to simplify this effort.

Step 1 – Create the FQDN Address Objects:
  1. Navigate to Objects > Addresses > Address Objects page.

  2. Click Add and create the following address object.

    Upon initial creation, *.youtube.com resolves to IP addresses 208.65.153.240, 208.65.153.241, 208.65.153.242, but after an internal host begins to resolve hosts for all of the elements within the youtube.com domain, the learned host entries are added, such as the entry for the v87.youtube.com server (208.65.154.84).

Step 2 – Create the Bandwidth Object
  1. Navigate to Objects > Bandwidth page.

  2. Click Add and create the bandwidth object.

Step 3 – Create the Access Rule:
  1. Navigate to Policies > Access Rules page.

  2. Click Add and create the access rule:

    After the access rule is created, the Bandwidth Management icon appears within the Access Rule table, indicating that BWM is active and providing statistics. Move your mouse pointer over the icon to see the BWM settings.

    Access to all *.youtube.com hosts, using any protocol, is now be cumulatively limited to speed that you have set, a low percentage of your total available bandwidth for all user sessions.

Was This Article Helpful?

Help us to improve our support portal

Yes! Not Really

Techdocs Article Helpful form

  • Hidden
  • Hidden

Techdocs Article NOT Helpful form

  • Still can't find what you're looking for? Try our knowledge base or ask our community for more help.
  • Hidden
  • Hidden