Quicken and IPv6

TedTheITGuy

Background: I am a network engineer and my home network is fully IPv6 enabled.

I noticed today that Quicken was taking an exceptionally long time to load today… like 10 minutes… it’s been taking a long time to load lately, but this was ridiculous. I did quite a bit of troubleshooting, reinstalling things, disabling things, etc., to no avail.

I just happened to look in resource monitor and noticed that Quicken was sitting there trying to access an IPv6 internet address over and over again. After a while, it would then finally connect to an IPv4 address and then Quicken finished loading shortly afterward.

So, for sake of troubleshooting, I disabled IPv6 on my PC. Suddenly Quicken loads almost instantly - as fast as you would expect with an NVMe drive.

I toggled IPv6 on and off a few times to be sure. When I turn OFF IPv6, Quicken connects to the IPv4 addresses and comes up almost instantly. With IPv6 turned ON, Quicken sits and spins while trying to connect to some IPv6 addresses out on the Internet, which don’t appear to be responding.

So, what is the problem with Quicken and IPv6?

Note: I have also submitted a similar report as a bug from within the application.

Rocket J Squirrel

I tried to reproduce this, but can't. My Resource Monitor shows Quicken opening IPv4 addresses only at startup.

Perhaps your DNS cache has a stale IPv6 address for one of the hosts Quicken connects to. If you haven't already, try flushing the DNS cache as a simple first step and see whether that fixes it.

TedTheITGuy

LOL, @Rocket J Squirrel, it wouldn't be the first time my network baffled an "off the shelf" consumer product, but this is the first time it has been a bit of plain software.

Earlier today, I realized that all of the "stuck" IPs were actually NAT64 addresses (basically IPv4 addresses in IPv6 format for hosts with no IPv4 access). I don't use NAT64 on my network, so I had to go hunting. After whipping out WireShark, I figured out I was getting these NAT64 IP addresses in the DNS responses for only a handful of hosts, but apparently coming from one of my upstream IPv6 DNS servers.

One of the problem hosts I identified was ip-api.com - it kept trying to connect to this IP over and over again. (Why so much geo-location Quicken?)

DNS -> Standard query response 0x59b4 AAAA ip-api.com AAAA 64:ff9b::d05f:7001

So, long story short, my DNS was essentially being poisoned. After a teeny bit of jiggery-pokery (technical term) I am no longer seeing these NAT64 addresses my DNS responses and Quicken launches at a normal speed with IPv6 enabled. EDIT: I am still receiving *other* NAT64 addresses, but those ones seem to actually *work*.

I guess I should have broken out WireShark sooner. However, I did expose an issue with Quicken's poor handling of unreachable IPv6 hosts.

Thanks for your responses!

Rocket J Squirrel

Glad you got it figured out. I'm no expert, but wondering why you were getting NAT64 addresses with IPv4 enabled, and why those addresses didn't work.

I also wonder about ip-api.com. I have no idea why Quicken wants geolocation, unless it's trying to decide which servers are closer than others.

I will take credit for guessing early on that the problem was DNS-related.

Rocket J Squirrel

I tried to reproduce this, but can't. My Resource Monitor shows Quicken opening IPv4 addresses only at startup.

Perhaps your DNS cache has a stale IPv6 address for one of the hosts Quicken connects to. If you haven't already, try flushing the DNS cache as a simple first step and see whether that fixes it.

Chris_QPW

I don't think going "pure IPv6" is a good idea, since the world is still very much mixed.
From my machine Windows 10 Pro, and Comcast as the ISP.

C:\Windows\System32>ping -6 yahoo.com

Pinging yahoo.com [2001:4998:24:120d::1:0] with 32 bytes of data:

Reply from 2001:4998:24:120d::1:0: time=35ms

C:\Windows\System32>ping -6 quicken.com

Ping request could not find host quicken.com. Please check the name and try again.

C:\Windows\System32>nslookup

Default Server:  cdns01.comcast.net

Address:  2001:558:feed::1

> google.com

Server:  cdns01.comcast.net

Address:  2001:558:feed::1

Non-authoritative answer:

Name:    google.com

Addresses:  2607:f8b0:4005:808::200e

          172.217.6.78

> quicken.com

Server:  cdns01.comcast.net

Address:  2001:558:feed::1

Non-authoritative answer:

Name:    quicken.com

Addresses:  151.101.2.127

          151.101.130.127

          151.101.194.127

          151.101.66.127

Notice no IP6v addresses. And just in case you think this is only Quicken's servers.

Server:  cdns01.comcast.net

Address:  2001:558:feed::1

Non-authoritative answer:

Name:    chase.com

Addresses:  159.53.84.126

          159.53.224.21

          159.53.85.137

          159.53.42.11

          159.53.44.60

          159.53.116.62

          159.53.113.168

C:\Windows\System32>ping -6 chase.com

Ping request could not find host chase.com. Please check the name and try again.

Chris_QPW

P.S. It has been point out that my terminology of "pure IPv6" is well basically nothing/made up.  I'm not a network expert, so that is what you get.  
But the point is that that certain machines won't have a IPv6 address and normally that would be almost immediately discovered, and there would be a fall back to IPv4.  For some reason that isn't happening on your machine.  This all way to low level for Quicken to control it.  Yes, Quicken may very well be using some old network libraries, but Quicken certainly doesn't know anything about IPv6 vs IPv4.

TedTheITGuy

@Chris_QPW That's the thing, I *am* a networking expert, and yes, my IPv6 fails over to IPv4, very quickly. My home network is built with enterprise-grade networking gear and supports IPv6 and IPv4 across most of my VLANs. FWIW, my network gets a 20/20 from "ipv6-test.com"

@Rocket J Squirrel - I actually did try flushing both the local cache AND the cache on my DNS servers. I even manually forced the use of remote DNS (Cloudflare and OpenDNS) with the same results. My local DNS supports both IPv4 and IPv6 and generally has a sub-millisecond response time for cached entries.

Regardless, I have applications using IPv6 and IPv4 side by side every day with no issues. Quicken is literally the only application that is affected this way.

If I get time, I may break out Wireshark to see the DNS exchange between Quicken and my DNS servers.

Rocket J Squirrel

Well, my next thought is that as a network expert, you have your networks set up in a way that baffles Quicken somehow.

I don't see Q looking for v6 addresses at startup. Below is what I see in Resource Manager. @TedTheITGuy , are you seeing v6 addresses in the connections list when filtered to qw.exe?

I can envision a data overflow bug where Q is naively trying to store a v6 address in a data structure meant for a v4 address. Maybe in that 1996 Netscape code mentioned in Acknowledgements.

Rocket J Squirrel

Oh, PS, we should be looking at activity from quickenPatch.exe as well as qw.exe.

Rocket J Squirrel

Moving to a different PC, I can see a v6 address (used by both processes). But it does not cause my Quicken to start more slowly than usual.

Chris_QPW

One thing I can say as a programmer, Quicken itself knows nothing about IP addresses, it knows names, and recourses like a network socket.

So this really comes down to the network libraries that are being called and how they lookup/translate network addresses.

And one thing that I think is different about Quicken and a lot of programs is it seems to have multiple interfaces being used to work with web pages both internal and external.  I'm sure it one of few that is still using ActiveX.  I would certainly expect calls to both very old network APIs and current ones.

BTW I remember a problem years ago that seems like what you are describing where I couldn't get a connection as long as IPv6 was enabled.  Unfortunately that was too long ago to even remember what programs were involved.  But one thing I remember, I never really figured out what the problem was.  I think either changed hardware or it was there until an OS update of something.  Not much of a help, and the main reason I didn't mention it before.

Quicken is a program, that will find the worst in the best of computers.

TedTheITGuy

LOL, @Rocket J Squirrel, it wouldn't be the first time my network baffled an "off the shelf" consumer product, but this is the first time it has been a bit of plain software.

Earlier today, I realized that all of the "stuck" IPs were actually NAT64 addresses (basically IPv4 addresses in IPv6 format for hosts with no IPv4 access). I don't use NAT64 on my network, so I had to go hunting. After whipping out WireShark, I figured out I was getting these NAT64 IP addresses in the DNS responses for only a handful of hosts, but apparently coming from one of my upstream IPv6 DNS servers.

One of the problem hosts I identified was ip-api.com - it kept trying to connect to this IP over and over again. (Why so much geo-location Quicken?)

DNS -> Standard query response 0x59b4 AAAA ip-api.com AAAA 64:ff9b::d05f:7001

So, long story short, my DNS was essentially being poisoned. After a teeny bit of jiggery-pokery (technical term) I am no longer seeing these NAT64 addresses my DNS responses and Quicken launches at a normal speed with IPv6 enabled. EDIT: I am still receiving *other* NAT64 addresses, but those ones seem to actually *work*.

I guess I should have broken out WireShark sooner. However, I did expose an issue with Quicken's poor handling of unreachable IPv6 hosts.

Thanks for your responses!

Rocket J Squirrel

Glad you got it figured out. I'm no expert, but wondering why you were getting NAT64 addresses with IPv4 enabled, and why those addresses didn't work.

I also wonder about ip-api.com. I have no idea why Quicken wants geolocation, unless it's trying to decide which servers are closer than others.

I will take credit for guessing early on that the problem was DNS-related.

Chris_QPW

@TedTheITGuy thanks for the update, I’m glad you found it.

I have an idea of why Quicken wants geolocation.  It has been noted that Quicken login gets triggered if you are moving your machine to different locations.  It seems to tie into whatever games they are playing with their deciding of when to check the subscription.

It is unlikely it has anything to do with trying to decide on what servers to use.  Natural IP routing should basically take care of that and I don’t think Quicken Inc has multiple server locations in the first place.