^ 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.

conf.png
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.

@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?