1

I've recently got IPv6 native (dual-stack) working from my ISP to my home network. "Working" means that I negotiate an IPv6 connection, gateway, and a delegated /56 prefix. My LAN picks up this prefix (putting it in the 0x1 subnet, though using 0x0 subnetting didn't change the behaviour reported) and neighbour discovery seems to be doing all the right things. Visiting IPv6 test sites seems to show all is as expected with respect to the host and DNS64 and so on. That is, most test sites know that I'm coming from an address from a block provided by my ISP.

I'm using a home-made appliance running OPNsense (which is essentially "hardened" FreeBSD with a web config).

All seemed to be well until someone on the network tried their usual Zoom meeting using the Zoom app. If the host running Zoom isn't going through a VPN (i.e., unlike my corporate laptop, which goes through a Cisco VPN that is essentially IPv4 only to the rest of the world) then Zoom spins for a long time until it complains it cannot connect. The alternative "web" app works. If I recalled correctly, the error is "104103", which is a general connectivity error.

After some investigation I determined it was native IPv6 that was the problem on Windows 10 and recent stable Debian. An older Mac OS client seemed to work, but I have a feeling it switched to the web-based Zoom app ("Join from browser") on failure automatically.

Disabling IPv6 on the LAN such that none of the "temporary" non-local IPv6 addresses are available for outgoing connections and the Zoom app works. It seems to prefer a NATted IPv4 address over a non-NATted delegated IPv6 address.

I'm willing to admit this is a problem with config on my side, but I'm at a loss to explain why IPv6-to-Zoom isn't working when everything else seems to work. I've tried:

  • Allowing all traffic through the firewall without any filtering. OPNsense uses BSD pf which I'm pretty familiar with, and logging shows lots of unrestricted traffic from the LAN host (using whatever "temporary" INET6 address it chooses) going to Zoom and AWS nodes (e.g., ec2-3-213-157-163.compute-1.amazonaws.com.) where I presume Zoom is hosting their services. I never see any traffic back, though -- blocked or otherwise.
  • Creating rules specifically allowing the Zoom IPv6 /40 net (even though I never see that incoming traffic, as above.)
  • Removed all Google and Cloudflare DNS refs used by the edge box and defaulted to using my ISP DNS. (This was mentioned in a similar report about Zoom in a Reddit post. Unlikely, but I did rule it out.)
  • Confirmed that the IPv6 addresses for the edge box itself (on both the WAN and LAN side) and the temporary address used by the host where the Zoom client is running are reachable via IPV6-ICMP. I specifically allow IPV6-ICMP Echo Requests as well as all of the required RFC-4890 IPV6-ICMP traffic on the firewall. I do not use "unique" addressing as per RFC-4193.
  • Reviewed WAN NIC settings and MTU, in case this was a problem with serious fragmentation I wasn't seeing on this side of the WAN. I can ping6 packets large enough for any IPv6 traffic. Various NIC config had no effect on the problem.
  • Configured the PPPoE WAN to not accept an IP for the WAN device itself. I also tried to ask for a different prefix, but my ISP only gives me a prefix of /56. Whether I subnet that with 0x0, 0x1, or 0xFF it makes no difference.
  • In desperation I configured the LAN to use SLAAC instead of "track interface" (which is basically DHCP6 and RA and NDP) in case my ISP was doing both. (Zoom works in this case, of course, because my LAN never gets any IPv6 addresses.)

All these tests are being done via Zoom "test" meetings on Windows 10 or Linux.

I've run across at least two other reports online where otherwise correct-seeming IPv6 native doesn't work specifically with Zoom. I see nothing on their support site about this other than general firewall rules. I just don't see evidence this is a firewall problem.

This feels like a routing issue, where the temp INET6 address used by LAN hosts passes the firewall (state-fully) and reaches AWS or Zoom, but the expected replies are just not coming back somehow. This feeling is based on the fact that I see my net try over and over with different AWS addresses (and, obviously, a different source port) because there isn't ever a useful reply. The firewall manages all these outgoing states until they eventually expire.

Perhaps Zoom doesn't like that any reverse lookup will not return any actual host or domain name? Even if it did, I have a completely different external domain name at the firewall, and it is only used as a destination for some special A records (and no AAAA records). One main difference is that the NATted host with IPv4 is a static IP with some A and CNAMEs associated with it. This is not the case with any non-NATted IPv6 traffic.

Maybe someone else has this problem, too? Maybe someone with more INET6-fu has some idea how I could dig further into this? I'd even like to hear from anyone who is using an IPv6 native, dual-stack network and can connect to Zoom using their app.

11
  • I don't use Zoom very often but the last time I used the native Windows Zoom program some weeks ago it worked well on Windows and my IPv4/v6 dual stack DSL connection. What router do you use? The last reviews I have read on IPv6 internet cable/DSL router often IPv6 was often a problem for the router firewall.
    – Robert
    May 17 at 16:20
  • @Robert, it's an OPNsense router. It, and my VDSL ISP, should be IPv6 ready, and I'm using the ISP defaults.
    – jdv
    May 17 at 16:30
  • @Robert, also are you sure you are IPv6 native? It has to be asked because it can be easy to be IPv6 internally, even with RA and NDP doing the right stuff, but that traffic not making it out of the net. i.e., do you get 10/10 when visiting test-ipv6.com
    – jdv
    May 17 at 16:33
  • I don't think there is anything special about "native IPv6" in general; most likely the Zoom servers do not like your IPv6 prefix specifically. You didn't mention which ISP you are using?
    – user1686
    May 17 at 16:37
  • 1
    @jdv I am getting 10/10 on test-ipv6.com. My provider assigns me a /56 subnet.
    – Robert
    May 17 at 16:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.