Bug #4429
closedProblem with radvd(8) SLAAC packets autoconfiguring client IPv6 routes
0%
Description
In the last release 2.1.5, stateless address autoconfiguration (SLAAC) was working correctly. After updating to 2.2 my SLAAC clients make requests as usual but drop (or plumb or down) their IPv6 addresses as the wrong (or too few?) SLAAC packets are broadcast from pfSense. In the following packet analysis, 'cafe' is the Ubuntu 14.04 AMD64 desktop host making SLAAC client request to the router 'babe' running pfSense 2.2-RELEASE (amd64) on year 2014 PC Engines hardware:
cafe.ubuntu# tcpdump -i eth0 icmp6
13:33:02.048683 IP6 :: > ff02::1:ff5b:cafe: ICMP6, neighbor solicitation, who has fe80::ea11:32ff:fe5b:cafe, length 24
13:33:03.048724 IP6 fe80::ea11:32ff:fe5b:cafe > ip6-allrouters: ICMP6, router solicitation, length 16
13:33:03.497266 IP6 fe80::20d:b9ff:fe35:babe > ip6-allnodes: ICMP6, router advertisement, length 136
babe.pfsense# tcpdump -i re1 icmp6
13:33:02.053881 IP6 :: > ff02::1:ff5b:cafe: ICMP6, neighbor solicitation, who has fe80::ea11:32ff:fe5b:cafe, length 24
13:33:03.053981 IP6 fe80::ea11:32ff:fe5b:cafe > ff02::2: ICMP6, router solicitation, length 16
13:33:03.502143 IP6 fe80::20d:b9ff:fe35:babe > ff02::1: ICMP6, router advertisement, length 136
...it seems that packets are not being blocked by a firewall rule since I have a firewall rule on LAN to pass IPv6 liberally as well as:
<system>
<ipv6allow/>
</system>
I'm routing IPv6 over HE Tunnelbroker, have VLANs and am running Captive Portal (which crashes PFSense when I turn it off.)
When I select 'Status: System logs: Routing', I see in 'Routing daemon log entries':
radvd12345678: sendmsg: Permission denied
radvd12345678: sendmsg: Permission denied
radvd12345678: sendmsg: Permission denied
radvd12345678: sendmsg: Permission denied
...and I check that radvd(8) is running:
$ ps -a | grep 12345678
root 12345678 0.0 0.1 <somenum1> <somenum2> - S Thu08PM 0:48.60 /usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
...and see that the radvd(8) configuration is correct:
pfSense# cat /var/etc/radvd.conf- Automatically Generated, do not edit
- Generated for DHCPv6 Server lan
interface re1 {
AdvSendAdvert on;
MinRtrAdvInterval 5;
MaxRtrAdvInterval 20;
AdvLinkMTU 1500;
AdvDefaultPreference low;
prefix beef:dead:beef::/50 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
route ::/0 {
RemoveRoute on;
};
RDNSS cafe:babe:cafe:babe::9 { };
DNSSL host.tld { };
};
...and radvd.conf(5) has entries for opt[n] which are VLANs with identical configs just the prefix are different.
I've also tried setting the funky '<allowopts/>' Advanced features/Advanced Options/IP options on the LAN/Ipv6 firewall rule as well as adding a second LAN/Ipv6 rule specially for fe80:: 'Local link IPv6 -> any'.
QUESTION
What can I do to make SLAAC work correctly as it did in pfSense 2.1.5?
Updated by Mich MSvB about 9 years ago
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
...so I've concluded that only SLAAC is broken.
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.
Updated by Chris Buechler about 9 years ago
- Status changed from New to Feedback
This works in general. You're getting RAs, which seem fine at a basic level at least though contents of the RA not shown. Capture those to a file and open in Wireshark (and/or attach here), do they look sane?
Updated by Mich MSvB about 9 years ago
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.
Updated by Chris Buechler about 9 years ago
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.
Updated by Mich MSvB about 9 years ago
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.
Updated by Chris Buechler about 9 years ago
- Status changed from Feedback to Closed
Thanks for the follow up. SLAAC requires a /64, which is why. The RAs are correct. Not a bug.
though we could improve usability in some related areas here. That's something I'm reviewing