Using MAC and FQDN Dynamic Address Objects

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.

Create the FQDN Address Object. From Network > Address Objects, select Add and create the following Address Object.

When first created, this entry will resolve only to the address for dyndns.org, for example,, 63.208.196.110.

Create the Firewall Access Rule. From the Firewall > Access Rules page, LAN->WAN zone intersection, Add an Access Rule as follows:

NOTE: Rather than specifying ‘LAN Subnets’ as the source, a more specific source could be specified, as appropriate, so that only certain hosts are denied access to the targets.

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.

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 https://support.microsoft.com/en-us/help/816592/how-to-configure-dns-dynamic-updates-in-windows-server-2003).

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.

Create the MAC Address Objects. From Network > Address Objects, select Add and create the following Address Object (multi-homing optional, as needed).

Once created, if the hosts are present in the SonicWall’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:

Create an Address Object Group comprising the Handheld devices:

Create the Firewall Access Rules:

Navigate to the Firewall > Access Rules page, click on the All Rules radio button, scroll to the bottom of the page, and then click the Add button.

Create the following four access rules:

Firewall access rules
Setting	Access Rule 1	Access Rule 2	Access Rule 3	Access Rule 4
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.3	10.50.165.3	Any	Any
Users allowed	All	All	All	All
Schedule	Always on	Always on	Always on	Always on

NOTE: 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.

Create the FQDN Address Object. From Network > Address Objects, select Add and create the following Address Object:

Upon initial creation, youtube.com will resolve 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 will be added, such as the entry for the v87.youtube.com server (208.65.154.84).

Create the Firewall Access Rule. From the Firewall > Access Rules page, LAN->WAN zone intersection, add an Access Rule as follows:

NOTE: If you do not see the Bandwidth tab, you can enable bandwidth management by declaring the bandwidth on your WAN interfaces. For more information on BWM, refer to Bandwidth Management Overview.

The BWM icon will appear within the Access Rule table indicating that BWM is active, and providing statistics. Access to all *.youtube.com hosts, using any protocol, will now be cumulatively limited to 2% of your total available bandwidth for all user sessions.