Additional info¶

Bogons¶

My Interfaces: LAN 'Private networks' section contains Block private networks and Block bogon networks which I've left unticked.

DHCPv6¶

To set the SLAAC config, I chose Services: DHCPv6 server and left the Enable DHCPv6 server on LAN interface checkbox of LAN/DHCPv6 Server unticked. Instead I clicked the LAN/Router Advertisements tab and changed the Router Advertisements listbox from disabled to unmanaged thus producing the radvd.conf(5) mentioned earlier.

IPv6 routing table¶

cafe.ubuntu$ netstat -rn6
Kernel IPv6 routing table
Destination                          Next Hop                          Flag  Met Ref Use If
cafe:babe:cafe::/50                  ::                                UAe   256 0   0 eth0
fe80::/64                            ::                                U     256 0   0 eth0
::/0                                 fe80::20d:b9ff:fe35:(pfSense^1)   UGDAe 1024 0  0 eth0
fe80::ea11:32ff:fe5b:(ubuntu^2)/128  ::                                Un    0   1   0 lo
ff00::/8                             ::                                U     256 2   0 eth0
::/0                                 ::                                !n    -1  1   3 lo

...where ^1 is the pfSense router's link-local address and ^2 is the ubuntu client's link-local address.

IPv6 route tracing¶

My IPv6 tunneled routing is working just as it did before updating from 2.1.5 to 2.2. I followed https://doc.pfsense.org/index.php/Using_IPv6_with_a_Tunnel_Broker while configuring. If I log into the pfSense 2.2 router I can send and receive IPv6 packets:

[2.2-RELEASE][admin@name.host.tld]/tmp: ping6 2001:4860:4860::8888
PING6(56=40+8+8 bytes) cafe:babe:cafe:babe::a --> 2001:4860:4860::8888
16 bytes from 2001:4860:4860::8888, icmp_seq=0 hlim=56 time=45.710 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=1 hlim=56 time=45.137 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=2 hlim=56 time=45.207 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=3 hlim=56 time=45.171 ms
^C
--- 2001:4860:4860::8888 ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 45.137/45.306/45.710/0.234 ms

...and if I log into the Ubuntu host and manually configure a IPv6 address it works:

cafe.ubuntu$ sudo ip -6 addr add beef:dead:beef::baba/50 dev eth0
cafe.ubuntu$ ping6 2001:4860:4860::8888
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=55 time=46.5 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=55 time=46.6 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=55 time=48.5 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=4 ttl=55 time=52.7 ms
^C
--- 2001:4860:4860::8888 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 46.537/48.614/52.769/2.539 ms

Problem¶

Alas, SLAAC is still not working propertly and none of the IPv6 enabled hosts on the LAN configure IPv6 addresses via ICMP6 from pfSense RA packets.

Yes, I'm getting a single RA from pfSense to ip6-allnodes which results in a correct IPv6 route in the Ubuntu client's routing table. My theory is that there should be a second RA describing the network prefix from which the client can take an address. If this theory is correct, then the missing RA is probably being sent by radvd(8) and results in the sendmsg: Permission denied errors in the pfSense log.

can you send me a pcap containing one of the RAs? Email to me cmb at pfsense.org referencing this ticket # if you don't want to post it publicly.

In fact, the SLAAC logic in pfSense 2.2 seems to be okay. If an interface is configured with flawed Ipv6 notation like this:

IP: 2001:1234:5678:1::1
Subnet bits: 50

...then pfSense will accept it and advertise (see full captures below):

prefix info option (3), length 32 (4): 2001:1234:5678::/50, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s

But if I use the same interface address but change the subnet mask from /50 to /64, then pfSense will advertise:

prefix info option (3), length 32 (4): 2001:1234:5678:1::/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s

Solution¶

For whatever reason, neighbour nodes won't autoconfigure their interfaces when receiving the former RA prefix, but will properly autoconfigure when receiving the latter RA prefix.

Full capture which neighbor nodes silently REJECT¶

15:54:25.478912 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::20d:b9ff:fe35:babe > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 136
        hop limit 64, Flags [none], pref low, router lifetime 60s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2001:1234:5678::/50, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
          route info option (24), length 24 (3):  ::/0, pref=medium, lifetime=60s
          rdnss option (25), length 24 (3):  lifetime 20s, addr: some:rdns:srvr:::1234
          dnssl option (31), length 24 (3):  lifetime 20s, domain(s): mydnserver.itut.
          mtu option (5), length 8 (1):  mymtu
          source link-address option (1), length 8 (1): my:ma:ca:dd:dr:es

Full capture which neighbor nodes ACCEPT¶

16:36:47.356375 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 136) fe80::20d:b9ff:fe35:babe > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 136
        hop limit 64, Flags [none], pref low, router lifetime 60s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2001:1234:5678:1::/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
          route info option (24), length 24 (3):  ::/0, pref=medium, lifetime=60s
          rdnss option (25), length 24 (3):  lifetime 20s, addr: some:rdns:srvr:::1234
          dnssl option (31), length 24 (3):  lifetime 20s, domain(s): mydnserver.itut.
          mtu option (5), length 8 (1):  mymtu
          source link-address option (1), length 8 (1): my:ma:ca:dd:dr:es

Conclusion¶

Troubleshooting was impeded by constant irrelevant pfSense radvd(8) logging errors, but there seems to be no problem in the RA broadcasting logic. Furthermore, changing interface prefixes from 50 to 64 and clicking 'Apply' does not restart radvd(8) which must be manually restarted in order to broadcast the changed (implicit) RA prefix.

Recommendation¶

There is probably some IPv6 subnet or prefix validation test that would prevent users from making the mistake of supplying a 50 rather than 64 bit mask, and if the RA daemon is depending on interface configuration for a implicit prefix config then it should be restarted when a interface is changed and 'Apply' is clicked.