To the time it takes.. You understand you can copy a rule right, and then just need to change the interface and it moves over to that tab.. So creating your rule once and then copy to multiple vlans only takes a few seconds.  And if you used alias to list your ports for your dest and even your dest IPs.. You just need to modify those and all rules using those would auto get updated..

@johnpoz: Where do you read that?  That does not say anything of the sort… I can put rfc1918 and public on a box as well - doesn't mean you should... You seem to think its ok to run multiple layer 3 on the same layer 2, which is exactly what that is..  Which is not the case, be it you can do it or not.. Who says those are the same interface?  It could be a back lan, or a storage network.. If he wants to run ULA on a vlan interface, and Global on another vlan - sure ok... Pretty pointless but yeah you can do it.. I could for sure see it as storage network say..  This should be a different L2.. Well, here's what RFC 6724 says: 1.  Introduction The IPv6 addressing architecture [RFC4291] allows multiple unicast   addresses to be assigned to interfaces.  These addresses might have   different reachability scopes (link-local, site-local, or global).   These addresses might also be "preferred" or "deprecated" [RFC4862].   Privacy considerations have introduced the concepts of "public   addresses" and "temporary addresses" [RFC4941].  The mobility   architecture introduces "home addresses" and "care-of addresses"   [RFC6275].  In addition, multi-homing situations will result in more   addresses per node.  For example, a node might have multiple   interfaces, some of them tunnels or virtual interfaces, or a site   might have multiple ISP attachments with a global prefix per ISP. Notice it says "multiple unicast addresses".  That implies more than two, so we can rule out just a unicast & a link local.  It also mentions multiple scopes (unique local replaced site local).  Clearly the IETF intended there be multiple routable addresses on a single interface.  It also mentions multiple ISPs & prefixes.  These are things I've mentioned were possible with IPv6.  You may think it's "borked", but you're at odds with the IETF.  They seem to think there are valid reasons for these things.  I have also read pretty much the same in the Cisco book "IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6" 2nd ed..

I have removed pfsense from the equation and there is still packet loss so seems to be a strange coincidence with an ISP issue.

I really appreciate your help John. With regards to your comments about ipv6 dns and / or global gateway setup, I can't find any reference to these in the guide, so probably the reason why they aren't setup. I've just hooked up my Asus AC86U to my modem, bypassed my pfsense device, and configured my HE tunnel on the AC86U and I've got ipv6 connectivity straight away. I know I've followed the pfsense guide for setting up an HE tunnel on my pfsense as accurately as I can, but for some reason it just won't work. I don't see why it's so easy to setup on my AC86U yet so difficult on pfsense., it's certainly beaten me. As I said before it's not important for me to get up and running, just would have been nice to have it, so I'm going to leave it for now. Perhaps when I have more time I'll rebuild pfsense and try again then, perhaps my initial setup wasn't correct. Thanks again for all your help, I do appreciate your efforts.

If you want a device to talk to a global address it needs a global address. Not quite.  It can, provided it doesn't have to go over the public Internet.  PfSense can easily route between global and ULA addresses.  I have done that here.  This is no different than using RFC 1918 addresses on IPv4. But your client will have to have one if you want to be able to talk to stuff via that linklocal transit your using upstream of pfsense. Here we go again.  Global addresses are not normally used for routing.  As I pointed out recently in another thread, routing is done using link local addresses between routers.  Check your routing table to verify.  You can also capture router advertisements to see what address is provided for routing.  However, those global addresses are definitely useful for management and diagnostic purposes. But sure it is possible to do such routing with linklocal, or use a ULA as your transit IP scheme, etc. Once again, link local addresses are always used for routing, unless specifically configured otherwise.  Take a look at your routing table in pfSense and computer operating systems.  You will see link local addresses.  For example, here is the default IPv6 route on the Linux computer I'm currently sitting at: default via fe80::1:1 dev eth0  proto ra  metric 1024  expires 46sec hoplimit 64 pref medium As you can see, it's a link local address, as provided by pfSense.  Further, it's entirely possible for a router to have the same link local address on multiple interfaces.  It's only necessary to have unique link local addresses for devices on any given link.  This would not be possible with a routable address. As I mentioned in other threads, many things in IPv6 are different from IPv4.  You need to update your understanding of this.  There is one other difference shown in that default route that goes to another disagreement we had a while back.  Do you see that "medium" at the end of the line?  That refers to router priority.  By changing that, you could have multiple default routes, possibly via alternate ISPs, simply by assigning different priorities, as pfSense can do.  Then should the primary default route fail, another can then be used.  This is part of IPv6 and can only be accomplished in IPv4 by using a first hop redundancy protocol.

Now I have to do some special port forwarding, aka "connect to IP x.x.x.x port YY" for this backup and "connect to IP x.x.x.x port ZZ" for the other backup. Again, not a huge deal but would be nice to have IPv6. That's an excellent reason for moving to IPv6 as much as possible.  NAT brings a lot of problems, such as yours where you need some other means to select among multiple computers running the same protocols.

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.