which field on which page?

this fixed it for me

I'm still having this issue with default settings
Modem: SB6183
pfSense: 2.3.1

DHCPv6: Pending

this fixed it for me: https://forum.pfsense.org/index.php?topic=87623.0

No idea about your issue but for something similar happening on my cable modem. The work-around until the glitch was fixed by the ISP with new modem firmware was to do a DHCP release/renew on the WAN interface in pfSense, much less aggravation than a reboot!

http://your-pfsense-box/status_interfaces.php

Yeah, the PPPoE example is exactly the same situation that you have with a tunnel provider such as HE or SixXS. There has to be a separate tunnel network (sometimes called transfer network) with an address space that does not overlap with any of the other subnets used on your systems, otherwise you just can not route anything. On such tunnel network a /64 is used but only two addresses are ever actually used because link is point-to-point with just two peers.

2.3.1-RELEASE-p1 (i386)

@wiz561:

@virgiliomi:

I'll validate darkcrucible's statement as well… /56 for business, /60 for residential, both for cable internet service. The only Comcast residential offering that offers a smaller prefix is their Gigabit Pro 2Gbps active fiber service, where they give a /48.

A touch off-topic, but are there 16 subnets in a /60, where each subnet contains 254 hosts?

You're thinking IPv4.
A /60 gives you 16x /64 IPv6 subnets. So 2^64 addresses in each.

Just thought that I'd mention a feature request asking for the DUID to be part of the config file, allowing it to be backed up/restored.

https://redmine.pfsense.org/issues/3971

I think there's actually a field for it in the config file, but it's probably not used for anything at this point in time as it's blank.

As for persistence across reboots, if you're running the nano version or have RAM disk storage enabled, those might be reasons why it's not persistent. Because it's definitely persistent for my pfSense box, and I'm not using RAM disk storage.

Thanks - that nailed it.

Looks like though I'd tried the /48 and IP4, I clearly hadn't done both at the same time.

I was just about to post I dropped ipv6 on all but one subnet and started just requesting a /64.  I've gone about a week and it is still working.  I can't get /60 to work for more than 24hrs and I don't really have time to fuss with it right now.

Hopefully there will be some solution to this before too long.

Unmanaged = SLAAC (StateLess Address Automatic Configuration)
Managed = DHCPv6
Assisted = SLAAC preferred, DHCPv6 available

If you set your RA to managed, but don't have a DHCPv6 server on your network (either from pfSense or another device on your network), then your devices won't get an IPv6 address.

Also, it should be noted that Android devices only use SLAAC for IPv6 addresses, so you need to either be in Unmanaged or Assisted mode. And Windows will only get an IPv6 address via SLAAC; it won't use RDNSS provided DNS servers. DHCPv6 is required for DNS servers under Windows.

Seems that 6rd border relay need patched stf :(

Thank you for the reply.  Did not know that Assisted was using SLACC.  If I understand your comment, if I set the RA to Managed I will see the leased IPV6  devices and if a device does not support DHCPv6 it will not get an IPV6 address but would still get the IPV4 address from the DHCP v4 server.  is this correct?

Thanks

It Maybe a case of my isp hasn't set up their stuff yet.

@Box293:

What do you mean by activate? Perhaps I'm missing something.

By default, no IPv is assigned to the WAN (or comparable) interface.
I didn't find a dhcp client running that uses "scan" WAN style interfaces which checks if the upstream provides an IPv6.

Btw : setting up manually the config.xml is of course the way to go - and you can definitely consider yourself as a not-pfsense-dummy if you pulled that one off :)

@Box293:

with a WAN connection that provides IPv6 via DHCPv6+PD, pfSense 2.3+ will request a /64 prefix and assign it to the LAN

Which means, when booting, some DHCP-client look-alike is executing to obtain an IPv6/[whatever], putting an IPv6 on WAN and init LAN with an IPv6.
(are you sure ? - all this 'out of the box' without any user preparation ?)

Again : I'm not advertising that I know a lot of IPv6, I use the "tunnel" proposed by he.net. It work quiet well, but isn't really a native solution. I consider it as some sort of "plan B". My ISP is Orange, the biggest in France, 16 million 'victims', sorry => 'clients' - and they still don't know what "IPv6" is. During the last 6 years they are 'testing it' ….. (and right now, they are probably are in strike again  ;)).

It's weird that on my setup apparently the extraction of the ip for the HE-account does not work, but it does for no-ip :-(

@johnpoz:

That is a pretty OPEN rule ;)  If your wanting to lock down access to the gui.. And only access it from a specific vlan great.  But that that seems pretty wide if you ask me ;)

Glad you got it sorted.

yea..I will configure a rule according to the link below. :D
https://doc.pfsense.org/index.php/Restrict_access_to_management_interface

Thanks!!!

If I recall the formula is something like

33434 + (max-ttl * numberofprobes - 1)

Since each port going to use a different port, where 33434 is the base port.. So for example ding a sniff while doing a traceroute to something behind pfsense I get attached.  So yeah opening up the ports should allow your trace to work when using udp.

udptraceports.png
udptraceports.png_thumb
tracerouteviaudp.png
tracerouteviaudp.png_thumb

I have found the solution!

instead of configuring the lan interface to 'track interface'  ,  I used a static ipv6 address and now it works
also those messages in the log are gone now