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

@virgiliomi:

The two items I bolded in your original post are why you will need to adjust the indexes. LAN1 and WAN are currently set to use the same /64 address range (assuming the xxxx:xxxx is the same in both, since you didn't use different letters), which won't work. Fix the index used for LAN 1.

That's what I figured.  Thanks, I appreciate the confirmation.

I renew this old thread because, at today (2.3), I think would be useful  a way to set the right MTU in a 6rd ipv6 environment.
Currently mtu is hardcoded to 1280…. but in case of ipv4 mtu 1500 on the wan, the right (and optimal) value should be 1480... (wan mtu minus 20).
What do you think about?

What johnpoz is talking about is that with IPv6 tunnels the traffic is fully routed and the remote end must know which IPv6 prefix (usually a /64) it should route to the client end for two-directional traffic between the LAN network on the client and the IPv6 internet. Also that same prefix must be used on the local LAN for hosts by some method, manual or automatic configuration. OpenVPN as far as I know has no provisions for automatic configuration of IPv6 other than the one client IPv6 address that gets assigned to the local end of the tunnel network.

It's possible. Just not with the exposed pfsense gui. Here are some logs after some heavy editing in dhcpd6.conf (rog is a W10 client):

bind debug log

client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': update unsuccessful: rog.example.com: 'name not in use' prerequisite not satisfied (YXDOMAIN) client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': deleting rrset at 'rog.example.com' DHCID client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': adding an RR at 'rog.example.com' DHCID AAIB6pZPrA7zoDg1s+EYgl0GGo0yjS0hKNuiDIcN0lyFMHs= client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': deleting rrset at 'rog.example.com' AAAA client 2a02::1#23748/key dhcp_updater: updating zone 'example.com/IN': adding an RR at 'rog.example.com' AAAA 2a02::b9c7

Pfsense dhcpd log:

May 13 08:33:57 srv dhcpd: Sending Reply to fe80::4854:ff3c:xxxx:xxxx port 546 May 13 08:33:57 srv dhcpd: Added new forward map from rog.example.com to 2a02::b9c7 May 13 08:33:57 srv dhcpd: Added reverse map from 7.c.9.b.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.a.2.ip6.arpa. to rog.example.com May 13 08:33:58 srv dhcpd: Renew message from fe80::4854:ff3c:xxxx:xxxx port 546, transaction ID 0xA7A3900 May 13 08:33:58 srv dhcpd: Reply NA: address 2a02:::b9c7 to client with duid 00:01:00:01:1d:4e:73:c9:10:bf:xx:xx:xx:xx iaid = 51429192 valid for 1920 seconds ```  Updated zone record:

$TTL 600 ; 10 minutes
rog A 10.0.200.7
AAAA 2a02::b9c7
DHCID ( AAIB6pZPrA7zoDg1s+EYgl0GGo0yjS0hKNuiDIcN0lyF
MHs= ) ; 48819 13 32

The problem is that the pfsense dhcpd server is very picky about dhcp clients. I couldn't register any apple ios device in ipv6 ddns zone. On the other hand i had no problems with a HP printer. ISC dhcp 4.3.4 might fare better.

Thanks for the info – much appreciated!

It may have been you were seeing a Cox modem firmware bug that was impacting IPv6 that has now been fixed. There was some discussion of that bug over at:

http://www.dslreports.com/forum/coxhsi

Your issue is the same than

https://forum.pfsense.org/index.php?topic=109278.0