The first 3 bytes are flags showing the status of the buffer:
1. free-flag - wether the buffer is free or not

Is this only a boolean value for each buffer ? Then you might be able to use a bit field (even if you can't actually use bit-addressed variables and have to work on the field with byte-wise commands) or merge this information into one of the two other status bytes (by defining a special value for one of the field that indicates that the buffer is empty).

1. When a package with size 4bytes arrives and I put it to the 13byte buffer I am loosing memory
Another solution would be to use a chained list and not hard allocate the buffers, but than I will have fragmentation problems.
I.e. When a 4byte package is not more valid and another 9bytes package arrives which I need to put in the middle of the buffer.

Even if you use a linked list, you would still have to make sure that there is enough memory for the worst case (which is probably 5 messages containing 9 bytes), or you would run the risk of running out of memory and handle this situation somehow.

3. If a new package type with size 15bytes will be defined I have to change the default buffer size.

I guess there is no way to avoid this. Apart from maybe starting with a larger buffer in the first place, which would also allow you to "split" one of the large buffers to hold two shorter messages.