Juniper SRX Default Timeout Values

Reminder for myself while looking into some reports of TLS Session Resumption denoted at the twitter blog I started looking into reasons why there were reports this might be blocked at the enterprise firewall. NOTE: the FW this behavior was reported on was NOT a Juniper SRX.

One of the first things I wanted to check was the default settings on my vSRX when building a policy to allow/deny ‘junos-https‘ traffic profile. Since these are built into the box, the inline help isn’t much help here which is where google came to the rescue.

You can see the help doesn’t indicate there’s anything there… but there is.

root@vSRX-1> show configuration groups ?
Possible completions:
Execute this command
Group name
| Pipe through a command

root@vSRX-1> show configuration groups junos-defaults ?
Possible completions:
Execute this command
> access Network access configuration
> access-profile Access profile for this instance
> accounting-options Accounting data configuration
> applications Define applications by protocol characteristics
> bridge-domains Bridge domain configuration
> chassis Chassis configuration
> class-of-service Class-of-service configuration
> ethernet-switching-options Ethernet-switching configuration options
> event-options Event processing configuration
> firewall Define a firewall configuration
> forwarding-options Configure options to control packet forwarding
> interfaces Interface configuration
> multicast-snooping-options Multicast snooping option configuration
> policy-options Policy option configuration
> protocols Routing protocol configuration
> routing-instances Routing instance configuration
> routing-options Protocol-independent routing option configuration
> schedulers Security scheduler
> security Security configuration
> services Set services parameters
> smtp Simple Mail Transfer Protocol service configuration
> snmp Simple Network Management Protocol configuration
> switch-options Options for default routing-instance of type virtual-switch
> system System parameters
> vlans VLAN configuration
> when Specify additional conditions for groups
| Pipe through a command

root@vSRX-1> show configuration groups junos-defaults applications application junos-?
Possible completions:
Application name
junos-aol Application name
junos-bgp Application name

So, let’s check what our settings will be for this application set.

As denoted in this Juniper KB (login may be needed), there’s two ways to retrieve the default settings as they don’t actually live in the configuration on the FW, but actually reside in the forwarding-plane (FWDD process specifically).

On branch platforms you can retrieve this by issuing a command directly to the ‘pfe’ (packet-forwarding-engine) as such. By running this from the CLI, rather than a shell.

Normally you could do it this way… and run the command directly on the pfe but apparently not on vSRX. That’s OK, because by running this through the ‘pfe execute’ command, we have the CLI filtering/grep/pipe we can use to narrow down our results which you can’t do directly on the pfe.

root@vSRX-1> start shell pfe network fpc0
error: command is not valid on the firefly-perimeter

So here, we ask the FW to return the forwarding-plane defaults, and filter specifically on https (I’ve included http for additional context). You can see for junos-https the alg id=0 indicates we aren’t performing any higher level inspection on the protocol short of a standard tcp timeout of 1800 sec (30min).

root@vSRX-1# request pfe execute target fwdd command "show usp app-def tcp" | match junos-http
tcp port=80, appl_name=junos-http, service type=6, alg id=6, timeout=300
tcp port=443, appl_name=junos-https, service type=58, alg id=0, timeout=1800
tcp port=7001, appl_name=junos-http-ext, service type=66, alg id=0, timeout=1800

root@vSRX-1# show groups junos-defaults applications application junos-https
protocol tcp;
destination-port 443;

So based on the above info – we aren’t doing anything special with traffic connecting through the firewall on tcp-443 short of inserting into the session state table, and tracking the default timeout value of 30min.

Summary of this short post, is the default FW configuration does not lend itself to blocking anything related to RFC5077 on the firewall as a new TCP socket is instantiated each time which will qualify as a fresh session in the state table.