[IGS-10020PT (V4)] Why do all my hosts lose connectivity after I enable IP Source Guard on C, and how do I configure it correctly? - FAQ

What IP Source Guard does:

IP Source Guard (IPSG) is a security feature that blocks any IP traffic whose (port, VLAN, IP, MAC) does not match a trusted binding. On IGS-10020PT, these bindings come from:

1. DHCP Snooping Table (dynamic entries learned from DHCP traffic):

2. Static IP Source Guard entries that you configure manually.

Effectively:

If a client got its IP via DHCP on an untrusted port → IPSG learns <port, VLAN, IP, MAC> and allows only traffic that matches this binding.
If a client tries to spoof another host’s IP (change the source IP in packets) → packets no longer match its binding and are dropped at ingress.

This is designed to stop IP spoofing, especially when you use IP-based ACLs as your main access control method.

Q1. Why all hosts lose connectivity after IP Source Guard is enabled:

A. IPSG is very strict. If it does not find a valid binding, it will drop all IP packets on that port.

Common reasons everything suddenly goes down:

1. DHCP Snooping is not correctly configured

DHCP Snooping table is empty → IPSG has no bindings → all IP packets from untrusted ports are dropped.
If your DHCP or ARP settings are wrong, IPSG will install a default deny ACE without any valid per-host permit entries, causing complete loss of IP connectivity.

2. Clients are using static IP addresses

IPSG can’t learn static IP addresses from DHCP.
If you don’t create static IPSG bindings for those hosts → their IP packets are all dropped.

3. Max Dynamic Clients = 0 on the port

On the IP Source Guard Configuration page, if a port is Enabled but “Max Dynamic Clients” is set to 0, the port will only allow traffic that matches static entries.
All DHCP clients on that port will be blocked until you either:
- increase Max Dynamic Clients, or
- create matching static IP Source Guard entries.

Example Topology:

Topology:

PC1 – DHCP client, gets IP 192.168.10.100/24, on Port 7.
PC2 – DHCP client, gets IP 192.168.10.102/24, on Port 6.
DHCP Server / default gateway – 192.168.10.254/24, pool 192.168.10.100–192.168.10.150, connected to Port 8
All in VLAN 1(for example).

Pre-configured:

DHCP Snooping: enabled globally, all ports untrusted except Port 8 (DHCP server).
ARP Inspection: enabled globally, all ports untrusted except Port 8.

Access list:

This ACL means:

ICMP to 192.168.10.254 is denied by default (ACE 2),
except from 192.168.10.100 (PC1), which is permitted by ACE 1.

Test connectivity

PC1 ping 192.168.10.254: should succeed (allowed by ACE 1).
PC2 ping 192.168.10.254: should be blocked by ACE 2 (no ACL permit for 192.168.10.102).

Bypass IP-based ACL by spoofing PC1’s IP:

A. Let’s look at what happened before IPSG was enabled:

ACL logic:
- ACE 1: allow ICMP from 192.168.10.100 to gateway .254
- ACE 2: deny all other ICMP to .254
During the test:

1. Normal behavior (no spoofing):

PC1 (192.168.10.103) → ping .254 → ACE 1 matches, allowed → counter of ACE 1 = 5 (for 5 pings).
PC2 (192.168.10.105) → ping .254 → ACE 1 does not match, ACE 2 matches → counter of ACE 2 = 5, all packets denied.

2. Spoofing with Scapy on PC2:

PC2 crafts ping with source IP set to 192.168.10.100.

Switch sees a packet with:
- Source IP = 192.168.10.100.
- Destination IP = 192.168.10.254.
ACL has no knowledge of which physical port the packet came from. It just sees IP addresses.
So the packet matches ACE 1, is permitted, and reaches the gateway.

　　　→ ACE 1 counter increases from 5 to 10 (5 from PC1 + 5 from spoofed PC2 pings).

Result: PC2 successfully pretended to be PC1 and bypassed your IP-based ACL. ACL alone cannot stop this; it does not verify that the IP belongs to the MAC/port that originally got it.

Enable IP Source Guard and block spoofed ping from PC2:

1. Verify DHCP Snooping and ARP Inspection are working

Confirm that both PC1 and PC2 obtain DHCP addresses normally.
Check the DHCP Snooping table – you should see:
- Port 7 → IP 192.168.10.100, MAC of PC1
- Port 6 → IP 192.168.10.102, MAC of PC2

Check Dynamic ARP Inspection table; it should be consistent with DHCP snooping.

2. Enable Global IP Source Guard

Set Global Mode: Enable.

3. Enable IP Source Guard on the client ports

Still in IP Source Guard Configuration:
- Port 6 (PC2): Mode: Enable, Max Dynamic Clients: 1.
- Port 7 (PC1): Mode: Enable, Max Dynamic Clients: 1.
- Port 8 (DHCP server / router): usually disabled for IPSG (it’s a trusted uplink, not an end host).
Apply and save.

4. Verify the Dynamic IP Source Guard Table

You should see entries similar to below:
- Port 7, VLAN 1, IP 192.168.10.100, MAC = PC1 MAC
- Port 6, VLAN 1, IP 192.168.10.102, MAC = PC2 MAC

Now IPSG is correctly configured and does not break normal communication, but it will stop IP spoofing attempts.

Once IPSG is enabled and DHCP Snooping has built the bindings, the switch automatically creates hidden ACEs that look like:

ipSourceGuard ACE 11 permit source IP 192.168.10.102 (for PC2)
ipSourceGuard ACE 14 permit source IP 192.168.10.100 (for PC1)
ipSourceGuard ACE 1 deny all (default deny)

The important part is that these permit ACEs are tied to specific ports and MACs, not just IP.

Now consider spoofing test again:

1. PC2 (on Port 5) sends packets with:

Source IP = 192.168.10.100
Source MAC = PC2’s MAC (different from PC1’s MAC)
Port = 5

2. IP Source Guard checks:

Does Port 5 have a binding for IP 192.168.10.100 and PC2’s MAC?

→ No, Port 5 is bound to IP 192.168.10.102.

3. So the packet matches ipSourceGuard ACE 1 deny all.

Observation: counter for ipSourceGuard ACE 1 increased to 5.

Packets are dropped before they even reach the user ACL.

Result: IP Source Guard prevents PC2 from using PC1’s IP, even though your IP-based ACL would otherwise have allowed those packets.

Q2. Does IP Source Guard replace DHCP Snooping, ARP Inspection, or ACLs?

A. No – they work together:

DHCP Snooping – builds the trusted IP–MAC–VLAN–port bindings.
IP Source Guard – uses those bindings to block IP spoofing at Layer 3.
ARP Inspection – uses the same bindings to block ARP spoofing at Layer 2.
ACLs – implement your actual policy (“who can talk to what”), but are vulnerable to spoofing if used alone.

A good rule of thumb for access networks:

DHCP Snooping + ARP Inspection + IP Source Guard + IP-based ACLs gives you both strong identity (per IP/MAC/port) and flexible policy control.