I created ipv6.getmyip.com to test my IPv6 connectivity.
It only has an AAAA record and it only returns your IPv6 address if your IPv6 stack is working properly (otherwise it doesn't return anything).
It works great with curl (which is the main reason I built it).

In case anyone encounters the same problem, I happened upon the solution by chance months later while configuring NTP on a multi-homed Ubuntu server and wanted to post it here for posterity's sake.
My main LAN subnet obtains an IPv6 address via WAN DHCPv6 prefix tracking and advertises it via RA's. Because most of my other VLAN's use ULA's and eschew dynamic GUA's, I have the firewall set up with static IPv6 addresses which get advertised to each subnet. For consistency's sake, I wanted devices on my main LAN to obtain a ULA as well as a GUA, and had configured the RA's to include a ULA prefix of fd00:172:28:198::/64. Unfortunately, since pfSense doesn't currently support multiple IPv6 prefixes per tracked interface ([https://redmine.pfsense.org/issues/5999]) this means that the client ping was going out through it's ULA, hitting it's destination, and then being routed back through the firewall. Since the firewall didn't itself have a ULA on the LAN interface, it had no route back to the client, and the traffic was dropped. Removing the ULA prefix from the RA's on that interface resolved this issue.
If anyone has a solution for allowing both static and dynamic IPv6 addresses on the same interface while avoiding the issues I encountered here, I'd appreciate the suggestions.

Ok, so it appears I was getting a PD, but I wasn't seeing it in the logs because the DHCP6c debugging wasn't turned on. After turning it on, it was showing me the full PD of /60 being given to me and then the router handling the tracking.
So, what I have done is enabled tracking only on one of my 3 vlan interfaces (the guest). Then after receiving the prefix, I can set statics on the other interfaces that I care about.

The default deny rule logs by default.
There is a checkbox to stop this logging but it will affect ALL traffic hitting default deny not just the traffic you are specifically asking about.
A specific rule higher in the list can block the traffic, not log, and processing will stop.
The default deny rule (and the logging) will never be hit/processed.

I have exactly the same issue. SLAAC on the PPPoE WAN interface seems to work, but I can't ping6 any host on the internet. Also, clients seem to not getting RA's. But before 2.4.4 I was able to ping6 google.com when I logged in to pfSense via SSH. Don't have a solution unfortunately.

@xayumi said in IPv6 unable to access internet on LAN interface:
@derelict
Hi yes, I understand, they just assigned me a ipv6 address with mark /64 on my WAN, instead of a ipv6 and /64 subnet to me.
I am new to IPv6 just really does spent some hours to figure it out!
Thanks for your help! NAT for IPv6 is current a solution for me :)
One thing a lot of people have to figure out is the WAN address is not used for routing. It's a /128, which means it's to identify an interface only. It cannot be used to communicate with another device, without going through a router (pfSense). On IPv6, link local addresses are normally used for routing. Link local addresses start with fe80.

@earlish Hi,
Do you still use pfsense?
I'm facing the same problem as you using AsashiNET provider.
Only the WAN gets the prefix, LAN It is not getting anything.
Please let me know if you found a solution because my provider doesn't support PPPoE for IPv6.
Thanks in advance.

Hi,
thanks for the quick response!
actually, I don't need IPv6, but, as we in Germany say, it is sort of a chicken - egg problem. If nobody uses it, then no services will be made available. If no services are available, no one will use it.
Anyhow, the German Telekom started DualStack quite some time ago, and I want to use, if only for the reason of it being the future, and no immediate need. I expect current devices to use it where possible. But you are right, no necessary need has arisen, yet.
To solve my problem: A guy in the german telekom forum asked the same questions, to which somebody else posted screenshots. They work perfectly for my setup. So I will leave the link here for documentation purposes:
German Telekom Forum
This setup does exactly what I want and it works without further config need.
All the best,
Thomas

I'm pretty sure that the only way this could be done in pfSense is with a virtual IP (Firewall > Virtual IPs) on the respective interface... but if your ISP ever delegates a different prefix to you, that virtual IP would need to be manually updated with the new prefix in order to function again.

A packet capture on that provider would be interesting to see.
One from a device that works and one that doesn't.
As has been said, it works great but every ISP IPv6 deployment cannot possibly be tested. Some reliance on the community is required. I, personally, know that dhcp6c works flawlessly with Cox Las Vegas and it works in my lab with DHCPv6 served by pfSense.
Unfortunately, ISPs take great liberties here and some seem to need special sauce to make it work. It's too bad ISPs are less-than-helpful when you try to get the recipe for THEIR SERVICE out of them.

@bimmerdriver said in Dynamic IPv6 Prefix assignment issue in xDSL users:
Netflix doesn't work over it.
So what - use IPv4 for that... While I am all for IPv6 and would love to see it move more mainstream... In the BIG picture its not here yet.. There is ZERO reason for you to have to use it, especially as a home user. Sure if you are hosting services to the public you should make sure your services are available on IPv6..
I have been playing with IPv6 for years and years and years.. Way before the root servers for dns were even on IPv6.. Was one of the first few hundred to get my sage cert from HE..
Sorry but there are ZERO reasons to deal with nonsense ISPs that don't get it... Use a freaking tunnel if you are forced to use the ISP you have.. My current isp doesn't even provide IPv6 - I don't give 2 shits because I have 5X the speed for 1/2 the price of comcast..
Multiple threads around here about blocking AAAA for netflix if that is your only concern.. Here is the thing I have IPv6 on my network, I even host to the public ntp on IPv6... Through a tunnel - my devices that I use to watch netflix.. I just don't enable IPv6 on them its that freaking easy.
Its great that you want to learn and play and participate in the future, which for sure is IPv6.. But there is nothing forcing you to use it... Please name 1 actual public resource that is you HAVE to have IPv6 to access... Just 1... Other than some odd ball p0rn fetish site (which there are 100,000 others to choose from)... Or maybe a few sites on the darkweb. How fast you think ISP would get their shit in order if users actually complained about IPv6 issues. Problem is the only ones that give 2 shits about it are people like you.. 1 in 1000, maybe 10000 of their users..
I would love nothing more to just use IPv6.. Sorry not here yet - I am pretty freaking sure I will be retired from the biz well before that happens.. So while I understand your grief - your ranting to the wrong place... Its not the router distro your using problem to fix a BORKED deployment from your ISP..
And to be honest, the few developers have way more important things to worry about than some odd ball ipv6 hack to help some users on some borked isp setup ;) As already mentioned if you want a fix or hack or whatever you want to call it to handle your isp nonsense... Then submit your pull request :)
Or just do the simple thing and use a HE tunnel to get your IPv6 fix...
Or get your own IPv6 space from your local RIR, and get an ISP that will route it to you.. Expecting your typical residential ISP that has billy wanting to download porn and stream internet really doesn't give 2 shits about proper IPv6 deployment nor do they hire the appropriate skilled level engineers to deploy it correctly..

It says unless your running forwarder/resolver.. Prob could be worded a bit more precise - or actually check to see if listening on actual interface if you have strict set.
Normally people that run resolver/forwarder want their dhcp clients to talk to pfsense. This is what like 99% of use cases (number just pulled out of my ass <grin>)
If you have a lot of interfaces pick the way you want to go about it that is least amount of work ;)
I will try and duplicate so can put in request to have wording updated, or option changed so that if strict and not bound to interface don't hand out pfsense IP.

@derelict Thanks for your reply. This ISP has made some of possibly questionable implementation decisions in their network.
First, the DHCP before RA feature was tested on this network. Their edge routers will not respond to an RS until after the DHCP solicit/advertise and DHCP request/reply sequence is complete. After that, the edge router will respond to an RS with an RA. I just fired up wireshark and captured some packets. The router lifetime in the is 4500 seconds (75 minutes), the reachable time is 0 and the and the retrans timer is 100 ms. These values are also used in the unsolicited RA messages, which leads to another interesting implementation decision.
Second, the time between the unsolicited RA messages ranges from approximately 15 minutes to approximately 30 minutes. I determined this by capturing RA messages over several hours. This is longer than usual, but according to RFC 2461, MaxRtrAdvInterval is 1800 seconds, so they are operating within the allowable limit.
I also looked at the DHCP reply. T1 and T2 in the IA for PD are 300 and 480. The preferred lifetime and valid lifetime in the IA Prefix are 600 and 900, respectively.
The above are from my router which is working properly.
Apparently on some fiber networks, the unsolicited RA messages are not being sent at all. This is a known problem that they are working with the router vendor on. I'm trying to help someone else figure out why pfsense is behaving as I described above. Based on these timers, I would think it should work for 75 minutes (or whatever the prefix lifetime is) until the prefix expires, then it should stop working. However, it seems to fail once after initially getting a prefix, then if the interface is restarted, it keeps working. I don't understand why it would keep working if prefix expiration is causing it to stop working after the interface is started. Maybe something else is going on. I don't have packets captured from this network, but I'll try to get some.

@alankeny said in Splitting a static /48 from Mediacom into subnets:
With their static IPv6 allocation, the WAN side is basically a bridged network that can have 1,208,925,819,614,629,174,706,176 IPv6 hosts on it, and that's the only configuration option available.
That's nonsense. A /48 is not usable in that manner. It's supposed to be split up into /64s, which are what is used on a LAN. For example, I have a /56. One /64 is used for my main LAN, a 2nd for a test interface and a 3rd for my VPN. MY ISP uses DHCPv6-PD to provide my prefix and WAN interface address. As Derelict mentions, take a look at what's on the wire. You might want to see if you can talk to 2nd level support. Maybe they might have a clue about how IPv6 works.

@pete35 said in OSPF6 over IPv6 VTI Tunnel Interfaces:
some months ago i run into a similar problem. It looks like, that all the tunnels (openvpn, ipsec) doesnt provide the Link Local adresses of IPv6. OSPF needs them to work. I think, assigning the RFC4193 Address to the tunnels doesnt help in this case.
Fire up Wireshark or Packet Capture and see what's actually happening. IIRC, OSPF announces itself via mulitcast. There should also be Neighbour Advertisements advising of the address in general. Do you see those? Also, the tunnels don't provide the link local addresses, the end devices do. However, link local addresses will not be routed. Are there any routers in between? It must be a direct connection between OSPF routers, which could include a tunnel.

@heartofrainbow said in IPv6 not working on LAN:
The WAN and LAN IPv6 addresses have the same prefix
Doesn't work that way..
your so called passthru mode would be a bridge.. Why don't you call your isp and ask what they support or what is your ISP so we can look it up.
What are you wanting to do with IPv6 exactly? If you don't even know how your ISP does it, why does it even matter... If you want IPv6 - just get a free tunnel from HE.. Then you can have a /48 and clickity clickity done... Doesn't matter what your ISP supports or doesn't support.

@eternalglue said in Ipv6 setup for Telus:
This is what worked for me:
Navigate to Interfaces -> WAN
IPv6 configuration should be DHCPv6
Under the DHCP6 config, select “Request only an IPv6 prefix”, prefix size 56, “Do not wait for a RA”, and “Do not allow PD/Address release”.
Under the DHCP config, select advanced configuration and add “supersede dhcp-lease-time 1800;” under Option modifiers. I found this necessary to keep the IPv6 prefix working for longer than a few hours.
Under your LAN interface, select track interface for IPv6, and pick a prefix ID of 0. Other interfaces can use nonzero IDs but I found if I didn’t use zero I would eventually lose the prefix and pfsense wouldn’t recover.
You could also add some rules to allow the relevant ICMPv6 packets through the firewall.
Just noticed this thread about Telus. Telus has played with lease times quite a bit. Lately, at least for DSL, the lease time is 10 minutes, so you will see it renew every 5 minutes. This happens in the background, so it makes no difference to the service.
The only mandatory settings for Telus are: request prefix only, /56 prefix, and do not wait for ra.
It's not strictly necessary to use do not allow pd release, unless you want the dynamic prefix to be as stable as possible. Telus will delegate the same prefix to the same DUID, unless another system requested a prefix while there was no active lease on it. The only difference do not allow pd release makes is that the prefix won't go back into the queue immediately, it will go back in after it expires. That's 10 minutes (BFD). In practice, if you keep your system running, the prefix won't change. As long as you keep an active lease on it, the prefix will stay the same.

@mikekoke said in DHCPv6 problem with Netgear router:
Richiesta scaduta.
Request timed out - what are you rules.. If you don't allow icmp then no you wouldn't be able to ping..
Do a traceroute - does it actually send it to pfsense IPv6
So what network/prefix did you put on your lan side network?
You sure your actually even surfing via IPv6?
What does say https://test-ipv6.com/ show you when you go there from a client

That is not your whole ipconfig /all output..
A widows box will have teredo, 6to4 and isatap interfaces listed... Unless you took the time to clean them up... They will attempt to get IPv6 and tunnel out of your ipv4 network..
If you want to play with IPv6 - your ISP doesn't have to support it.. Just get an HE tunnel.. they are FREE and and will give you a /48 to play with.. And they have certification program to walk through and help you learn the stuff you need to learn to correctly setup IPv6.. My last isp support ipv6 - well kind of.. It was way more trouble than it was worth... So I ran HE tunnel.. And my new isp doesn't have any ipv6 support.. Still have my same /48 because I was using tunnel.. But then again I only run it on the devices I want to run it on, for my own amusement and testing.. There is not actual "need" for it.. If that is something you want to do to learn about IPv6 than yeah lets go - lots of learning to do.. Happy to help... But when someone doesn't know the difference between a A record and AAAA... maybe they quite ready to ride the IPv6 train correctly.
Here is the thing - IPv6 for sure is the FUTURE... But no matter how much some people want it... IPv4 is not going away any time soon.. For the home user, sorry there is no actual reason they need to run IPv6.. And to be honest until such time that they can commit to learning how to correctly configure it.. Its easier to turn it off.. Some people don't like that approach... But sorry thing tunneling out of your IPv4 network just to use a protocol that is not actually needed. Name a internet resource that you NEED, that you can not get to unless you have IPv6 and then we can talk about IPv6 being a "required" thing...
And in the corp world - yeah the cost of transition on the lan side when they have all the IPv4 space they need with rfc1918.. Sure they can put their public facing stuff on both IPv4 and IPv6 that is for outside access.. But on the internal corp network - it cost money to do this transition... Until there is a financial reason - corp is going to drag their feet screaming into the IPv6 world..
So there is PLENTY of time to get up to speed on IPv6.. Nothing saying you need to take on that challenge right now.

Ok, thank you, sorry for duplicated theme.
About :3:: - it really not existing IP at all, but real if remove this part. I sure, because have ntopng installed and have configured monitoring for long time storing. For me this strange situation.
P.S. This clients is Win10.

@edooze said in A looped back NS message is detected during DAD:
It is to do with pfSense, because the error is in pfSense. If the resolution is not, so be it, but that's what we're here to find out.
I suggest you read up on how IPv6 duplicate address detection works. With it, a device is supposed to send out a NS to see if any other device is using the address it wants to use. If that address is in use, the device will then have an error condition to deal with. It has nothing to do with pfSense.

So what does the config on pfSense look like vs your external server config? There must be some difference in the formatting or naming of the option to explain what is happening.
Look in /var/dhcpd/etc/dhcpdv6.conf

@roally That's more than I see in my file. I am currently setting up a box with an older version of pfSense. 2.3.4 worked for all the time and I'll see soon whether there is a difference. If it would work, I'd know what is supposed to be in radvd.conf...

It looks like FreeBSD is able to create IPv6 fragments (45 fragments created), but i have no idea where they are going to in case of the WAN interface.
netstat -s -p ip6
ip6:
402474348 total packets received
0 with size smaller than minimum
0 with data size < data length
0 with bad options
0 with incorrect version number
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 fragments that exceeded limit
0 packets reassembled ok
614833 packets for this host
401766863 packets forwarded
2 packets not forwardable
45 redirects sent
746064 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
0 output packets discarded due to no route
0 output datagrams fragmented
45 fragments created
0 datagrams that can't be fragmented
0 packets that violated scope rules
0 multicast packets which we don't join

@jimp said in TunnelBroker - Should "Enable IPv6 over IPv4 tunneling" be enabled?:
No, that is not needed. It's for passing IPv6 encapsulated traffic from your WAN through to some other device behind the firewall, so that the other device can handle IPv6 routing.
https://www.netgate.com/docs/pfsense/book/config/advanced-networking.html#ipv6-over-ipv4-tunneling
Thanks

@beremonavabi said in Three Entries in NDP for Some Devices? [ANSWERED]:
Unfortunately, I don't even have a name for what I'm seeing so I can't look it up.
https://en.wikipedia.org/wiki/IPv6#SLAAC_privacy_extensions

I got an e-mail from Hyperoptic today saying that apparently IPv6 is disabled pending a firmware update they are currently working on... not sure if was just being fobbed off but that was enough discouragement to make me leave playing for a few days. I will try again then. I wonder if this is a firewall issue really but I tried a bunch of frankly scary things there too and nothing helped.

@jimp Thanks, this time I have edited the file /etc/inc/filter.inc as it appears here: https://redmine.pfsense.org/projects/pfsense/repository/revisions/e9446f537051c7b536d0b3fbb5ebd00c3766001a/diff?utf8=✓&type=sbs
/* Do not form an invalid NPt rule.
* See https://redmine.pfsense.org/issues/8575 */
if (!(is_subnetv6($srcaddr) || is_ipaddrv6($srcaddr)) ||
!(is_subnetv6($dstaddr) || is_ipaddrv6($dstaddr))) {
continue;
}
the system patches package it seems that it is not ready yet, but with that edition by hand it works great for now and in version 2.4.5 it will be fixed.
Putting a prefix other than 128 does not work in the environment I use, the rule is created, but it does not work as expected.
Thank you