There are a few issues with your protocol. Namely it doesn't protect against men-in-the-middle.
Issue #1 (mentioned by fgrieu in the comments): Assume I host one of the (many) servers all your IP packets have to travel through from ClientA to Server. If I drop the server's Key1A (or KeynA) any future request won't work and I have successfully denied your user the usage of the server. He will have to re-perform the secure initial secret exchange which is likely expensive.
While this won't break the protocol in the sense you're interested in, this is still potentially harmful as it may cost you money (by losing customers being angry about the unrelieability of your protocol) if you need to do an expensive renegotiation (which involves human interaction?) too often.
Issue #2: If I don't just drop the packet, but flip a single bit, the client will get a wrong key and the server will assume the client has been successfully broken, so your legitimate client will be angry at you and has to re-perform the secure exchange. (see issue #1)
Issue #3: If I can eavesdrop on any of the server's responses and I'm able to drop all users packets, I can successfully take over the role of the client.
You send the next valid token in each of your server's responses and if I can get my hands on that and one valid client request (for getting the ID) I can successfully use said ID and the valid token to make my own requests.
All I have to ensure is that the client won't make any requests himself until I've finished all my evil requests.
The time-frame I need may be relatively short (a few seconds or minutes maybe) and I may be very well able to pretend the server is offline for maintenance for this time-frame. Or I could just launch a packet flooding attack on the client (which probably doesn't have more than 100Mbps bandwith?).
You shouldn't rely on an attacker not being able to DoS your client just because "it's not easy", a good protocol wouldn't create this situation in the first place (and the below mitigation should fix this issue anyways), for example you could avoid sending the next valid token at all,
but cleverly use HMAC to only send derived values and thereby only send the next valid nonce.
Issue #4: If the client actually is some piece of software that should authenticate to the server, I as the (not-so) legitimate user can extract the full program state from RAM / disk drive and just copy it over to another machine to perform my evil requests from there, and maybe I even install some software (like increasing packet loss or just root-level blocking the application) to make sure the legitimate client needs some time to figure out, I stole his credentials. This will be detected, but I still have some time (minutes up to days) to make my evil requests which may cause serious harm to the system and make you lose customers / money.
I hope this points the main issues of your protocol out (if anyone finds any else, please comment / answer yourself).
Now for the improvement.
The best thing to do is: Don't roll your own crypto.
The easiest way to mitigate the issues #1-#3 is by simply using your protocol on top of server-authenticated TLS. This would mean a modified packet would never reach your client application, the server would notice (thanks to record numbers / TCP) if a key didn't reach the destination and an eavesdropper wouldn't be able to read the valid tokens (and mitm is mitigated if the client checks the certificate properly). To fully mitigate man-in-the-middle attacks, you have to deploy DNSSEC along with TLS (and maybe DANE if you're at it) which would ensure you get the correct IP from the domain name for which you know the correct certificate (and can cross-check via DANE) and would allow you to drop the "known IP" requirement.
Issue #4 can't be mitigated with a pure software solution. I can go ahead and copy the state of any program (if I'm root / admin on a PC) and continue running it somewhere else (at least for some time). You need to use a hardware solution in order to ensure that a specific PC was used for a specific client or the client will be able to just shut-down his PC and copy the app to another one (in the same network?) and run it from there. The cheapest approach to this is using the TPM many modern PCs have (and which Windows 10 will require as of july 2016 for Windows 10 logo certification of PCs)