Host ignores IPv6 router advertisements (SLAAC)

subsevid

subsevid

I'm currently setting up a FreeBSD host with native IPv6. My router provides a prefix to all local machines via SLAAC. Unfortunately the FreeBSD machine ignores all router advertisements (RAs) unless I put the relevant interface re0 in promiscuous mode.

I'm following instructions from this page of the handbook.

This traffic results from running rtsol re0 on the machine in question (recorded on a third machine):

Code: 
13:48:29.191491 IP6 fe80::e23f:49ff:fe17:e776 > ff02::2: ICMP6, router solicitation, length 16
13:48:29.192821 IP6 fe80::2665:11ff:fe6d:10d > ff02::1: ICMP6, router advertisement, length 112
13:48:33.230717 IP6 fe80::e23f:49ff:fe17:e776 > ff02::2: ICMP6, router solicitation, length 16
13:48:33.231668 IP6 fe80::2665:11ff:fe6d:10d > ff02::1: ICMP6, router advertisement, length 112
13:48:37.271650 IP6 fe80::e23f:49ff:fe17:e776 > ff02::2: ICMP6, router solicitation, length 16
13:48:37.272669 IP6 fe80::2665:11ff:fe6d:10d > ff02::1: ICMP6, router advertisement, length 112

If I run tcpdump on the problematic machine, th RA gets processed and an IPv6 address is set. However the gateway is still missing according to the output from netstat -r:

Code: 
Destination        Gateway            Flags      Netif Expire
::                 localhost          UGRS        lo0
localhost          link#2             UH          lo0
::ffff:0.0.0.0     localhost          UGRS        lo0
2003:44:ed33:700:: link#1             U           re0
2003:44:ed33:700:e link#1             UHS         lo0
fe80::             localhost          UGRS        lo0
fe80::%re0         link#1             U           re0
fe80::e23f:49ff:fe link#1             UHS         lo0
fe80::%lo0         link#2             U           lo0
fe80::1%lo0        link#2             UHS         lo0
ff01::%re0         fe80::e23f:49ff:fe U           re0
ff01::%lo0         localhost          U           lo0
ff02::             localhost          UGRS        lo0
ff02::%re0         fe80::e23f:49ff:fe U           re0
ff02::%lo0         localhost          U           lo0

Has anyone had problems like this before? Any ideas where this problem stems from?
 
Your interface needs to be configured. Do you have, in /etc/rc.conf:
Code: 
ifconfig_re0_ipv6="accept rtadv"
 
SirDice said:
Your interface needs to be configured. Do you have, in /etc/rc.conf:
Code: 
ifconfig_re0_ipv6="accept rtadv"
Click to expand...

Yes, I think so. Here are the relevant parts of rc.conf:

Code: 
ip6addrctl_enable="YES" 
ip6addrctl_policy="ipv6_prefer" 
ipv6_network_interfaces="re0"
ifconfig_re0="DHCP"
ifconfig_re0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"

Some of that is probably unnecessary but I have been trying out a lot since I started on this.
 
I know one problem with SLAAC which explained why I could not and never will be able use it (quite similar to your problem). You really need to advertise a /64 net for SLAAC to make it work.
 
nakal said:
I know one problem with SLAAC which explained why I could not and never will be able use it (quite similar to your problem). You really need to advertise a /64 net for SLAAC to make it work.
Click to expand...

My router has a /56 available to it, and as far as I can tell it provides /64 prefixes to hosts.

For example here is a line from ifconfig on a Linux machine from the same network:

Code: 
inet6 2003:44:ed32:700:2185:9f45:ce6f:faa8  prefixlen 64  scopeid 0x0<global>

As you can see it got assigned a /64 prefix from the /56 that my router has assigned.
 
I have investigated some more: It seems all ICMP6 traffic is affected. Using ping6 google.com showed that all ICMP6 traffic is ignored.

While tcpdump is running, everything works. Even the gateway problem is gone now.

This feels like a firewall issue, but I have the following firewall settings in my rc.conf:

Code: 
firewall_enable="YES"
firewall_type="open"

What am I missing?
 
The default ipfw rules for type "open" do not explicitly allow router solicitation and router advertisement packets:

Code: 
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00400 deny ip from any to ::1
00500 deny ip from ::1 to any
00600 allow ipv6-icmp from :: to ff02::/16
00700 allow ipv6-icmp from fe80::/10 to fe80::/10
00800 allow ipv6-icmp from fe80::/10 to ff02::/16
00900 allow ipv6-icmp from any to any ip6 icmp6types 1
01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
65000 allow ip from any to any

(A list of ICMP6 message types is available here.)

As you can see 133 and 134 are missing. I added those to the relevant configuration. Unfortunately that did not solve the problem.
 
How about switching off the packet filter entirely to figure out if it is the source of the problem? Or you can force logging on deny rules and watch the log for blocks during the solicitation procedure.
 
nakal said:
How about switching off the packet filter entirely to figure out if it is the source of the problem? Or you can force logging on deny rules and watch the log for blocks during the solicitation procedure.
Click to expand...

Regarding your first suggestion: I'd love to try that but apparently the default deny policy is compiled into the kernel? Setting firewall_type="open" was the closest thing I could find in the handbook. If there's something I'm missing here, please tell me.

I have tested
Code: 
firewall_logdeny="YES"
and nothing showed up in the logs. (Logging allowed traffic works as intended. But that's also missing the RAs.)

I think this is an issue with multicast because RAs are sent to a multicast address. Is it possible FreeBSD ignores multicast by default? How could I test this?
 
You should take a look at the rtsold() options. To make everything work properly the non-default option -F is needed.

To debug what rtsold does, you can start it on the command line in debug mode like this (IIRC):
rtsold -aFfd
 
nakal said:
You should take a look at the rtsold() options. To make everything work properly the non-default option -F is needed.

To debug what rtsold does, you can start it on the command line in debug mode like this (iirc):
Code: 
rtsold -aFfd
Click to expand...

I have tested rtsold with those options, unfortunately nothing changed. Given that the firewall doesn't even log in the incoming RAs, I think there is a problem at the driver level.

Accordingly I have tested the same configuration with a wifi stick (on the same network). SLAAC works 100% for that. So I assume this is a driver issue with my realtek chip. For reference, this is the problematic device: RL_HWREV_8168F aka RTL8111/8168B PCI Express Gigabit Ethernet controller.

Thank you everyone for your suggestions.
 
You must log in or register to reply here.
Back
Top