pfSense

Additional info:

ifconfig shows ACCEPT_RTADV on for the WAN NIC.

Adding the gateawy manually does allow it to work but is not ideal.

On 2.1 which works fine:

: rtsol -dD vr1
rtsol: kernel is configured as a router, not a host
checking if vr1 is ready...
vr1 is ready
set timer for vr1 to 0:242033
New timer is 0:00241936
timer expiration on vr1, state = 1
send RS on vr1, whose state is 2
set timer for vr1 to 4:0
New timer is 4:00000906
received RA from fe80::200:xxxx:xxxx:67cc on vr1, state is 2
OtherConfigFlag on vr1 is turned on
stop timer for vr1
there is no timer

On 2.2 that does not work:

: rtsol -dD em0
checking if em0 is ready...
em0 is ready
set timer for em0 to 0s
New timer is 0s
timer expiration on em0, state = 1
send RS on em0, whose state is 2
set timer for em0 to 4s
New timer is 4s
received RA from fe80::1:1 on an unexpected IF(em1)
New timer is 2s
received RA from fe80::200:xxxx:xxxx:67cc on em0, state is 2
OtherConfigFlag on em0 is turned on
Processing RA
ndo = 0x607a50
ndo->nd_opt_type = 3
ndo->nd_opt_len = 4
ndo = 0x607a70
ndo->nd_opt_type = 24
ndo->nd_opt_len = 3
ndo = 0x607a88
ndo->nd_opt_type = 25
ndo->nd_opt_len = 3
nsbuf = 2001:470:1f11:e1c::1
ndo = 0x607aa0
ndo->nd_opt_type = 31
ndo->nd_opt_len = 3
labellen = 6
labellen = 3
dname = example.org
ndo = 0x607ab8
ndo->nd_opt_type = 5
ndo->nd_opt_len = 1
ndo = 0x607ac0
ndo->nd_opt_type = 1
ndo->nd_opt_len = 1
rsid = [em0:slaac]
write to child = nameserver (11)
write to child = 2001:xxx:xxxx:xxx::1(20)
write to child = 
(1)
write to child = search (7)
write to child = example.org(10)
write to child =  (1)
write to child = 
(1)
script "/sbin/resolvconf" terminated
stop timer for em0
RA expiration timer: type=25, msg=2001:xxx:xxxx:xxx::1, expire=20s
RA expiration timer: type=31, msg=example.org, expire=20s
there is no timer

You expect RA on em0 but receive one from em1 not sure if you have 2 interfaces with DHCPv6?
Can you confirm that?

There was a little more info #3649 about this. Specifically, Ermal's comment on that ticket that "rtsold is not passing the gateway as second argument" which may be helpful to have here.

Added the patch to rtsol, next round of snapshots will have it in

Applied in changeset f3dd7e8cdb11077486421364ea3a11c411ba807b.

Watch out for this one. It works on some boots and not others, or depending on the timing. There's a race condition somewhere. I thought I had noted it on this or a duplicate ticket but can't find it now. The gateway is there during bootup but gets removed toward the end of the boot process. Something is clobbering/removing it.

This should be retested.
For me this should only happen when you have 2+ dhcp6 wans.

On the latest snap + gitsync this is still a problem for me with just one WAN. The gateway appears to be set and is there for a very short time during boot, but then by the end of the boot process, it is gone.

Currently running:
2.2-BETA (i386)
built on Sat Nov 08 15:40:19 CST 2014

I have a dual WAN configuration. WAN-01 consistently doesn't pick up a DHCP lease, WAN-02 picks up a lease most of the time, but not always. This isn't a critical system. I can test patches / config changes if that will help.

Meant to say DHCP6

Peter: you're not getting an IP at all? That seems like a different issue, what we've seen here the system gets an IP, sets its default gateway accordingly, but something comes along behind it and deletes the default gateway. Assuming you're not getting an IP, that is different, if you could start a thread on the 2.2 board (https://forum.pfsense.org/index.php?board=57.0) we can work with you to narrow down the possible causes and open a bug report with the root issue.

Finding a new issue wasn't the contribution I intended to make.

I'll double check with the ISP for that WAN connection to make sure things are all good on their end. If no issues there, I'll start with a post to the forum. Thanks for being kind about my unintentionally off topic post.

Turns out that the ISP for the WAN in question is only experimenting with IP6 at the moment. Anything I've picked up in the past was sheer luck. I'm sorry for the false alarm.

JimP: you have a way to at least semi-reliably replicate this on current versions? I've been trying a variety of scenarios for hours, across several dozen reboots, and haven't gotten it to fail once. IIRC you're seeing that on an ALIX? I'm mostly testing with VMs on fast systems, and physical hardware that runs circles around an ALIX. Didn't have an ALIX available a network with DHCP6 today.

Chris Buechler wrote:

JimP: you have a way to at least semi-reliably replicate this on current versions? I've been trying a variety of scenarios for hours, across several dozen reboots, and haven't gotten it to fail once. IIRC you're seeing that on an ALIX? I'm mostly testing with VMs on fast systems, and physical hardware that runs circles around an ALIX. Didn't have an ALIX available a network with DHCP6 today.

I have a 2.2 VM that never has a V6 gateway by the time the boot process ends. Ermal has access to it, I gave him the info last week.

My APU gets a gateway sometimes but not always. ALIX is the same.

The server ahead of it is pfSense doing DHCP-PD. Nothing too crazy about the setup. 2.1.x VMs pull settings without issue.

How low is your V6 lease time? It may get the gateway back when it renews the lease. If I save/apply WAN the gateway comes back.

This appears to be tied to having a DHCPv4 WAN configured along side DHCPv6. If I set the WAN of an affected system to static IP, the IPv6 gateway is present and working on each subsequent reboot. Set the system back to use DHCPv4 WAN and reboot and the v6 gateway goes missing.

Applied in changeset ec5753e7563c31e843a503d17f78487a2d156c78.

Will leave for feedback until the fix is in snapshots, but a gitsync on two VMs and an APU shows they are all working correctly. Kudos!