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.

@bimmerdriver: If you use pfsense 2.4 beta, the DUID is displayed in System / Advanced / Networking / IPv6 Options / DHCP6 DUID. It's a DUID-LLT format. As Bimmnerdriver says. Use version 2.4B. The DUID is then stored in the config file and will never change. Earlier pfSense versions can lose the DUID, especially if you are using a RAM disk. Goto System / Advanced / Networking / IPv6 Options / DHCP6 DUID and click SAVE. If you use an earlier version then the DUID is created by the dhcp6c client, and is created in /var/db, it goes by the name pf dhcp6c_duid. It's a binary file so you would need to read it in a hex editor. However, as I have said, if you use and earlier version than 2.4B you run the risk of the DUID changing.

I am pretty sure there is an issue with the latsest version of pfSense (2.3.4). I cannot put my finger on it. At least not yet. On my production firewall, I received the IPv6 from my provider using DHCPv6. I also got 128 subnet preventing anything to work. As I also owned a /48 from HE. I installed a second pfsense where I can play with at will using my production firewall to provide DHCPV6 and subnet delegation. During all my test, I always got a 128 subnet on my test firewall (sniffing the network shows the correct /64 announcement). I try many different configuration without success. Sometimes if I used SLAAC on my test firewall it works fine (reconfiguring the main firewall accordingly) , switching to DHCPv6 seems to provide the correct result… It is inconsistent and so far I could not create a test that provide each time the same results that would allow a good basis to fill a bug report... I am still searching but this 128 subnet appears after I installed the latest release. My next step will be to install an older realease on my test firewall....I'll let you know the outcome.

@moscato359: They were both set to 0. Would that cause the issue? Yes, that is what selects which /64 is used.  With both set to 0, they're trying to use the same prefix.  Change one to another number up to 255.

@mjgtall: @johnpoz: Glad to hear.. So they just forgot to give you that info before or did they have to fix it? Thanks. No, they had to fix it. Just out of curiosity, is your ISP Comcast?

Thanks for all help. I think I finally found the last problem. I had a IP alias for ::1 so I could have a easy to remember static gateway.. it had a /128 per how I'm used to setup ip aliases. Apparently the dhcp server were using this as base for it's range6 statement and it also messed things up somehow so it didn't reply to that anymore. After removing the ip alias and also disabling ipv6 completely on the lan interface and re-enabling everything including the ip alias but now as a /64.. everything seems fine again. Not sure if some check was changed between the releases.. because this issue started after the upgrade.

After a reboot of everything involved (computers, pfsense boxes, etc) everything is now working

That makes it look much easier I have now fixed it. I am very pleased,the kids not so much! Thank you so much for the help!

I just set up OpenVPN between my psSense firewall and a computer running Windows.  Initially, it provided the Windows computer an IPv6 address on my network prefix.  However, that will cause problems with routing etc., so I changed it to another prefix.  I'll have to see what happens with this.  At the moment, I can't ping the firewall or Windows computer, using the OpenVPN endpoint addresses.

Yes, I know every interface has a link local address.  No doubt about it.  My point is that it's not used for most things.  Routers advertise the link local address and other devices use that link local address for the default route.  But you can't use browsers with a link local address and you have to specify the interface for everything else, as a given link local address could be on any interface, as there is nothing in the link local address to indicate which interface is used.  For example, I just pinged my firewall.  When I used the global unicast address, I could just ping it.  But to ping the link local address, I had to specify the interface that connected to the firewall, even though there is only one network interface in this computer. i.e. ping6 -I eth0… So, yes, you could do something like use ssh to connect to a link local address, but why bother, if you have another unicast address, where you don't have to specify the interface? Regardless, this has gone beyond the original question, where the OP confused link local addresses with unique local addresses. https://en.wikipedia.org/wiki/Unique_local_address https://en.wikipedia.org/wiki/Link-local_address#IPv6