Sorry, I thought you would see the obvious issue (at least it is obvious in my head).
Regarding the error "Validation of viewstate MAC failed", in my opinion, you should not worry about it too much. I have seen it a million times in my sites but almost every time, when you look at the
UserAgent line, there is almost always something wrong about it. In the case of my cryptic message, I was referring to the original poster's log UserAgent line, which is "UserAgent: Mozilla/1.22 (compatible; MSIE 2.0d; Windows NT)". The UserAgent identifies the detected characteristics of the client’s browser, O/S, and other available items. As a reference, look at the line below from one of my DNN sites after I connected with my laptop, which runs IE8 on WinXP (TabletPC Edition).
UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Tablet PC 1.7; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1)
That site is still running DNN 4.9.5 by the way. Notice the version numbers for Mozilla, IE, Windows itself, as well as the other components. In my opinion the client having the viewstate MAC issue is overdue for some upgrades. I have also seen the viewstate problem with obscure spiders/bots accessing my Web sites and I really don’t care about them. This issue does not happen with the spiders for Google, Bing, Yahoo, etc. The other instance when the viewstate issue happens, is when someone is attempting to access your site via script, maybe trying to penetrate, looking for vulnerabilities, etc. Whenever this happens, look at the UserAgent signature, most of the time there is something strange about it.
Also, and another tell-tale factor that tells me the client having the viewstate issue is not a legitimate user, is when you see the error in the log many times within a minute. This is the sign of an automated client and not a human on the other side. Plus, are you getting support calls from users telling you they cannot login??? I bet you are not.
Again, I don’t worry too much about the viewstate issue. When I do see it happening a lot, I research the client’s IP address, which is included in the error message, and again, most of the time is a very suspicious source, so I block it (or the whole address range where they belong) in IIS. For instance, the address in the original post is 188.92.72.168, just do
http://whois.sc/188.92.72.168. This particular client is in Latvia/Amsterdam.
One more thing, regarding IE security settings, I have tested this from my kids PCs, which are running with very limited access, regular user account in XP, secure settings in IE, etc. and the viewstate issue does not happen.
Sorry for the long post, I was overcompensating for the previous short one.
Carlos