This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firewall Problem: Invalid Checksum

EMC v5.2.1.197

ES&C v10.3

I'm using the trial version of the endpoint goodies, and after successfully getting filezilla server and pidgin to work, teamviewer and spiceworks still fail due to an invalid checksum error.  I have unchecked the "use checksums" box under the general tab, added the programs as trusted under the applications tab, allowed the processes to create hidden processes, and double checked that the checksums do match between the whitelist and the log file.  Still getting:

11:50:50 AM teamviewer_service.exe OUT REFUSED TCP 95.211.37.198 HTTP Invalid Checksum

Thoughts, suggestions?

:45625


This thread was automatically locked due to age.
  • Hello AlexD,

    thoughts first :smileywink::

    unchecked the "use checksums" box

    As this applies to all applications and is used to verify the integrity of a known application, it should not considered as solution - I assume you temporarily turned it off for troubleshooting only.

    trusted ... create hidden processes ...

    This is more like desperately turning knobs and flipping switches, not a systematic approach :smileyhappy:. While Reason might not always be immediately intuitive there is no obscure cause behind it - if it says Invalid checksum then it is Invalid checksum. Application rules (trusted) are considered only after an application has been positively identified and neither is a hidden process involved nor would the allow launch setting affect the connectivity of the parent application.

    I don't think there is a bug or some peculiarity of these applications involved. Please note that a checksum decision "sticks" until the process is restarted. I.e. if teamviewer_service.exe is blocked due to invalid checksum it nevertheless keeps running. Any subsequent attempt by it to access the network will be blocked - even if you then add its checksum or untick Use checksums as the check is made at the first connection attempt only. 

    HTH

    Christian

    :45635
  • What did it for me was restarting the service for teamviewer; I was restarting the application every time, but forgetting the service that was running in the background (oops!).

    And yes, I was pushing whatever button I could find to try and get the traffic through :P  I know that I need to put it all back :)  I made all the changes on the local machine, fixed it (with your help :P), then pushed the correct policy through the server...all is well now!

    Thanks

    Alex

    :45661
  • I'm having similar issues where I can not get nsepa.exe to work. What nsepa.exe does is verify your settings when attempting to log into Citrix Access Gateway. It gets blocked due to "invalid checksum" even though I'm not using checksum checking.

    Points worth mentioning (all done locally on the client while connected to wifi, not using SEC):

    • I'm in secondary location, verified in system log.
    • It was working before, being allowed communcation via a global rule that is just set to allow TCP to the remote address of CAG.
    • Secondary location has never had the box checked for "use checksums" (nor has primary location, though that doesn't matter).
    • Fruitlessly, I've added the exe to both the "applications" and the "processes" tabs, though I didn't need to and it didn't help. I have it set to TRUST in the applications tab, then I modified that and added a rule specifically to allow TCP to the remote address being blocked (our CAG address). I added it to the processes tab too, to see if that affected checksum somehow, but it doesn't.
    • I added the exe to the checksum tab, rebooted, then tried again - still fail
    • Thinking that the checksum might change on a reboot, I rebooted, added the exe to the checksum tab, then tried again - still fail (the checksum doesn't change on reboot)
    • The previous 2 steps were done with the "use checksum.." box unchecked. I checked that box and now iexplore.exe claims to have an invalid checksum. I added the exe to the checksum tab - still fail
    • I unchecked "use checksums..." again and now iexplore.exe works but nsepa.com still throws the error.

    What is the deal with checksums?

    Why does it force a checksum check if I'm telling it not to?

    I'll go reinstall the endpoint completely and see if that helps.

    After reinstall...

    • iexplore.exe & nsepa.exe both come up with invalid checksums
    • If I set the firewall to "allow by default" to allow outbound traffic, both exe's work with the reason stating "Allow CAG Address", which is the name of my global high-priority rule. So obviously my rule works to allow the proper traffic, but I can't get around the checksum checking even though it shouldn't be.

    Update:

    Well basically, the "invalid checksum" error message is deceiving. What the problem ACTUALLY was was a hidden process. nsepa.exe has an associated launching process svchost.exe. I set up svchost.exe in the "processes" tab and now nsepa.exe doesn't throw the checksum error. I then turned on the "use checksums..." option, added iexplore.exe (both 32- and 64-bit versions) and nsepa.exe to the checksums tab, and tested it. It works. Hurray. The error message in the firewall log should really really REALLY not say "invalid checksum". It should say "Hidden application". Lesson learned. I hope I helped someone else out there as well.

    :46099
  • Hello mmcmillan,

    the "invalid checksum" error message is deceiving [...] the problem ACTUALLY was a hidden process

    Indeed this doesn't seem right - did you contact Support with this as it seems to be a bug/defect?

    Christian

    :46363