Blocking unwanted IPv6 RAs from devices on LAN

[eddy]

I'd like to block unwanted IPv6 Router Advertisements from certain devices on the LAN (specifically, Thread-capable Apple devices: the 2021 Apple TV 4K and HomePod Mini).

Because these devices have Thread radios, they act as WiFi-to-Thread bridges, via these IPv6 RAs.

Normally, these RAs wouldn't be an issue, and most people probably never notice them. For reference, I ran radvdump on the firewall, and this is what they look like:

Code: [Select]

interface igb2
{
AdvSendAdvert on;
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 0;
AdvDefaultLifetime 0;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;

        prefix fda5:29ff:3b2c:1::/64
{
AdvValidLifetime 857;
AdvPreferredLifetime 0;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition

        route fdb0:dd88:d3ec::/64
{
AdvRoutePreference medium;
AdvRouteLifetime 1800;
}; # End of route definition
}; # End of interface definition
HOWEVER, the RAs are very problematic for devices on the LAN that utilize the Cisco AnyConnect VPN client for secure remote access. (And for what it's worth, both MacOS and Windows system are affected by these RAs.)

Why? Any change to the network configuration (such as the addition or removal of an IPv6 address on an interface) is detected by AnyConnect, and to "secure" the system, it updates all its pf rules and then runs pfctl -F states to flush the state table, breaking all existing connections, which, of course, is unacceptable from a user perspective. And since these RAs have 1800s lifetimes, this can happen every 30 minutes!

Code: [Select]

vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] A network interface address has gone down.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] A routing table change notification has been received.  Starting automatic correction of the routing table.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] A new network interface address has been detected.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] Reconfigure reason code 15: New network interface.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] A routing table change notification has been received.  Starting automatic correction of the routing table.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] Automatic correction of the routing table has been successful.
vpnagentd: (libvpncommon.dylib) [com.cisco.anyconnect.vpn:acvpnagent] The entire VPN connection is being reconfigured.
Obviously I have an IPv6-capable network, and it is desirable to have devices on the LAN be able to access the HomePod Minis and Apple TVs, so I don't want to put them on a different VLAN. But since I don't have a need for Thread, I would like to block the RAs coming from these devices.

These are wireless devices, so the RAs come in via Ruckus APs which are connected to switches on OPNsense's LAN1 interface.

So my question: What's the best way in OPNsense to block IPv6 RAs from specific devices?

[priller]

Since the "rouge" RA's are already on the LAN,  OPNsense can't do anything about it. The source device sends them out and everybody is going to see them.

What you would need is a feature like RA Guard on the wireless or the wired switched LAN depending on the device attachment. 

Perhaps AnyConnect has a feature to only trust specific source RA's or something along that line?

[chemlud]

add an interface/VLAN named "appletrash" and put all these "devices" in there. Allow only traffic you really want/need.

I would never have entertainment and bussiness devices on the same interface. This is asking for trouble..

[priller]

One possibility is to set the OPNsense RA priority to "high".  The default is "normal" which is "medium" ... the same as the rouge RA.  A higher priority RA from OPNsense may very well my keep AnyConnect from flipping as it does now due to receiving multiple RA's of the same priority.