Should idle timeout match the server timeout

There's different definitions of a "session" depending on the OSI layer you're referring to.

A TCP session is the layer 4 connection. Within this definition there are variances based on the protocol you use. For example, things like FTP require a single (or a few) long lived TCP session(s), while HTTP - a stateless protocol - can build and tear down TCP sessions between requests. Of course it's generally bad for performance to allow that sort of thing, so HTTP also allows you to keep a TCP session open between requests with an explicit Keep-Alive header in HTTP/1.0 and natively in HTTP/1.1.

An SSL session is the layer 6 session that a client and server maintain during encrypted communications. This session is largely independent of the TCP session below it.

And then there's the application layer session. This session is highly dependent both on the protocol and the implementation. For example, RDP will maintain a session using a session ID value that's passed by the client. HTTP can use a variety of tricks to maintain session "state", including TCP Keep-Alives and cookies.

So you have to examine what 65 means in terms of a session. Do you have TCP tuned via Keep-Alives to hold a TCP session for that long? Do you even care about TCP Keep-Alives in your environment? Do you have a browser cookie that expires 65 minutes after it was created? Do you have a session entry on the application server that times out after some period of time?