How can support and developing coexist?

Is this work related to the same product? If so, why is it proving difficult to order maintenance in relation to other any other work on the Product Backlog?

I'm trying to implement scrum but there is a really big issue:

I would say that the big issue is that you are trying to implement Scrum instead of a self-managing, self-organizing team of individuals trying to do it.  I also suggest that a single team trying to implement Scrum without the support of the rest of the organization could be a problem.

the same team that does development of new features and makes maintenance, is the team responsible for all the support necessities.

This sounds like an impediment that a self-organizing, self-managing team would need to address.  It also sounds like it could require some changes on the organizational level.  Scrum doesn't solve all problems but it does make some become visible.

This means that there is no way of knowing how much time will be there in the sprint for developing new features and for support of existing clients.

I disagree with this.  A Sprint is a timeboxed event.  So you know exactly how much time there will be. It is the length of the Sprint.  The true statement is that there is no easy way to predict how much time during a Sprint can be focused on satisfying Product Backlog Items.  This is something that will have to be learned over time.  And even then you will never truly know because every time you make a change to the codebase, you introduce the opportunity for more support needs.  All you can actually do is inspect and adapt as you progress on the Product's lifetime.

How can i make it work? Should i have a pre determined time that will be used for these support requests and only plan for developing on the left over time?

The question isn't how can you make it work.  The question is how does the Scrum Team feel that they can handle this situation as a self-managed, self-organizing team.  The Product Owner is responsible for making sure that the Developers are focusing on the work that delivers value.  The Developers are responsible for determining how they work and what they do during a Sprint. The Scrum Team as a whole is responsible for providing consistent iterative value to the stakeholders. There is no manager, no director, no one individual that is responsible for telling people how to work.  It is a shared behavior and responsibility across the Product Owner, Scrum Master and Developers. 

The Scrum Guide defines a framework that is much more than Sprints.  And in reality most people's interpretation of a Sprint has very little resemblance to how the Scrum Guide defines.  If you are trying to drive a Scrum implementation, you might want to make sure that you understand the Scrum Guide's definition of the framework.  You can implement agile practices that are not Scrum and you can even use some of the terms.  But as the Guide states:

The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.