Let's see if I get any traction with this post: https://answers.microsoft.com/en-us/msoffice/forum/msoffice_sfb-mso_mac-mso_o365b/skype-for-businesslync-services-dont-appear-to/c204b511-8b0b-4338-924e-729603627413

Again I hear you… So? Read https://tools.ietf.org/html/rfc7404 I just did.  That article points out why you'd need a routeable address for management purposes, not routing.  Given that any interface that has a routeable address would also have a link local address (even my OpenVPN tunnel has a link local address), it's not an either/or situation.  Use a routeable address for management and link local for routing.  Regardless, a routeable address is not necessary for routing in IPv6.  Incidentally, some of the things in that article might make a case for using ULA and not global addresses.  ULA provides a routeable address that's not exposed externally.

@kpa: On top of that if you have only your normal IPv4 WAN connection and an IPv6 tunnel from HE (why would you even consider using another IPv6 connection in addition to your HE tunnel?) I'm not the person you were replying to, but speaking for myself, I see things like this on my HE tunnel all the time: Feb 12 14:00:45 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Alarm latency 33734us stddev 19534us loss 21% Feb 12 14:00:58 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Clear latency 33166us stddev 19392us loss 20% Feb 13 10:51:11 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Alarm latency 28309us stddev 9549us loss 22% Feb 13 10:51:12 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Alarm latency 605795us stddev 2656495us loss 19% Feb 13 10:52:07 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Alarm latency 137034us stddev 756717us loss 12% Feb 13 10:52:11 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Clear latency 33363us stddev 17753us loss 7% My homelab setup is much simpler than pbnet's, in that right now it's just one IPv4 through my ISP, and one IPv6 tunnel via HE.  But due to the regular latency spikes, I'm considering trying to figure out how to set up some kind of multi-WAN thing, using my ISP's own IPv6 as the other uplink.  The issue is that my ISP's IPv6 is hilariously terrible, so I need to keep HE's tunnel as an option.  I think multi-WAN connections like this should be able to either failover or load-balance when the latency gets high enough to set off alarms, it's just I haven't had the time and energy to make the attempt. So anyhow, that's just one example of why somebody might need a connection in addition to the tunnel.

@al: If accepted this fix is likely to enter pfSense v. 2.4.3. Excellent!  I'm running 2.4.2 so moving to .3 is totally an okay solution for me. I shall not rule out that something else could be wrong in your specific setup. Are you able to see the DHCPv6 leases in the menu of Diagnostics under the menu item NDP Table? I can see the dynamic lease that I was expecting to see, yes.  So it's probably due to the parser problem that your patch fixes.  Since it's a small network, I can get on each client and find out their DUID, and create the static mappings manually. I don't see any other DHCPv6 leases at all, though; neither dynamic nor statically mapping.  The rest of the NDP table, other than the router itself, are just the link-local addresses.  (So they're… not even asking for an address?  I would expect the Android phones to just languish in IPv4 until I get around to turning on SLAAC, but the laptops ought to be sending v6 solicitation packets... unless Windows 10 gets that wrong too...  They all seem to be making use of IPv6 even without the DHCPv6 leases, so this approach to a more thorough control of the local network is clearly incomplete.) Sorry, rambling aloud now.  Going to call the problem solved, and then turn off the dual stack until I can figure out a better way to do this.  Maybe use only ULAs combined with prefix translation, if that's even supposed to work with a tunnel provider on the outside...  I need more sleep. Thank you for your help, al!

The WAN side has nothing to do with the LAN side.  In fact, you don't even need a public address on the WAN side, as routing is usually done using the link local address.  In fact, routing doesn't even require any address. The route can be specified by a point to point interface.  However, your WAN IP address could easily be one out of a /64 prefix that's separate from your LAN prefix.  Having the WAN address within the LAN prefix wouldn't work.  I'll describe what I have here, though I'm no longer using a tunnel.  My WAN port has an IPv6 address and I also have a /56 prefix, which is then split into individual /64s.  The WAN prefix is significantly different from either my /56 or any of my /64 prefixes, so there's no conflict between the WAN and LAN sides.  Any address that's not within my /56 is elsewhere.  I don't care whether they're on my ISP or not, they're just elsewhere and pfSense sends packets for them out the WAN interface to my ISP.  Beyond that, I don't know or care what happens.  It should be the same with you on Start.  I suggested using traceroute, as it will show whether the packets actually leave your pfSense firewall or not.  If they do, the problem is elsewhere.  If they don't, it's with pfSense.

@JKnott: Does the prefix change?  If not, a MAC based SLAAC address is pretty much static.  On Windows there is also a random number address that does not change. Unfortunately, the prefix does change.  It is a unique use case, for sure.  DHCPv6 may be able to help us, if we work around its limitations in the GUI. On IPv4, we deal with the situation by putting each set of virtual IPs on a different NIC (along with a separate NIC for all outgoing NAT traffic).  This solution lets us change our set of public IPs immediately with no changes to the LAN addressing.  With IPv6 port forwarding, this could be done for IPv6 using site-local addresses for the destinations (DHCPv6 or static).  Otherwise I'd need to configure the DHCPv6 server to assign correct world-routable addresses with static mappings to each host.  The problem is that it's not easy to change the DHCPv6 static mappings in bulk, and the other records would be deleted, not deactivated. In any case, it's only public services that I want to apply port forwarding to.  All outbound Internet traffic would be through a routed subnet with no NAT.

Without going into the details, did you check that System / Advanced / Networking / Allow IPv6 is enabled? Interfaces / WAN / Request a IPv6 (global routing) prefix is checked? The Interfaces / WAN / DHCPv6 Prefix Delegation size is set to 56 (or whatever the ISP offers)? Interfaces / WAN / Send IPv6 prefix hint is checked? Services / DHCPv6 Server & RA / LAN / Router Advertisements / Router mode is set to unmanaged? Make sure that ICMP is allowed for IPv4 and IPv6 (though endpoints might still block IPv6 ICMP by default) This is essentially a generic guide, initially written for German Telekom, and described with more details somewhere else.

@wkearney99: … ... I'll leave ipv6 for another time. Know that you can have a 'real' IPv6 /56 on your network within 5 minutes : see what https://he.net can offer you right now - for free. pfSense has all the logic already on board, it just needs to be activated. I'm using he.net for years now, as my ISP promised IPv6 since "2000" - and they just started to upgrade their boxes with some crappy IPv6 /64 support (to "small" for me). he.net is the very next best thing, and very often far more better as what ISP's actually deliver.

@bawitdaba: It looks like for some reason on my LAN interface I had checked "Block Bogon Networks" which blocked all Link-Local IPv6 Traffic such as DHCPv6. My clients pull addresses now from DHCPv6 yay! Thanks, just got bitten by this one myself, trying to protect the internet from my devices going bad ;(

Do you know what settings your isp requires? The edge router may not even provide an ip address for the wan. You must request a prefix size that is supported. The edge router may only support one size. It may require you to only request a prefix, not a prefix and an address. If your router isn't asking for a supported configuration, nothing will be delegated.

@Ofloo: never mind spoke to soon :/ The port has vlan tags of several vlans enabled so not quite sure what you're refering to when you're talking about retagging the traffic, .. but i think what you're saying i already did. What is connected to that port? Is the connected device VLAN aware? Is it setup for multiple VLANs? Is this happening on more then one port with more then one device/client? Best bet is to use wireshark on a port that has this issue and look at the RA packets, confirm they are tagged at all and correctly for the VLAN for the subnet being advertised, if they are then set your sights on the client/s.

would there be any issues due to the built-in ethernet switch? –jason

@m3nt0r123: I have a simple home network. Just a handful of devices with an AP providing WiFi. I realized that a number of devices are using IPV6 instead of static IPV4 addresses I assigned. I read through the documentation and am thoroughly confused and need some guidance. Pure IPv6 devices exist when you force them to use only IPv6. I guess you didn't,, so they all ask (DHCP) for an IPv4 and, if they can handle it, an IPv6. @m3nt0r123: I want to ensure my traffic shaping (PRIQ) works as intended and that my packages function as intended as well. I have floating rules for traffic shaping to prioritize traffic but imagine those rules are not applied since an IPV6 lease is assigned to the device rather than the static IPV4. Can't tell, never shaped anything in my life. @m3nt0r123: Should I disable IPV6? Maybe, for the time being. But guidance isn't what you need. IPv6 is a huge subject. As "IPv4", you'll have to go through the "learning phase". @m3nt0r123: Am I able to apply PRIQ to IPV6? Is it already applied? Never heard that shaping, or "PRIQ" is IPv4-only. @m3nt0r123: Should my other packages work as expected (pfblockerng, suricata)? pfblockerng will work well - checkup with their support. But you should know that that the concept of "lists with bad IPv6" will never work out in the future, it's simply to big. Using DNSBL still works. suricata is more an packet inspection tool. These are still the same. The "IPv4" or "IPv6" is just the envelop that transports the packet. The thing is : as a firewall operator you do not have a choice, you should become friends with IPv6. Remember : a firewall handles IP packets. And IP means : IPv4 or IPv6, knowing that IPv4 will fade out (in the next decade so you have some time ;))

Agree, you are right, all the services that depended upon a static IP long ago moved to AWS, so I should just ditch it, good thought. Esp since Route53 works beautifully with pF's dynDNS updater.. Is there nothing that pF won't do (better) ?

Thx for all answers.

@JKnott: You could also use Packet Capture or Wireshark to see if pfSense is actually sending out RAs with the wrong gateway, or if they're coming from elsewhere.  You have to filter on ICMP6 to capture them.  If you use Packet Capture, you may want to download the capture file and use Wireshark to examine it, as Wireshark provides more info than the list shown in Packet Capture. You were right. I wiresharked it and found out that my old EdgeMax router was sending out router advertisements. Factory reset the darn thing and all is right on the network. At least, it wasn't DNS.  Thank you for you help.