Ah, surprisingly I am often amazed that even many "professional" programmers have no idea how this works in detail. There will be a big step back to explain the two phases of making an executable.
Compiling: every .c/.cpp/.cc (whatever your source files are called) is compiled in complete isolation. It knows absolutely nothing about the content of any other source file. This will usually create one compiled object file for every source file.
Linking: this pieces together all the object files into one big executable binary. This is also the step where every function that is being called must exist in one (and exactly one) object file (or one of the linked libraries). Same goes for global or static member variables.
Another important distinction is "declaration" vs. "definition". A header should usually contain only declarations (or inline code). Declarations say "this thing exists somewhere", while a definition says "this right here IS the thing". For global variables, "extern" is used to tell a declaration from a definition. For functions this difference is having or not having a function body.
So headers are a) never compiled on their own and b) are completely irrelevant for linking. They are needed to be able to compile source files that are using or referencing stuff that is "somewhere else". However, these are only declarations. Also, linker errors will never ever be fixed by touching #includes (except maybe by removing them if your compiler is seriously trying to link stuff that is never actually used).
There is also the issue of circular includes. If your includes ever start going around in circles, this is a bug and no, inclusion guards have nothing to do with it and won't fix that. The only solution is to not them and use forward declarations to break them up (using forward declarations as much as possible in header files is generally preferable anyway, especially when it comes to compile times). This is also one big reason why not to spam includes all over the place in header files, just in case they _might_ be needed or out of sheer convenience (my favorite quote from a coworker "but this is way easier, so everyone including this header automatically gets all the other stuff".. uhm, yes, including all the stuff they don't need, that might result in conflicts and will blow up compile times by a few multitudes).
So random guesses:
-your header includes something, but not RakNetTypes.h
-your header is trying to include itself
-the header isn't found and you are not looking at the error messages starting at the top
-there is a typo in the identifier