IP Source Guard: The Ultimate Defense Against Spoofed IPs

The Problem IP Source Guard Was Built to Solve

DHCP snooping stops rogue DHCP servers from handing out fraudulent addresses. Dynamic ARP Inspection (DAI) prevents ARP poisoning. But neither of those controls stops a determined insider from simply opening their network adapter settings and typing in a different IP address. A laptop plugged into Port 12 of your access switch was legitimately assigned 10.0.0.50 by DHCP. Nothing at the network level prevents that user from manually reconfiguring their adapter to 10.0.0.1—your router's address—and attempting to intercept traffic.

IP Source Guard (IPSG) closes that gap. It enforces a strict binding between a switch port, a MAC address, and an IP address. Traffic arriving on a port with a source IP that does not match the binding table for that port is dropped in hardware, before it reaches any routing or security logic upstream. The enforcement happens at line rate on the switch ASIC—there is no CPU overhead, no timeout, and no opportunity for a spoofed packet to slip through during a brief window.

How IP Source Guard Works: The Binding Table

IPSG does not maintain its own database. It reads the DHCP snooping binding table, which is built automatically as devices on trusted ports go through the DHCP discovery process. Each entry in the binding table records:

• The switch port number (e.g., GigabitEthernet0/12)
• The MAC address of the device on that port
• The IP address leased to that device
• The VLAN
• The lease expiry time

When IPSG is enabled on an untrusted port, the switch compares the source IP address (and optionally the source MAC address) of every incoming frame against the binding table entry for that port. If the source IP does not match, the frame is dropped. There are two enforcement levels:

1. IP-only filter: Checks only the source IP address against the binding table. A device can change its MAC address and still pass if the IP matches. This is the default mode on most platforms.
2. IP and MAC filter: Checks both source IP and source MAC. Any deviation in either field drops the packet. This is the more secure mode and should be used in high-security segments.

The Three-Component LAN Security Architecture

IPSG is the third layer of a complementary security stack designed for access-layer switches. Each layer addresses a different attack surface:

Deploying all three features together creates a network where:

• Devices cannot hand out false DHCP leases (DHCP snooping)
• Devices cannot poison ARP caches (DAI)
• Devices cannot use an IP address they were not assigned (IPSG)

These controls do not overlap—each addresses a distinct attack vector. A network with only one or two of the three remains vulnerable to the vector that the missing feature addresses.

Cisco IOS Configuration

IPSG is available on Cisco Catalyst access switches. The configuration requires DHCP snooping to be enabled globally and active on the relevant VLANs first:

ip dhcp snooping
ip dhcp snooping vlan 10

Then, on each untrusted access port where you want IPSG enforcement:

interface GigabitEthernet0/12
ip verify source

To enforce both IP and MAC:

ip verify source port-security

This command configures the port-security feature alongside IPSG. To verify the binding table and active IPSG bindings:

show ip dhcp snooping binding
show ip verify source

The second command shows the active IPSG entries per port, confirming which IP-MAC pairs are permitted on each interface.

Handling Static IP Addresses

IPSG relies on the DHCP snooping binding table, which only contains entries for devices that obtained addresses via DHCP. Devices with statically configured IP addresses—servers, printers, management interfaces—have no binding table entry and will be blocked by IPSG if it is enabled on their port.

The solution is to create static IPSG bindings that manually add the trusted IP-MAC-port combination to the binding table:

ip source binding 00:11:22:33:44:55 vlan 10 10.0.0.10 interface GigabitEthernet0/5

This tells the switch that the device on port GigabitEthernet0/5 with MAC 00:11:22:33:44:55 is legitimately using IP 10.0.0.10. Forgetting to create static bindings for servers and infrastructure devices is the most common operational mistake when deploying IPSG.

Real-World Use Cases

Insider threat mitigation: A disgruntled employee changes their laptop's IP to match the HR database server's address in an attempt to intercept traffic. IPSG on the access switch drops all frames from that laptop with the spoofed source IP. The attack is blocked before any traffic reaches Layer 3.

Healthcare and finance network segmentation: Regulatory frameworks require that devices in sensitive network segments cannot impersonate authorized infrastructure. IPSG provides auditable hardware-level enforcement that satisfies compliance requirements for networks handling protected health information (PHI) or financial data.

Guest and contractor networks: Guest Wi-Fi and contractor VLANs are high-risk segments because the devices on them are unmanaged. IPSG ensures that even if a contractor's laptop is compromised and tries to spoof an internal IP, the switch drops the traffic silently.

IoT device isolation: Industrial IoT devices and building management systems often have predictable IP addresses and weak operating systems. Binding each device to its specific port and IP via IPSG means a compromised IoT device cannot be used to impersonate other devices on the network.

Common Misconceptions

IPSG stops all types of IP spoofing

IPSG prevents spoofing within the Layer 2 broadcast domain—on the same switched segment. It does not protect against spoofing that originates outside the local network. For external spoofing protection, ISPs implement BCP38 (RFC 2827) ingress filtering at their network edges. IPSG and BCP38 address the same attack from different vantage points and are complementary, not redundant.

Enabling IPSG on uplinks and trunk ports is safe

IPSG should only be enabled on untrusted access ports where end devices connect. Never enable it on uplink ports to distribution switches, trunk ports carrying inter-VLAN traffic, or ports connecting to routers. Traffic on those ports legitimately carries many source IP addresses, and IPSG would silently drop all of them. Most platforms prevent this by design, but misconfiguration on non-Cisco hardware remains a risk.

IPSG eliminates the need for firewall rules

IPSG enforces source address legitimacy at Layer 2 within the LAN. It does not inspect traffic contents, does not apply application-layer policies, and does not control traffic between VLANs or to/from external networks. Firewalls remain essential for enforcing access policies between network segments and to the internet.

If DHCP snooping is working, IPSG provides no additional security

DHCP snooping builds the binding table and prevents rogue DHCP servers, but it does not validate source addresses on data packets. A user can still manually configure an IP address that happens to be unoccupied in the subnet and send traffic under that address. IPSG is the specific control that prevents this.

Pro Tips for IPSG Deployment

• Always inventory static-IP devices before enabling IPSG. Build a complete list of servers, printers, IP phones, and infrastructure equipment with static addresses and create their binding table entries before enabling IPSG on their ports. Discovering the gaps after deployment means service outages.
• Enable DHCP snooping first and observe for at least 24 hours. Let the binding table populate fully through normal DHCP activity before enabling IPSG. Enabling IPSG on an empty binding table blocks all traffic from all devices.
• Use the IP and MAC filter mode in high-security segments. IP-only mode allows MAC address spoofing as long as the IP matches. In environments with strict security requirements, the combined IP and MAC check eliminates this residual risk.
• Log IPSG violations to a SIEM. When IPSG drops a frame, most Cisco platforms can generate a syslog message identifying the port, the rejected source IP, and the timestamp. These events are valuable security data. Configure your SIEM to alert on clusters of IPSG violations from a single port.
• Test in a lab with representative traffic types before production deployment. IPSG drops packets silently—there is no rejection message sent to the affected device. Silent failures are difficult to debug under production pressure. A lab test reveals static binding gaps and unexpected traffic sources before they cause incidents.
• Document your binding table alongside your IPAM records. The DHCP snooping binding table is dynamic and rebuilt after switch reboots (unless persistency is configured). Maintain an authoritative record of all static bindings in your IPAM documentation so they can be recreated quickly after a switch replacement.

IP Source Guard is the hardware-level answer to the IP spoofing problem that exists at the access layer of every enterprise network. Combined with DHCP snooping and Dynamic ARP Inspection, it closes the three fundamental attack vectors that an insider with physical network access can exploit. Check whether your IP is being spoofed or impersonated here.