2 Replies Latest reply on Sep 24, 2013 2:28 PM by tincg_cw

    Can you limit policy-timeout statements based on dst/src of traffic?

    tincg_cw New Member

      I have a client who uses a web/telnet application.  The default timeout is too short (~10-15 minutes).  On their remote locations I've overcome this issue by using the following statement.


      ip policy-timeout tcp telnet 28800


      They are now migrating to our hosted environment from which they need similar access.  They are now in a multi-tenant scenario where multiple client's traffic runs through a NV3448.  I'm concerned about implementing the same rule because it is a global change for all traffic traversing the router.  I believe this will negatively impact router performance while being an additional security risk for all clients.


      Is there anyway that I can narrow the scope of the policy-timeout to only impact this client's traffic?  Internally each client is on separate VLANs if that helps.


      Worst case scenario, if I move the client to their own VRF could I then apply the policy timeout rule to only that VRF's firewall?


      Additionally, are my concerns over this being an additional security risk correct?




      Look forward to the feedback and discussion.

        • Re: Can you limit policy-timeout statements based on dst/src of traffic?
          jayh Hall_of_Fame

          To the best of my knowledge the timeout is a global setting.


          However, you can set it per port/protocol to limit it to telnet.


          I wouldn't worry about it being a security risk for TCP.


          TCP is connection-oriented.  Normally, the end host(s) will gracefully tear down the connection with a FIN packet when they close the session.  The purpose of the timeout in a firewall or NAT scenario is to tear down a connection should the end hosts fail to do so.  For example the telnet session is started from a laptop and the battery dies, a user wanders outside of wi-fi range, etc.  Note that any traffic on the session will reset the timer.


          It won't affect performance unless all of the following are true:

          • You have a lot of users opening telnet connections.
          • Most of them abandon the connection without closing the session or leave it open for hours with no activity.
          • The number of open policy sessions at any time is near the limit of the box.


          There really isn't any performance cost to leaving an idle session open other than a small amount of RAM to maintain the state.  You should be fine at 12 hour timeout.


          As far as security risks, telnet itself is unencrypted....