I just got this same error on a different v2.x version.
Apparently this issue has been present since v1.2.
https://mantisbt.org/bugs/view.php?id=19820
https://mantisbt.org/bugs/view.php?id=20273
The problem is not with a specific OS, PHP version, Mantis BT version, or any other such detail.
The problem is either:
1) The simple check for the client IP address is inadequate for determining session state. There are some legitimate reasons why an IP address can change. A LAN with DHCP can reset and reassign IP addresses to network PCs. A developer can login to Mantis to check tickets, and then connect to a VPN to work on a project. A user with two PCs can login to Mantis on both.
Frankly, while I believe those real-world conditions are legitimate, as a technician I think it's understandable that any software, including Mantis, would and should invalidate a session when it discovers that an IP address has changed. The scenario smells of a hijack, and I appreciate that a check exists to protect us against "man in the middle" attacks.
But that then leads to ...
2) We can understand that the scenario happens. We have verification that it does. So I think the real problem is that Mantis doesn't gracefully handle the scenario. An mysterious error is reported and the page resets. That's not elegant. It would be much better if the user is informed of the exact condition, with a button for confirmation, followed by a logoff of the session. Force the user to re-login with the current IP rather than forcing them to clear cache or guess at the problem and solution.
That would be my suggestion for an enhancement. I don't see this as a bug.