Lesson Contents
Router advertisements can be used by hosts to automatically configure their own IPv6 address and set a default route using the information they see in the RA. In the IPv6 router advertisement preference lesson, I explained how IPv6 hosts behave when they receive multiple router advertisements.
Hosts automatically select a router advertisement and they don’t care where it came from. This is how it was meant to be but it does introduce a security risk since any device can send router advertisements and your hosts will happily accept it. An attacker can send rogue router advertisements to redirect the traffic, or you can send so many RAs that it causes a DOS since your hosts will be too busy configuring their IPv6 prefixes.
The IPv6 RA guard feature can filter router advertisements and runs on switches. This can be as simple as “don’t allow RAs on this interface” or complex with policies where router advertisements are only permitted when it matches certain criteria.
In this lesson, I’ll show you how to use the IPV6 RA guard feature to block a malicious host and how to use a policy to permit router advertisements from a legitimate router, but only when it matches certain criteria.
Configuration
Here is the topology we’ll use:
R1 is our legitimate router that will send RAs. H1 is some IPv6 host that autoconfigures itself with SLAAC, H2 is our attacker who is going to send rogue router advertisements.
Let’s configure R1 so that it sends router advertisements. To do that, we need to enable unicast routing:
R1(config)#ipv6 unicast-routing
And we’ll configure an IPv6 address so that it includes a prefix in the RAs:
R1(config)#interface GigabitEthernet0/1
R1(config-if)#ipv6 address 2001:DB8:0:1::1/64
Our host is going to use SLAAC and sets a default route to the router:
H1(config)#interface GigabitEthernet 0/1
H1(config-if)#ipv6 address autoconfig default
Host Policy
Let’s see how our host reacts to the router advertisement from R1:
H1#show ipv6 routers
Router FE80::211:21FF:FE4E:D1C1 on GigabitEthernet0/1, last update 0 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:0:1::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
H1 receives the RA. Let’s see if it uses this router as its default gateway:
H1#show ipv6 route static
S ::/0 [2/0]
via FE80::211:21FF:FE4E:D1C1, GigabitEthernet0/1
Above, we see the default route that points to R1. Let’s see what happens when we try to mess around with this.
Let’s configure H2 so that it also sends RAs and to make it interesting, I’ll set the router preference to high:
H2(config)#ipv6 unicast-routing
H2(config)#interface GigabitEthernet 0/1
H2(config-if)#ipv6 address 2001:DB8:BAD:BAD::2/64
H2(config-if)#ipv6 nd router-preference high
Here’s what we see on R1:
H1#show ipv6 routers
Router FE80::211:21FF:FE4E:D1C1 on GigabitEthernet0/1, last update 0 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:0:1::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Router FE80::211:BBFF:FE0B:3641 on GigabitEthernet0/1, last update 2 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
HomeAgentFlag=0, Preference=High
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:BAD:BAD::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
H1 sees the RA, autoconfigures an IPv6 address with the 2001:DB8:BAD:BAD::/64 prefix and also uses H2 as a default route:
H1#show ipv6 route static
S ::/0 [2/0]
via FE80::211:BBFF:FE0B:3641, GigabitEthernet0/1
That’s pretty bad…H2 just hijacked all outgoing traffic from H1.
Let’s prevent this from happening. On my switch, I’ll create a new RA guard policy called hosts where the device role is “host”:
SW1(config)#ipv6 nd raguard policy HOSTS
SW1(config-nd-raguard)#device-role host
With the host device role, all RAs and router redirect messages will be blocked. We need to enable this policy on the interface:
SW1(config)#interface GigabitEthernet 0/2
SW1(config-if)#ipv6 nd raguard attach-policy HOSTS
Here’s how you can verify which policies you have activated on what interfaces:
SW1#show ipv6 nd raguard policy HOSTS
Policy HOSTS configuration:
device-role host
Policy HOSTS is applied on the following targets:
Target Type Policy Feature Target range
Gi0/2 PORT HOSTS RA guard vlan all
Let’s see it in action though. We’ll enable a debug on H2 so we can see when it sends a router advertisement:
H2#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on
And on the switch we’ll enable RA guard debugging:
SW1#debug ipv6 snooping raguard
IPv6 snooping - RA guard debugging is on
After a few seconds, we’ll see that H2 sends a router advertisement:
H2#
ICMPv6-ND: Sending RA from FE80::211:BBFF:FE0B:3641 to FF02::1 on GigabitEthernet0/1
ICMPv6-ND: MTU = 1504
ICMPv6-ND: prefix = 2001:DB8:BAD:BAD::/64 onlink autoconfig
ICMPv6-ND: 2592000/604800 (valid/preferred)
Our switch will block this RA:
SW1#
SISF[RAG]: Gi0/2 vlan 123 RA Guard setting sec level to GUARD
SISF[RAG]: Gi0/2 vlan 123 RA received by RA guard on Gi0/2 from FE80::211:BBFF:FE0B:3641
SISF[RAG]: Gi0/2 vlan 123 option 1 : ND_OPT_SOURCE_LINKADDR
SISF[RAG]: Gi0/2 vlan 123 option 3 : ND_OPT_PREFIX_INFORMATION
SISF[RAG]: Gi0/2 vlan 123 option 5 : ND_OPT_MTU
SISF[RAG]: Gi0/2 vlan 123 !Not a router port: all router messages disallowed
SISF[RAG]: Gi0/2 vlan 123 ! DROP ROUTER-ADVERT src FE80::211:BBFF:FE0B:3641 dst FF02::1 reason = 3
The debug output is nice and clean. Since this is not a router port, all router advertisements are dropped. Besides the debug command, there is also a show command that tells you the number of drops:
SW1#show ipv6 snooping counters interface GigabitEthernet 0/2
Received messages on Gi0/2:
Protocol Protocol message
NDP RA[3]
DHCPv6
Bridged messages from Gi0/2:
Protocol Protocol message
NDP
DHCPv6
Dropped messages on Gi0/2:
Feature Protocol Msg [Total dropped]
RA guard NDP RA [3]
reason: Message unauthorized on port [3]
This is a good feature to block rogue RAs. I should have implemented this before H1 received the first RA though:
H1#show ipv6 routers
Router FE80::211:21FF:FE4E:D1C1 on GigabitEthernet0/1, last update 0 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
HomeAgentFlag=0, Preference=Medium
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:0:1::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
Router FE80::211:BBFF:FE0B:3641 on GigabitEthernet0/1, last update 8 min
Hops 64, Lifetime 1800 sec, AddrFlag=0, OtherFlag=0, MTU=1504
HomeAgentFlag=0, Preference=High
Reachable time 0 (unspecified), Retransmit time 0 (unspecified)
Prefix 2001:DB8:BAD:BAD::/64 onlink autoconfig
Valid lifetime 2592000, preferred lifetime 604800
We can still see the RA from H2 because it has a lifetime of 1800 seconds. Eventually, it will timeout and disappear but until then, it will be used by H1.
Router Policy
What about the router policy? We didn’t have to configure anything to permit RAs from R1. What we can do, is create a policy called ROUTERS with some restrictions that define what R1 can or cannot put in its RAs:
You are using real gear or vios?
Hello Heriberto
As far as I know for most of Rene’s labs he uses Cisco’s VIRL.
Laz
Hi, so I’m trying to understand whats going on with this so I’ve created the test setup int CML2 and looking at the commands should the command be
... Continue reading in our forumshow ipv6 route nd
instead ofshow ipv6 route static
?as when I type in show ipv6 route static I don’t see any entries
but if I type in
Hello Andy
Yes, you seem to be correct. The default route that will appear in H1 should be learned via NDP from either the legitimate or the hijacker router, and should not appear as a static route. I will let Rene know about this to modify the content…
Thanks again!
Laz
Hello,
I am trying to implement RAguard attach-policy on the interface but I get this message:
% Hardware failure
I am labbing on vIOS VIRL image with EVE-NG, is that due to the virtual appliance that doesn’t support the feature or am I missing something ?
Does it work for someone ?
Thank you
Mathieu.