IPv6 RA Guard

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:

Ipv6 Ra Guard Topology

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
The policy that I just created doesn’t have any criteria, except for the device-role but “host” is the default. I also could have used the ipv6 nd raguard command on the interface without any parameters and the end result would be the same. When we look at the router policy, you’ll see how you can add criteria.

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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 786 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

1512 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Forum Replies

  1. Hello Heriberto

    As far as I know for most of Rene’s labs he uses Cisco’s VIRL.

    Laz

  2. 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
    show ipv6 route nd instead of
    show ipv6 route static ?
    as when I type in show ipv6 route static I don’t see any entries
    but if I type in

    H1#sh ipv6 route nd
        IPv6 Routing Table - default - 6 entries
        Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
               B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
               H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
             
    ... Continue reading in our forum

  3. 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

  4. 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.

4 more replies! Ask a question or join the discussion by visiting our Community Forum