You should consider a different strategy as encryption as you discovered is not the most efficient.

Send data unencrypted but the server needs to decide if the action the client sent fits within the rules of the game world. For example a player sending movement data, over a given time can a character cover the distance between p1 and p2, if the move is legal the server now tells other clients the character is at p2, if not the server keeps the player at p1. The aim is to not trust the client, you will also have to account for packets arriving out of order or lost.

I suppose I'm having a very large overhead because of the encryption/decryption AES.

You should measure first, before deciding what the issue is.

Since you are encrypting the packets in the client you have to include the encryption-keys in the client too.

With this you are giving a malicious and knowledgeable player everything he needs to capture, unencrypt, modify and re-encrypt the packets before they leave his computer. He just has to extract your keys from your program! (which is not that hard to do)

He doesn't even have to modify your *.exe! So while checking the checksum of the *.exe might hinder a malicious player, it won't stop him from tinkering with your program. (he could modify the program on-the-fly in-memory after the program loaded)

So do what the others say and discard your encryption and don't trust you clients.

(this has the added benefit that you "could" intercept the packets yourself to aid you in debugging some problems)

Even without measuring it is clear that AES cannot possibly be the reason for that delay. Typical AES software implementations run at speeds upwards of 150 MB/s, optimized implementations using special CPU instructions run about 4 times as fast. Thus, unless you have the most pathetic AES implementation in the universe, 150ms delay is equivalent to encrypting megabytes of data. Encrypting 120 bytes will take, as you have measured, more or less zero time (means under a microsecond, not hundreds of milliseconds).

Did you make sure that no application level firewall is running on either of the machines (which maybe does realtime scanning on traffic)? This is on a LAN, I suppose? Routers in between causing delay?

Also, can you describe how you measure that sending and receiving takes 150 or 200 milliseconds, and what it means exactly? Measuring what time it takes to send is (naively) easy, although in reality you can only measure the time it takes to push the data to the network stack. You do also display a number for receiving, though.

Receiving can only be measured on the other computer, but it is not meaningful to measure that. The receive will block forever as long as no packets come in, and unless the two computers are in perfect sync (which is impossible) there is no way of knowing when to start counting. Even doing this over loopback on the same computer could be troublesome due to scheduling.

You should measure complete round trips (and divide by two for one-way). That way, it's the same clock everywhere, and there are no synchronization issues.