Firewall – Many ‘Deny IPv6-ICMP reverse path check’ alerts from multicast addresses on Cisco ASA

ciscocisco-asafirewallipv6multicast

In an effort to prevent IP Source Address Spoofing (RFC 2827) I've enabled reverse path filtering (RPF) on my Cisco ASA 5505.

The topology is aprox. like this. Each segment has its own IPv4 subnet and IPv6 subnet.


                 guests
           vlan 40 |
                   |
  vlan 2           |            vlan 10
outside --------- ASA -------- inside
                   |
                   |
           vlan 30 |
                  dmz

I've enable RPF like this:

ip verify reverse-path interface outside
ip verify reverse-path interface inside
ip verify reverse-path interface guests
ip verify reverse-path interface dmz

On the outside interface I'm seeing some things being blocked by RPF as expected, such as:

Feb 20 2014 11:25:06: %ASA-1-106021: Deny ICMP reverse path check from <ip1> to <ip2> on interface outside

However on all other interfaces I see dozens of IPv6-ICMP events a minute, like these:

Feb 20 2014 11:27:21: %ASA-1-106021: Deny IPv6-ICMP reverse path check from :: to ff02::16 on interface guests
Feb 20 2014 11:27:21: %ASA-1-106021: Deny IPv6-ICMP reverse path check from :: to ff02::1:ff73:8762 on interface guests
Feb 20 2014 11:27:21: %ASA-1-106021: Deny IPv6-ICMP reverse path check from :: to ff02::1:ffed:4b2d on interface guests

Those IP's appear to be IPv6-multicast related, according to Wikipedia. I'm no expert in multicast.

Why are they triggering the RPF check, and what can I do about them? Is this a misconfiguration on my part or of not, can I somehow stop the flood of alerts?

Best Answer

The :: address is the unspecified address. It is not often used on the wire, but its use is allowed in certain cases. One example is specified in RFC 3810 section 5.2.13, which explains the packets to ff02::16.

Such packets don't seem spoofed and shouldn't trigger an RPF error. I therefore think this is an implementation bug in the ASA. I cannot be sure though without seeing the actual packets. It is probably a good idea to open a Cisco TAC case for this.

Related Topic