1

On my SRX 1400 I see maximum sessions here:

show security flow session summary

This is what shows up now:

Unicast-sessions: 46795
Multicast-sessions: 0
Services-offload-sessions: 0
Failed-sessions: 931259
Sessions-in-use: 51465
  Valid sessions: 46337
  Pending sessions: 0
  Invalidated sessions: 128
  Sessions in other states: 0
Maximum-sessions: 1048576

My SRX can handle this number of sessions fine but the rest of my network can NOT.

How can I decrease the Maximum-sessions value?

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 14 '17 at 19:12
1

You cannot decrease the maximum sessions value directly, but you can use Screen options to limit the maximum number of concurrent sessions per source- or destination IP. In your case I would expect a destination-based limit (see Juniper documentation).

For example:

security {
 screen {
  ids-option max-1000-sessions-per-host {
   limit-session {
    destination-ip-based 1000;
   }
  }
 }
 zones {
  security-zone untrust {
   screen max-1000-sessions-per-host;
  }
 }
}

However, it sounds really weird that your network is constrained by the number of sessions it can handle. This is usually only relevant for stateful devices like firewalls and load balancers, that are perfectly capable to drop exceeding traffic on their own. If it is bandwidth that's the problem, then there are probably better knobs to turn than session limits.

| improve this answer | |
  • The SRX is our firewall. How is a firewall capable of dropping excessive traffic other than screening? – user3063045 Jul 5 '16 at 16:25
  • The SRX has a whole bunch of options for dealing with traffic apart from screens, including policies, bandwidth shaping, and layer-7 stuff (UTM/IDP). But to answer your question properly it would be useful to know what you're actually defending against, and what resources in your network are going to be depleted when your firewall allows too many sessions (as opposed to too much traffic). – RobinG Jul 5 '16 at 17:46
  • This is traffic being accepted by a policy that's ramping up. The sessions are maxing out the SRX which is causing other services to become unavailable. Is there a better way than session limiting in this case? – user3063045 Jul 5 '16 at 19:17
1

You cannot limit the number of sessions to a policy - there would be no way to determine "good" sessions from "bad" ones.

Depending on the service (let's assume a web-server) you could simply limit the number of connections it will accept on the server - this can be done in things like Apache, NGINX, IIS etc - you should even be able to apply the limit based on whether the source is inside your firewall or outside.

Another option could be to apply rate-limiting to specific policies on the SRX - that way if it is a specific service that is attracting the most traffic, you could set a hard limit on the amount of bandwidth it offers.

This can be done client-to-server or server-to-client.

To do this, set up an application-traffic-control profile, and then reference it in your policy after permit eg:

set security policies from-zone INTERNET to-zone DMZ policy PERMIT-SERVER1 match source-address any
set security policies from-zone INTERNET to-zone DMZ policy PERMIT-SERVER1 match destination-address SERVER1
set security policies from-zone INTERNET to-zone DMZ policy PERMIT-SERVER1 match application junos-http
set security policies from-zone INTERNET to-zone DMZ policy PERMIT-SERVER1 match application junos-https
set security policies from-zone INTERNET to-zone DMZ policy PERMIT-SERVER1 then permit application-services application-traffic-control rule-set INTERNET-LIMITS
set security policies from-zone INTERNET to-zone DMZ policy PERMIT-SERVER1 then log session-init
set security policies from-zone INTERNET to-zone DMZ policy PERMIT-SERVER1 then log session-close
set security policies from-zone INTERNET to-zone DMZ policy PERMIT-SERVER1 then count

set class-of-service application-traffic-control rate-limiters 10M bandwidth-limit 10485760
set class-of-service application-traffic-control rate-limiters 10M burst-size-limit 524288
set class-of-service application-traffic-control rule-sets INTERNET-LIMITS rule WEB-10M match application junos-http
set class-of-service application-traffic-control rule-sets INTERNET-LIMITS rule WEB-10M match application junos-https
set class-of-service application-traffic-control rule-sets INTERNET-LIMITS rule WEB-10M then rate-limit server-to-client 10M

This will limit all traffic from SERVER1 back to the client to 10M, which will not limit sessions, but instead slow them down so that they don't use all your upstream bandwidth.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.