If that alone was the reason, then your interviewer did a bad job.
The point isn't to trick you. It's to see how you work under pressure when presented with a tough problem. What is your thought process? Do you dive right in or do you take time to chew on it? What parts of your background can you draw on to help you?
It certainly helps your chances if you can solve the problem, all else being equal, but I'd rather take someone who talks through their work but doesn't quite solve it over someone who solves it yet has trouble explaining how or why.
The best interview questions are layered. There should be a relatively easy solution solvable in multiple ways by anyone with experience programming. It should almost solve itself if you walk through the specifications. (Think fizz-buzz-level.)
But underneath that should one or two harder problems with very elegant solutions. And those are much more about the process -- about weeding out the people who would dive in without really thinking it through. If you make a mess of the whiteboard, get frustrated, start desperately erasing and rewriting the same things without ever stepping back to think through alternatives... well, that might be what I'd hold against you. It's not that you didn't solve it. It's that you didn't prove to me you could've given more time.