@chrcoluk I downloaded 2.5 and tested this today. Based on my results i created https://redmine.pfsense.org/issues/9893 If you have any information you could add to the new bug it would be appreciated.

Or ignore the logs. Or make rules that suppress the logs. Whether or not you enable IPv6 really depends on whether or not you have IPv6.

@JKnott I finally figured it out. "Track Interface" is the option that seems to be the right way to solve my problem.

@adhodgson said in IPV6 working on LAN but not pfSense box itself: Could I potentially use one of the /64s on the WAN side? No point in doing that. You already have a /128 address on the WAN and the link local address is used for routing. That's all you need. I had a problem with my ISP a few months ago. I used Wireshark and Packet Capture to see what was happening. I also tethered my notebook computer to my cell phone so that I could test from outside my network. With that, I was able to determine that the problem was not on my network and was even able to identify, by host name, the failing system at my ISP. One thing I did, which helped is I used a 5 port switch, configured as a data tap, to monitor the traffic between my modem and firewall, when pfSense was booting up.

after losing 2 days of sleep the problem was solved after disabling "Block private networks and loopback addresses" and/or "Block bogon networks" that i had on the WAN interface it was mentioned here https://redmine.pfsense.org/issues/9631 also a route come out of nowhere after cheking the routing table i had the ip from general settings / DNS inside the routing table

@amello said in IPv6 address allocated but not working: It is u-verse, so DSL on dry line. A couple of my friends have ADSL and get IPv6. I don't know the details though. For what I read so far. It seems that that Aris can handle IP Passthrough and Default Server, and as I understood the latter is like putting a host in DMZ. Perhaps the people in the forums can help with that.

@JKnott They could set dummy addresses (albeit not practical) not needing to know if they're assigned to a host or not. But it's academic at this point. It's technically possible but not practical. It does require the ISP to delegate the reverse records but my ISP is not going to do that.

@lohphat said in pfsense and IPv6 default behavior: I understand that and agree however multicast is intrinsic to IPv6 not optional with IPv4. IPv6 internal consistency of multicast groups replacing broadcast and other functionality means that it should either be enabled fully or a clear, clean setting to enable multimedia multicast. For stuff directly on the LAN, multicast works fine and pfSense is not involved, except for it's own needs. It's only when you go beyond that you have to enable it. This is the same for every just about everything. By default, firewalls block everything coming in.

@Derelict Would you believe it. That was the last place I never check. Doh ! Thanks.

@Derelict I think it's a CPE issue not Spectrum, but that's just a guess.

@johnpoz said in Can`t get provided /56 prefix: Plus multicast .... Ok, so I'm saved by the fact that DHCP traffic is passed upfront, before the bogon rule list (example). Thanks for the explanation.

just installed a pci network card, and RA is working out of the box :) thank you resolved.

@johnpoz It's a Lenovo E520 ThinkPad. It's whatever driver comes with Windows 10, as I haven't installed any other. It originally came with Windows 7. I just took a quick look and didn't see any I could download.

@tomeq82 well aware that interfaces may be set to prefixes longer than /64 in certain router-to-router links, etc. That is not what is being discussed here. Interfaces with hosts on them need to be /64.

Sounds to me like the ISP has implemented a brain-damaged provisioning. I'd tell them to fix it.

I have pretty much the same kind of setup provided by a local ISP. I found out that ISP providing static IPs is not so common practice. At least among PFSense forum users. I built up two different setup ("automatic" and "semi-automatic"). Not 100% sure those are according to best IPV6 practices, but I tried to do everything by the book. Not just something that happens to work. Hoping you get your IPV6 network to work and/or people here are able to assist you on that. Ax.

@Derelict You cannot SLAAC a routed prefix. Ok, this is clear. There is nothing like that on the configuration page either. You either set it statically or with DHCP6. Yep, done that both ways. Both methods work without issues. You also seem to be confusing assigning an address to a device out of that interface prefix I think I understand that, but that could to be true. The configuration described earlier works and it does what I expect it to do. I don't think it differs much what johnpoz suggested. Ax.

Answering my own question: This post: https://forum.netgate.com/topic/112802/disable-accepting-ra-advertisements-on-an-interface has a suggestion to edit /etc/inc/interface.inc and add a minus ( - ) in front of the accept_rtadv for the WAN interface. This fixed the FC00:: problem. Had to uncheck the "Wait for RA" option in the DHCP6-PD section. Telmex also requires the DHCP6-PD queries to happen over IPv4. A side note: Telmex IPv6 uses a smaller MTU to stay stable. I used 1412 thought 1467 may work as well. Discovered this when ping -6 worked but TLS would have broken/missing packets in Wireshark.

The best thing to do is get information from your ISP. Perhaps they have a beta program or something that would result in more information. You can see what PD you are getting by saving the DUID in System > Advanced, Networking [image: 1566154620163-screen-shot-2019-08-18-at-11.56.41-am.png] Then enable the Debug mode on WAN in the DHCP6 Client Configuration area, setting whatever secret sauce your ISP requires. This is what I use for Cox Las Vegas: [image: 1566154797177-screen-shot-2019-08-18-at-11.59.41-am.png] Your ISP might require something completely different. Then look at Status > System Logs, DHCP and set the filter to process dhcp6c You will see exactly what is happening. My PD looks like this: Sep 1 03:55:10 dhcp6c 44071 update an IA: PD-0 Sep 1 03:55:10 dhcp6c 44071 status code for PD-0: success Sep 1 03:55:10 dhcp6c 44071 update a prefix 2600:dabb:ad00:bc00::/56 pltime=34359824768, vltime=34359824768 Sep 1 03:55:10 dhcp6c 44071 executes /var/etc/dhcp6c_wan_script.sh Sep 1 03:55:10 dhcp6c dhcp6c renew, no change - bypassing update on igb0 Sep 1 03:55:10 dhcp6c 44071 script "/var/etc/dhcp6c_wan_script.sh" terminated If you want to try new settings just increment the DUID-LLT, save, and Edit/Save WAN. That should result in a new renewal using a new DUID so it should all be fresh. Your ISP might have settings that don't like changes like this. Only they know. Ask them. We cannot know what they require here. Again, only they know.

Are the addresses being assigned out of the same /64 or /64s from different VLANs? Perfectly normal and expected for there to be multiple if not several IPv6 addresses on an interface, but they should all be inside the interface prefix. We know pfSense is tagging the traffic properly. The problem is that switch doesn't properly isolate broadcast (multicast) domains or is misconfigured. I would never use one of those switches in any network that mattered to me. I would use it for test stuff (like a tap, as mentioned) or throw it away.