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.

Advertisements

Juniper MX : BERT Testing a Loopback

So you’ve been receiving errors on your Juniper router, and asked your local provider to drop a loop on the cable facing your box at some point in the cable run in order to divide and conquer. Now what. We probably want to generate some traffic to determine if any of the equipment involved in the loop is responsible for that pesky CRC you’re trying to find.

You can follow the steps outlined here to generate some traffic.
https://www.juniper.net/techpubs/en_US/junos12.3/topics/topic-map/ethernet-fast-and-gigabit-loopback-testing.html

I modified this somewhat in that I created a routing-instance type virtual router, placed my interface in that routing-instance and performed the tests noted above so that you’re not mucking about in the default routing-table should you mess something up with your IP allocation, etc.

user@Juniper> show configuration routing-instances LINKTEST
instance-type virtual-router;
interface xe-2/1/3.0;

user@Juniper> show configuration interfaces xe-2/1/3
description “Test Interface”;
unit 0 {
family inet {
address 1.1.1.1/30 {
/* this must be the MAC address of your local interface so you’ll accept the traffic */
arp 1.1.1.2 mac 2c:6b:f5:77:66:88;
}
}
}

user@Juniper> ping 1.1.1.2 source 1.1.1.1 routing-instance LINKTEST size 65000 count 200 rapid

In practice – this command netted about 67Mbps of traffic dropped onto the link, looping about until the TTL expired. By using rapid – you’re forcing the ping to continuously send traffic before the previous request has expired, effectively doubling the amount of data on the link. Increasing your ping size, obviously results in a larger amount of data being dropped on the link per ping.

Since this wasn’t quite enough traffic – a suggestion (not mine) was to drop into the shell and queue up a bunch of jobs to do the same thing. I thought it was a great idea – and now I’m sharing it with you.

user@Juniper> start shell
% ping
usage: ping [-ACNQRSXadfnqrvw] [-c count] [-i wait] [-g loose-gateway]
[-l preload] [-p pattern] [-s packetsize] [-t tos]
[-F source] [-G strict-gateway] [-I interface]
[-Ji|r|4|6|I interface|U routing-instance|L logical-router]
[-T ttl] host

% % ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null &

etc…

% jobs
[1] + Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[2] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[3] Exit 2 ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[4] Exit 2 ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[5] Exit 2 ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[6] Exit 2 ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[7] Exit 2 ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[8] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[9] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[10] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[11] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[12] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[13] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[14] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[15] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[16] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[17] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[18] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[19] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[20] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[21] Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null
[22] – Running ping -Jr -c 500 -s 65000 -F 1.1.1.1 -JU LINKTEST 1.1.1.2 > /dev/null

Now, if you execute the above command 25 times, I found this generates about 850Mbps of traffic. You probably want to be a bit careful creeping much past this if you want to push bits for a long amount of time as this traffic is generated from the internal em0.0 interface connection to the routers backplane and saturating the routing-engine/backplane connection on a production router is probably not a great idea for all your routing protocols and such.

user@Juniper> show interfaces em0 | match Speed
Type: Ethernet, Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps