What is IP Source Guard?

IP Source Guard (IPSG) is a security feature of managed switches that only forwards IP traffic on an access port when the source IP address matches a known binding of IP address, port and VLAN, so a connected device cannot use a forged source address. The bindings come from DHCP Snooping or are entered manually as static bindings. IPSG therefore blocks IP Spoofing at exactly the point where traffic enters the network.

In OT environments, IP Source Guard helps protect critical communication, such as between a PLC and SCADA, against traffic from a device pretending to be another system.


🧠 Why is IP Source Guard needed?

Many industrial protocols, such as Modbus TCP, have no authentication: at most a device or firewall filters on the source IP address. A PLC that receives a write command from the address of the engineering workstation or the SCADA server often executes it without any further check. Anyone who can forge that address can inject commands or disrupt a session. IP Source Guard addresses this:

  • Prevents IP Spoofing - a device cannot send packets carrying the IP address of another system
  • Improves the integrity of network traffic - only sources with a valid binding are forwarded
  • Makes attacks harder - a Man-In-The-Middle or a Rogue Device cannot quietly pose as an existing device
  • Works per switch port - the check happens at the edge of the network, before traffic reaches a router or firewall
  • Fits Zero Trust and defence in depth - the network does not simply trust a source address but checks it against a known binding

πŸ”§ How does IP Source Guard work?

IPSG follows a fixed sequence. As soon as the feature is enabled on a port, the switch first blocks all IP traffic there except DHCP messages. Only once a valid binding exists is traffic from that address forwarded.

Step What happens?
1. DHCP Snooping listens in The switch reads DHCP traffic on untrusted ports and builds a binding table with MAC address, IP address, lease, VLAN and port
2. Add static bindings For devices with a fixed IP address, the administrator enters the binding manually
3. Install the filter The switch installs an implicit port ACL in hardware per port that only permits the bound source addresses
4. Check incoming traffic Every IP packet entering the port is compared with the binding; non-matching packets are dropped
5. Keep it up to date When a lease expires or a binding is removed, the permission disappears as well

IPSG thus checks incoming traffic on a Layer 2 port. There are two modes:

  • Source IP only - the default mode; the IP address must match the port and VLAN
  • Source IP and source MAC - optional (on Cisco ip verify source mac-check or combined with Port Security); the MAC address must then match as well

You enable IPSG on untrusted access ports where end devices are connected. Trusted ports, such as the uplink towards the DHCP server or another switch, are left unfiltered.


IP Source Guard is one building block in a set of complementary Layer 2 protections. They often share the same binding table but protect against different attacks.

Technique Protects against Based on
IP Source Guard IP spoofing Source IP (optionally also MAC) ↔ port ↔ VLAN
Dynamic ARP Inspection (DAI) ARP Spoofing ARP messages checked against the DHCP binding
Port Security Unknown devices or too many devices Permitted MAC addresses per port
MAC Binding MAC spoofing Fixed MAC ↔ port linkage
802.1X Unauthenticated devices Authentication via a RADIUS server
DHCP Snooping Rogue DHCP servers Trusted and untrusted ports

The key distinction: DAI checks ARP traffic, IPSG checks IP traffic. An attacker who uses ARP spoofing to redirect traffic is stopped by DAI; an attacker who sends a Modbus command from a forged source address is stopped by IPSG.


🏭 How do you deploy IP Source Guard in OT networks?

In an office network almost every device obtains its address via DHCP, so DHCP Snooping fills the bindings automatically. OT is different: PLCs, HMIs, variable frequency drives and I/O stations usually have a fixed IP address. ProfiNET devices also receive their name and address via the DCP protocol of the IO controller, not via DHCP. Without static bindings, IPSG therefore blocks these devices completely.

A practical approach in five steps:

  1. Take inventory - record per port which device is connected with which IP and MAC address and in which VLAN; an up-to-date asset inventory is the foundation here
  2. Enable DHCP Snooping on the relevant VLANs and mark only uplinks and DHCP server ports as trusted
  3. Enter static bindings for every device with a fixed address, for example ip source binding <mac> vlan <id> <ip> interface <port>
  4. Enable IPSG on a test port first and verify with show ip verify source and show ip source binding that the filter is active
  5. Roll out in phases during a maintenance window, with a fallback plan in case a device is blocked unintentionally

Typical points of attention in practice:

Point of attention Consequence Measure
Replacing a PLC or I/O card New MAC address, traffic blocked when MAC checking is on Update the binding through change management
Switch reboot DHCP bindings are lost without storage Store the DHCP Snooping database on flash or a server
Unmanaged switch behind a port Several devices on one port One binding per device, or replace the unmanaged switch
Limited hardware resources Filters share the ACL hardware (TCAM) Check the capacity of each switch model
Trunk and aggregated ports Support differs per platform Consult the documentation of the switch model

When a switch reboots without stored DHCP bindings, DHCP clients can only communicate again after renewing their lease. In a production environment that is an availability risk. Static bindings are part of the configuration and do not have this problem.

Many industrial switches and managed switches support IPSG or a comparable feature, sometimes under a different name. Vendors such as Cisco (including its industrial IE series), Juniper and Extreme Networks use the term IP Source Guard; HPE Aruba calls a comparable feature Dynamic IP Lockdown.

A concrete example: someone plugs a laptop into a spare port in a cabinet and gives it the PLC’s IP address in order to send commands. The binding for that address belongs to the port of the real PLC, so IPSG drops the laptop’s traffic right at the access port. For the same reason, a device accidentally connected to the wrong port gets no IP connectivity until the binding is updated.


πŸ” What are the limitations of IP Source Guard?

IP Source Guard is effective, but it does not protect against everything:

  • No protection against a compromised device - a device with a valid binding can still send malicious traffic from its own address
  • MAC spoofing in the default mode - without MAC checking, IPSG only looks at the IP address
  • No content inspection - IPSG looks at the source address, not at what a packet does; that requires a firewall or IDS
  • Only on the access port - traffic entering the switch through a trusted port is not filtered
  • IPv6 - requires separate features, such as IPv6 Source Guard, based on the IETF framework SAVI (Source Address Validation Improvement, RFC 7039 from 2013)

Combine IPSG therefore with network segmentation into zones and conduits according to IEC 62443, with DAI and Port Security, and have blocked attempts recorded centrally in a SIEM, as far as the switch platform supports it. Not every switch logs IPSG drops by default; on some Catalyst switches, for example, Cisco offers smart logging to a NetFlow collector. An IPSG alert on a port in a zone with controllers is a strong signal that something is wrong.


❓ Frequently asked questions

Does IP Source Guard work without DHCP?

Yes, IP Source Guard also works without DHCP if you enter static bindings. Each binding ties an IP address and MAC address to a VLAN and switch port. In OT networks with fixed IP addresses, this is the usual way to apply IPSG.

What is the difference between IP Source Guard and Dynamic ARP Inspection?

IP Source Guard checks the source address of IP packets, whereas Dynamic ARP Inspection checks ARP messages. Both use the same DHCP Snooping binding table. Together they prevent both IP spoofing and ARP spoofing on the same port.

Does IP Source Guard also block MAC spoofing?

By default, IP Source Guard only filters on the source IP address. With the optional MAC check, on Cisco mac-check or combined with Port Security, the source MAC address must match as well. Without that option, a device can change its MAC address as long as the IP address is correct.

What happens to IP Source Guard when the switch reboots?

Static bindings are stored in the configuration and survive a reboot. Dynamic bindings from DHCP Snooping are lost unless the switch stores them in a DHCP Snooping database on flash or a server. Without that storage, DHCP clients remain blocked until they renew their lease.

Can IP Source Guard disrupt an OT process?

Yes, a misconfigured IP Source Guard can block legitimate devices such as PLCs. This mainly happens when static bindings are missing or after hardware has been replaced with a new MAC address. Test on a single port first, therefore, and record bindings in the change management process.

Does IP Source Guard also work for IPv6?

Classic IP Source Guard filters IPv4 traffic. For IPv6 there are separate features, such as IPv6 Source Guard, based on the IETF SAVI framework. IPv6 still plays a minor role in most OT networks, but it is worth checking whether it is active on the switch.


πŸ“Œ In summary

IP Source Guard only forwards IP traffic on a switch port from source addresses with a valid binding, blocking IP Spoofing right at the edge of the network. In OT networks with fixed IP addresses it requires static bindings and sound change management. Combined with DHCP Snooping, DAI, Port Security and segmentation according to IEC 62443, it makes a zone containing PLCs and HMIs considerably harder to attack.