Home

Enhancing Network Security with FortiGate MAC Address-Based Policies

.

In today's evolving network security landscape, controlling device-level access has become increasingly critical. While IP addresses remain fundamental to network communication, they can be dynamically assigned and sometimes spoofed, creating potential security gaps. Fortinet FortiGate firewalls address this challenge through a powerful feature: MAC address-based policies. This capability allows network administrators to create security rules based on the unique, hardware-burned Media Access Control (MAC) address of each device, providing a more stable and hardware-specific layer of identification and control.

This approach is particularly valuable for managing bring-your-own-device (BYOD) environments, securing IoT devices with static behaviors, and enforcing granular access controls in sensitive network segments. By tying policies to the physical device itself, organizations can achieve a more robust security posture. This article explores the functionality, configuration, and practical applications of MAC-based policies within the FortiGate ecosystem, drawing from official documentation and real-world implementation guides.

Understanding MAC Address-Based Policies

A MAC address is a unique identifier assigned to a network interface controller (NIC) at the time of manufacture. Unlike IP addresses, which can change or be replicated, the MAC address is typically fixed to the hardware. FortiGate firewalls leverage this characteristic to create firewall policies that trigger based on the source or destination MAC address of network traffic.

According to Fortinet's administration guides, MAC addresses are a link layer-based address type. A crucial technical limitation is that a MAC address cannot be forwarded across different IP subnets. This means MAC-based policies are most effective within the same local broadcast domain, such as within a specific VLAN or behind the same layer-2 interface on the FortiGate.

These policies can be applied to several IPv4 policy types within FortiOS:

  • IPv4 Firewall Policy
  • IPv4 Virtual Wire Pair Policy
  • IPv4 ACL Policy
  • IPv4 Central SNAT Policy
  • IPv4 Denial-of-Service (DoS) Policy

The operational mode of the FortiGate Virtual Domain (VDOM) significantly impacts how MAC addresses can be used in a policy:

  • In NAT Mode VDOMs: The MAC address type is supported only as a source address. It cannot be defined as a destination address. Importantly, when used as a source, standard Network Address Translation (NAT) rules defined in the policy are still executed. The MAC address matching is solely for traffic identification and does not influence NAT behavior.
  • In Transparent Mode or Virtual Wire Pair Interfaces: Administrators have greater flexibility. The MAC address type can be used as both a source and a destination address within policies. This mode is ideal for inserting the FortiGate into an existing network segment without re-addressing.

Configuring MAC Address Objects and Policies

Creating a MAC-based policy is a two-step process: first, define the MAC address as an address object, then reference that object within a firewall policy.

Using the Graphical User Interface (GUI)

  1. Create the MAC Address Object:

    • Navigate to Policy & Objects > Addresses and click Create New.
    • Enter a descriptive name for the object (e.g., CEO-Laptop-MAC).
    • Set Category to Address.
    • Set Type to Device (MAC Address) in newer versions (FortiOS 7.6) or MAC Address Range in earlier versions.
    • Input the singular MAC address (e.g., 00:0C:29:41:98:88) or define a range.
    • Click OK.

  2. Create the Firewall Policy:

    • Go to Policy & Objects > IPv4 Policy (or Firewall Policy).
    • Create a new policy or edit an existing one.
    • In the Source field, add the MAC address object you created. You can mix it with other IP-based address objects.
    • Configure the destination, schedule, service, and action (Accept/Deny) as required.
    • Remember: In NAT mode, the MAC object can only be a source. In Transparent mode, it can be either source or destination.

Using the Command Line Interface (CLI)

The CLI offers precise control. The following example creates a MAC address object and applies it in a policy.

config firewall address     edit "CEO-Laptop-MAC"         set type mac         set macaddr 00:0c:29:41:98:88         # For a range, use: set start-mac <start> set end-mac <end>     next end  config firewall policy     edit 1         set srcintf "internal-port"         set dstintf "wan-port"         set srcaddr "CEO-Laptop-MAC"  # MAC object as source         set dstaddr "all"         set action accept         set schedule "always"         set service "ALL"         set nat enable     next end

Advanced Feature: Dynamic Device & OS Identification

FortiOS 7.6 introduces a sophisticated evolution of MAC-based control: the Device & OS Identification dynamic address subtype. This feature moves beyond static MAC lists to create policy objects based on device characteristics.

  • How It Works: It relies on the FortiGate's device detection capabilities on the user-facing interface. The firewall inspects traffic to identify the hardware vendor, model, operating system, and version.
  • Dynamic Policy Objects: Administrators can create an address object that dynamically includes devices matching specific criteria (e.g., "All Apple iPhones," "Windows 10 laptops from Dell"). The FortiGate automatically updates the members of this address group as devices are detected on the network.
  • Usage: Similar to static MAC objects, this dynamic subtype can be used as a source address in firewall, proxy, and ZTNA rules. It offers a scalable way to apply policies to classes of devices without manually tracking each MAC address.

To enable this feature, navigate to System > Feature Visibility and enable Dynamic Device & OS Identification.

Practical Application: Securing Unmanaged Switches

A common and powerful use case for MAC binding, as highlighted in a practical guide, is securing networks that extend through unmanaged switches. Unmanaged switches are simple, plug-and-play devices that lack any security features, making them a potential backdoor for unauthorized devices.

The guide outlines a method to enforce control at the upstream FortiGate:

  1. Network Topology: The setup is FortiGate → Managed Switch → Access Point (AP) → Unmanaged Switch → End-user Devices.
  2. Disable Rogue DHCP: Ensure the DHCP server is disabled on the Access Point, forcing all devices to obtain an IP address from the FortiGate.
  3. Enable MAC Binding on FortiGate DHCP: Configure the FortiGate's DHCP server to perform MAC binding (also called "reserved" or "static" DHCP). This ties a specific IP address to a specific MAC address permanently.
  4. Create Restrictive Firewall Policies: Craft policies that explicitly allow traffic only from the MAC addresses (or the IPs bound to them) of authorized devices. A final explicit "DENY ALL" policy blocks any device not on the whitelist.

This approach effectively uses the FortiGate as a security gateway, applying strong access control at the network edge and neutralizing the security risk posed by the unmanaged switch.

Key Takeaways and Conclusion

FortiGate's MAC address-based policies provide a vital layer of device-centric security that complements traditional IP-based rules. They are indispensable for scenarios requiring strict device identification, such as compliance adherence, IoT network segmentation, and securing environments with unmanaged infrastructure.

The key points to remember are:

  • MAC policies are ideal for layer-2 access control within the same subnet.
  • Their application differs between NAT and Transparent firewall modes.
  • The feature has evolved from static MAC entries to dynamic device identification based on hardware and OS fingerprints.
  • When combined with DHCP MAC binding, they form a robust defense for securing otherwise vulnerable network extensions.

By integrating this capability into a broader network security strategy, administrators can significantly reduce the attack surface and gain finer control over exactly what can communicate on their networks.

Frequently Asked Questions (FAQ)

Q: Can MAC address spoofing defeat these policies? A: Yes, a technically sophisticated attacker can spoof (imitate) the MAC address of an authorized device. Therefore, MAC-based policies should be considered one part of a defense-in-depth strategy, not a standalone security solution. Combining them with 802.1X authentication or certificate-based access provides much stronger security.

Q: Are MAC address-based policies suitable for large, dynamic networks with thousands of devices? A: Managing thousands of static MAC address objects can become an administrative burden. For large-scale deployments, the Dynamic Device & OS Identification feature is more scalable. Alternatively, using MAC-based policies for a limited set of critical devices (servers, network infrastructure, executive equipment) while relying on other methods like user authentication for general users is a common practice.

Q: How do I find the MAC addresses of the devices I want to control? A: The FortiGate can help discover them. You can check the DHCP lease list (under System > Network > DHCP Server) if devices get IPs from the FortiGate. The ARP Table (Network > ARP) also shows the MAC addresses of devices communicating through the firewall. Most end-user devices also display their own MAC address in their network settings menu.

Q: What happens if I replace the network card in an authorized device? A: The device will receive a new, different MAC address. The old MAC-based policy will no longer apply to it, and it will likely be blocked if using a whitelist approach. The device would need to be re-authorized by adding its new MAC address to the FortiGate's address objects and policies. This is an important consideration for maintenance and support.

Q: Can I use MAC address objects in Security Profiles or VPN policies? A: No. According to the documentation, MAC address objects are specifically for use in the IPv4 policy types listed earlier (Firewall, Virtual Wire Pair, ACL, etc.). They are not applicable for use in IPS, Antivirus, or SSL-VPN/IPSEC VPN configurations, which operate at different layers of the network stack.