You don't have to do anything with DHCPv6 Relay unless the DHCPv6 server is on another subnet.

In a static IPv6 WAN configuration, if the provider is expecting /56 and you set /64 on the WAN interface (others have said setting /56 on the WAN interface is ridiculous; they are correct), the ISP assumes that 2001:xxxx:xxxx:6901:: is on the same L2 subnet, but it isn't because the subnets sizes don't match. Think of the /56 as 256 /64s.  PfSense can pick select /64 for each LAN or VLAN interface.

@fastisp: The physical interface is a Realtek PCIe GBE network Controller (onboard ethernet controller). That might be the cause of your problems. Otherwise, I have no idea. :(

^ that clearly is not needed derelict, I already posted the RA coming out of pfsense with the vlan tag on it..  See my tcpdump. "Try with it set to unimagaged on the vlans and managed on the native interface with DHCPv6 enabled." Has ZERO to do with anything!! And as a side note - how do you know I don't have that currently setup that way ;) Simple enough for you to show that pfsense is not putting tags on traffic.. simple tcpdump is all that is needed you will either see the tags or you wont.. Per what Derelict stated about the conf and the interfaces in it.. You can see clearly that assigned to the vlan interface or not. [image: conf.png] [image: conf.png_thumb]

Unfortunately yes this is a production system. I have enabled Reject Leases From: 192.168.100.1 as my modem (surfboard) apparently does that when it loses connection. I haven't seen it happen in a couple days, but we're still in the 4 day window.

HOLY JEBUS! After whacking my head against this and doubting my networking skills… I got it running. Turns out: A rogue IPMI from (older) testing times was also using the same IP used for the transfer net. This resulted in some kind of wierdness. Deactivated ipv6 on said ipmi, everything is working. Thanks all you rock! I can rest easy tonight. \o/ -Chris.

As to visiting the site only twice - I find myself using their looking glass interface now and then https://lg.he.net/ very handy… And if your leveraging their FREE dns you will need to go there, or if you want to edit any of your IPv6 PTR records. So prob a bit more than twice for some of us ;) BTW they also make a handy app for your iphone/android http://networktools.he.net/

While I agree, and sure hope he is not forwarding traffic to something that is not meant to be public consumed.  He is forwarding to port 80 - so assumed it was some public sort of website. If this is a private use app your running - then by all means the correct solution would be to vpn into pfsense and then access whatever it is you want.

Thanks for pointing it out: https://redmine.pfsense.org/issues/7625

/64 Neighbour Discovery (ND) Prefix. This is used to automatically address the WAN interface of your Router, or if you are directly connected without a router, the WAN interface of that device. Actually, it's router advertisements that do that.  The router advertisements tell the device the network address and the router link local address.  If necessary, a device can to a router solicitation to trigger an advertisement.  Neighbour discovery is used to find the MAC address for a host's IPv6 address.

@JKnott - it was just the first site I found with a quick google to just show that browser can leak your local address.  It might not even do IPv6, etc. Without some details its unclear to what might have been reported to this guys buddy.  But if he has ipv6 off on pfsense, I find it pretty much impossible for it to be a global IPv6 address from his isp, etc.  So it could be something like a browser leak, or could be say a teredo address.. There are better sites for detecting ipv6 leaks, etc.

OMG Thanks!!! I'll try to make it work based on that picture. If I have any problems, and if you don't mind I'll come back here to ask for help. Thanks :D

Thanks, patched the file and fixed my problem in 2.3.4 - guess issue has no priority…

Perhaps the easiest way of getting your own ULA is http://unique-local-ipv6.com. I want to thank HG for making me aware of RFC 7368 and twitched for pointing out a simple way to implement it in pfSense.

Here's a Wikipedia article about MSS: https://en.wikipedia.org/wiki/Maximum_segment_size Please note where it says: The maximum segment size (MSS) is a parameter of the options field of the TCP header that specifies the largest amount of data, specified in bytes, that a computer or communications device can receive in a single TCP segment. It does not count the TCP header or the IP header (unlike, for example, the MTU for IP datagrams).[1] The IP datagram containing a TCP segment may be self-contained within a single packet, or it may be reconstructed from several fragmented pieces; either way, the MSS limit applies to the total amount of data contained in the final, reconstructed TCP segment The MSS field is a 32 bit value, which means the MSS could be as much as 65K bytes.  This is entirely legal, but it would force fragmentation, when the packets are created.  On the other hand, if you don't specify the MSS, it will be determined automagically, when the two ends set up the TCP connection, based on the interface and path MTUs. So, bottom line, DON'T TOUCH THE MSS!!!

Both or IPv4 only. Deutsche Telekom breaks every 24h IPv4 Connection and gives a new IPv4 but not everytime a IPv6. In both situations IPv6 doesn't work after this event for lan Clients https://forum.pfsense.org/index.php?topic=130448.0  WAN seams to be ok. I turned of that DHCP devices register in unbound and it helps, but if IPv6 works, the renewel script lets start unbound at 00/15/30/45. But back to the topic, IPv6 doesn't work in 2.3.4 with Deutsche Telekom… know some patches for that? pfadmin

Bug 7303

Disable and enable the wan interface, then post the dhcp log entries. Also, if your orbi is an AP, I don't see why you need to have a dedicated interface for it. I have two ubiquity APs on my network and they just work. You may want to try disabling the orbi interface to ensure that it's not interfering with the wan and lan interfaces.