Community Homepage
Discussions
Categories
Quicken for Mac
Quicken Lifehub
Quicken Mobile
Quicken on the Web
Quicken for Windows
Support
Quicken Classic
Quicken Simplifi
Getting Started
Community Training FAQs
Using and Improving the Community
Announcements & Alerts
Announcements
Alerts, Online Banking & Known Product Issues
Product Ideas
Connect and Engage
The Community Meetup
The Water Cooler
The Lounge
Beta
Home
Quicken Classic for Windows
Errors and Troubleshooting (Windows)
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.
Find more posts tagged with
Accepted answers
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.
All comments
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.
Quick Links
All Categories
Recent Posts
Activity
Unanswered
Best Of