Lesson Contents
IP Source Guard prevents IP and/or MAC address spoofing attacks on untrusted layer two interfaces.
When IP source guard is enabled, all traffic is blocked except for DHCP packets. Once the host gets an IP address through DHCP, only the DHCP-assigned source IP address is permitted. You can also configure a static binding instead of using DHCP.
Source guard is not a standalone tool. It relies on the information in the DHCP snooping database to do its work. You can only use this on layer two (access and trunk) interfaces and it only works inbound.
Configuration
Let’s see how we can configure IP source guard. I’ll use the following topology:
- H1 is a legitimate host that receives its IP address through DHCP.
- H2 is an attacker that tries to spoof its source IP address.
- S1 is a server with a static IP address.
- R1 assigns IP addresses through DHCP.
- SW1 is pre-configured with DHCP snooping. We will configure IP source guard on this switch.
- Configurations
- H1
- H2
- S1
- R1
- SW1
Configurations
Want to take a look for yourself? Here you will find the startup configuration of each device.
H1
H2
S1
R1
SW1
Let’s take a look at what we have. H1 receives an IP address through DHCP from R1:
H1#show ip interface brief | include DHCP
FastEthernet0/0 192.168.1.1 YES DHCP up up
We can see a binding in the DHCP snooping binding table:
SW1#show ip source binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:1D:A1:8B:36:D0 192.168.1.1 86316 dhcp-snooping 1 GigabitEthernet0/1
Total number of bindings: 1
This information is important. We need it to make IP source guard work.
DHCP Binding
Let’s configure IP Source guard. We’ll start with the interface that connects to H1. To enable this, you only need a single command:
SW1(config)#interface GigabitEthernet 0/1
SW1(config-if)#ip verify source
We can verify that it is enabled for the interface that connects to H1:
SW1#show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
--------- ----------- ----------- --------------- ----------------- ---- ---
Gi0/1 ip active 192.168.1.1 1 disabled
SW1 now only permits source IP address 192.168.1.1 on the GigabitEthernet 0/1 interface. The MAC address field is empty so right now, the switch only checks the source IP address. We can also check the source MAC address though. IP source guard uses port-security for this. Here’s how to enable it:
SW1(config)#interface GigabitEthernet 0/1
SW1(config-if)#switchport port-security
SW1(config-if)#ip verify source port-security
First, we enable port-security and then we add the port-security
parameter to our ip verify source
command. The MAC address now shows up in the table:
SW1#show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
--------- ----------- ----------- --------------- ----------------- ---- ---
Gi0/1 ip-mac active 192.168.1.1 00:1D:A1:8B:36:D0 1 disabled
SW1 now only permits the source IP address and source MAC address that we see in the table above. Let’s do a quick test, let’s see if H1 can still ping R1:
H1#ping 192.168.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
This is working, great. Let’s add the exact same commands on H2:
SW1(config)#interface GigabitEthernet 0/2
SW1(config-if)#switchport port-security
SW1(config-if)#ip verify source port-security
H2 has a static IP address. Let’s check the table on SW1 again:
SW1#show ip verify source
Interface Filter-type Filter-mode IP-address Mac-address Vlan Log
--------- ----------- ----------- --------------- ----------------- ---- ---
Gi0/1 ip-mac active 192.168.1.1 00:1D:A1:8B:36:D0 1 disabled
Gi0/2 ip-mac active deny-all deny-all 1
There is no known source IP and/or MAC address known on the GigabitEthernet 0/2 interface so SW1 will drop everything. Let’s see if this is true, we can see it in action with a debug:
SW1#debug ip verify source packet
Ip source guard debug packet debugging is on
Let’s send an IP packet from H2 to R1:
H2#ping 192.168.1.254 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.1.254, timeout is 2 seconds:
.
Success rate is 0 percent (0/1)
This ping fails and SW1 will show us the following output:
SW1#
DHCP_SECURITY_SW: validate port security packet, recv port: GigabitEthernet0/2, recv vlan: 1, mac: 0017.5aed.7af0, invalid flag: 1.
Great, this proves that IP source guard is working for us.
Static Binding
What about that server? It’s a legitimate device but it has a static IP address. Fortunately, we can create a static binding. Let’s check the MAC address of S1:
I configured the switch port for voice and data vlans. I was trying to use IP source guard for this port but it was failing. I can see the phone IP address in the DHCP binding table but the IP source guard was failing. I configured static binding for the IP phone and it was working.
Any suggestion to solve this issue without using the static binding ?
Hello Hind
In order for IP source guard to function with a voice VLAN, DHCP snooping must be enabled on that voice VLAN. Take a look at the following documentation from Cisco:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SY/configuration/guide/sy_swcg/ip_source_guard.html#78545
When you say IP Source Guard was failing, what do you mean exactly? If the issue was
... Continue reading in our forumHello Dongsok
When some features tend to work on some platforms and not others, there may always be an issue with the IOS, the platform being used, or just the fact that GNS3 may not be able to accurately reproduce the features. It’s difficult to determine this, unless you have real devices on which you can configure these features. Hopefully, after reviewing your config as well, you’ll be able to determine the reason for the topology not functioning correctly.
I hope this has been helpful!
Laz
Hi Laz,
When the voip phone comes up it will boot as vlan 10 (data vlan). the port is configured to authenticate via ISE server. ISE will notice the mac address is for VOIP phone and will change the vlan from vlan 10 (data vlan) to vlan 20 (voice vlan).
VOIP phones configured to use dhcp to get the IP address. I am able to see the voip ip address in the dhcp sooping binding but the phone ip address is no longer pingable.
I think IP source guard feature blocking the VOIP phone as its using 2 vlans for same MAC address.
Any idea how to fix this issue ?
Hello Dongsok,
in GNS3 you can test IPSG only with checking IP address. It does not work while you wanna check the source MAC address.
I tested this with VIRL vios_l2-adventerprisek9-m.03.2017.qcow2 image.