ICMPv6 Router Advertisments

  • Hello all,

    I'm currently running a fresh install of 2.4.3-RELEASE on bare metal. I having an issue with devices not receiving ICMPv6 router advertisement messages from pfSense. Neighbor advertisement and DHCPv6 assignment is working fine.

    I have the following configured:

    • DHCP6 on WAN with an ISP assigned /56 delegation.
    • DHCPv6 server enabled on the LAN with radvd running in Assisted mode.
    • LAN is a bridge interface (bridge0) with IPv6 auto linklocal enabled.
    • LAN is assigned an IPv6 /64 prefix from the WAN delegation as well as fe80::1:1 for linklocal.

    Clients are assigned an IPv6 address from the delegation but not a default router. Statically setting the default IPv6 router on clients to fe80::1:1 works just fine and traffic passes. I ran tcpdump on the bridge0 interface and only see ICMPv6 type 133 (solicitation) and never a type 134 (advertisement). I also do not see any solicitation/advertisement messages in the radvd log.

    The radvd log does show the following message every roughly every 15-30 seconds, not sure if it's of consequence:

    ioctl(SIOCGIFMEDIA) failed on bridge0: Invalid argument 

    Any thoughts?

  • Hello,

    Same issue other there  :(

    Just find this things on the radvd github : https://github.com/reubenhwk/radvd/issues/33

    It seems to be for 2.4 but we are on 2.17 :
    [2.4.3-RELEASE][root@XXX]/root: radvd -v
    Version: 2.17

  • Hi same issue but with a few differences/specifics.

    • I'm running a HE.net tunnel to get my ipv6-delegation, with static configurations for the LAN interfaces. So no delegation in my case.
    • Only interfaces with a bridge assigned doesn't work/loggs the errors. Interfaces with NICs / VLANs assigned directly work as expected.

    Anyone know how to create a bug in the pfsense-bugtracker and/or got any ideas for workarounds (besides applying gateway manually to the clients where that is a possibility)?

    –- Edit ---
    Seems a Bug is reported in redmine for this.

  • So this problem only applies to bridged interfaces and not single NIC?  This has been causing me to hole off on updating.  Can I assume this won't affect me, as I don't have a bridge configured?

  • Atleast in my case the non-bridged interfaces seems to work, and Spencer's description of the bug on redmine would support this.
    (I find it rather likely that if the more common use-case with NIC-backed interfaces was affected it would have been noticed in testing, but sometimes things slip through).
    Allthough I would probably wait with upgrading until someone with abit better understanding of how everything works together have had a look on the problem before updating if I was in your shoes.

  • I updated yesterday and it appears to be working OK, including IPv6.

Log in to reply