You mentioned that you had this problem in a load balanced environment, right? I assume that you are using the default "In Proc" method to store session data. If so, then I think I know what might happen. (for the sake of argument, I will take 2 servers, but it really doesn't matter if you have more)
You go to ServerA and a session is created. Because it is In Process ServerB has no idea about it. In the end (and how this happens, it's a question of how your balancer is configured. Sticky session? Cookies? Round robin?), You will be sent to ServerB. Since this server did not know that you already have a session; a new one is created and you are assigned a new session identifier.
So why does this happen under your play points? Well, I suspect that given enough time and load, you will see that it just moves from / page 1 to / page2. Again - it depends on how your load balancer is configured, but it may be because you are changing the protocol that starts something, and you are sent to another server in the pool.
How can you fix this?
To get started, make sure you have the same machine key in the machine.config file. If you do not have access to this, I think it will work in web.config, but I have not tried it.
Now configure a different way to store session state. Perhaps on a Sql or MySql or Postgres server, or anywhere. If you have SQL Server, which will be the easiest since it was created, but if you have another data warehouse, you will need to either build or find a library that will do this. I was working on a project in which we used Postgres to store session state.
We used npgsql as a driver to connect to the server and created our own PgsqlSessionProvider:SessionStateStoreProviderBase , and its connection is really easy
<sessionState mode="Custom" customProvider="PgsqlSessionProvider"> <providers> <add name="PgsqlSessionProvider" type="My.namespace.PgsqlSessionStateStore" connectionStringName="connectionStringName" writeExceptionsToEventLog="true" /> </providers> </sessionState>