SRX

Architecture
Source: juniper.net


 * JUNOS runs on top of FreeBSD.

Details of Flow
3 Way Handshake check Sequence no check Acknowledge check
 * What happens in "TCP" section of the flow?

It is check in First path & Fast path both.
 * Where are the TCP parameters checked?

Changes in Flow
Source: exactnetworks.net


 * Next-Generation NAT:
 * In Junos 9.2 the flow module was changed
 * Static and Destination NAT now occurs prior to Route and Policy lookup
 * Source NAT takes place AFTER routing and policy evaluation.
 * NAT and Security Policy configuration was decoupled
 * Before Junos 9.2, all NAT was processed after routing and policy evaluation.


 * Issues with flow of Junos 9.1 or earlier:

1. Destination NAT where the destination IP address within the incoming packet is not an IP address the SRX has a route to.


 * Assume we have "untrusted" and "trusted" Zones.
 * Our ISP has given us 1.1.1.1 to use for our FTP server and has routed this address to our SRX.
 * We have configured destination NAT for users on the internet to access the FTP server.
 * In this case the SRX will not have a route directing 1.1.1.1 to the internal zone.
 * This means zone lookup/polcy match will fail and ultimately drop the packet.
 * Placing a route on the SRX for the 1.1.1.1/32 address can be done as a workaround but this is inefficient and goofy.

2. NAT Configuration that requires multiple security policies (due to the fact that NAT and Security Poilcy are configured together). 200.200.200.1---SRX---192.168.1.10(FTP) |                    |                192.168.2.10
 * An alternate private network of 192.168.2.0/24 has the exact same security requirements as the 200.200.200.0/30 network and they reside in the same zone.
 * Assume that no destination NAT is needed between 192.168.1.0/24 and 192.168.2.0/24 networks.
 * We can simply just route between these networks.
 * It would be ideal in this case to create a single rule in the security policy.
 * This cannot be done as NAT parameters are configured within the security policy.
 * To accomplish this tasks multiple policies would need to be configured.

Basics
Source = jsrx.juniperwiki.com


 * Physical Interfaces


 * Physical interfaces are the interfaces that you can touch, they are the interfaces that you see when you look at the device, and they are the interfaces you plug cables into. All interfaces are defined under the interfaces hierarchy as such

interfaces { ge-0/0/0 {  unit 0 { ...            }    } }


 * Physical properties such as MTU and framing protocols are defined directly under the interface.


 * Logical Interface


 * Logical interfaces are where the majority of the configuration is done. Every interface has to have at least 1 logical interface (usually 0). Logical interfaces are where you configure IP addresses and protocol families.

interfaces { ge-0/0/0 { unit 0 {  }   } }


 * There are many different protocol families that you can configure. Some of them include inet (IPv4), inet6 (IPv6), iso, mpls, and ethernet-switching.

[edit] metacortex@DevourerofSouls# set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.1/24 [edit] metacortex@DevourerofSouls# set interfaces ge-0/0/0.0 family inet address 192.168.1.1/24
 * When using set commands to either set interfaces or refer to interfaces, you can use one of two methods. You can refer to the interface as " unit <#>" or " .<#>.


 * Multiple IP Addresses on a Single Interface


 * You can assign as many IP addresses as you would like to an interface as well as multiple families on an interfaces. When you want to specify what address gets preferred, you just use the preferred option.

interface { ge-0/0/0 { unit 0 { family inet { address 192.168.0.1/24; address 192.168.1.1/24 { preferred; }               address 10.0.0.1/8; }       }    } }


 * OSPF and IS-IS will form adjacency across all subnets configured on a logical interface so if you do not want this, you need to separate the interfaces out across multiple logical interfaces.

interface { ge-0/0/0 { unit 0 { family inet { address 192.168.0.1/24; address 192.168.1.1/24 { preferred; }               address 10.0.0.1/8; }           family inet6 { address 3001::1/64; }       }    } }
 * To configure multiple protocol families on an interface, you do it like this


 * Interface Names


 * JunOS uses 4 criteria in naming an interface. It uses (and in this order) Media Type, FPC Slot Number, PIC Slot Number, and Port number. For instance, ge-2/1/4 would be the forth interface on PIC slot 1 of the FPC in the number 4 slot.


 * There are many different media types. Here are a few of them

ge = gigabit ethernet fe = fast ethernet lo = loopback ae = aggregated ethernet fab = fabric interface for JSRP clusters st = tunnel interfaces ls/lsq = link services

rollback 5 commit
 * Rollback Config:
 * Junos Stores 49 previously committed configurations on its storage device.
 * The factory default for the maximum number of backup configurations allowed is 5.
 * Rollback number 0 is the current running configuration - before commit, If after commit = rollback 1


 * The current operational configuration is stored in a file named juniper.conf,
 * The last 5 committed configurations are stored in the files juniper.conf.1 through juniper.conf.5.
 * If you create a rescue configuration, it is stored in a file named rescue.conf.
 * These files are located in the /config directory, which is on the flash drive of the SRX Series device.
 * Increasing this backup configuration number results in increased memory usage on disk and increased commit time.
 * When you edit a configuration, you work in a copy of the current configuration to create a candidate configuration.
 * To have a candidate configuration take effect, you commit the changes.
 * Rollback Commands:

rollback 5 commit

show rollback 5 show | compare rollback 5


 * Modes


 * Shell Mode:
 * The shell mode is to troubleshoot from Linux like CLI.


 * Operational Mode:

user@SRX240>
 * This mode is used for monitoring and troubleshooting of the device.
 * You can monitor all of the hardware components, test network connectivity, and view the current running configuration.
 * You can not make configuration changes in this mode.
 * Operational Mode is the mode you are placed into when initially logging in (except for the root acount).
 * This mode is indicated by the greater than sign at the end of the prompt
 * Configuration Mode:

[edit] user@SRX240#
 * This mode is used for making configuration changes to JunOS.
 * Configuration would include interface ip address, routing protocol configuration, and user access/control.
 * When we get into configuration mode, you will see something new added to the top of the prompt and the greater than sign will change to a pound sign to reflect we are in configuration mode.

[edit] user@SRX240# edit interfaces
 * The [edit] top of the prompt signifies what section of the XML configuration tree we are currently sitting in.
 * When it displays [edit], we are at the very top of the configuration.
 * Issuing a show will output the entire configuration from that section down.
 * For instance, if we wanted just to see the configuration of the interfaces we would run the following commands:

[edit interfaces] user@SRX240# show

ge-0/0/0 { unit 0 { family inet { address 6.6.6.6/30; }   } }

[edit] user@SRX240# show interfaces
 * We can also view a specific section of the tree by specifying it in the show command like so

ge-0/0/0 { unit 0 { family inet { address 6.6.6.6/30; }   } }

[edit] user@SRX240# run ping 4.2.2.2 rapid count 5
 * You can also run any Operational Mode command in Configuration Mode by appending "run" to the beginning of it like so:


 * Show

[edit] user@SRX240# show
 * This shows everything in the configuration from the current level down


 * Reference

[edit] user@SRX240# help reference interfaces address
 * Help reference will show you everything you need to know about a given command


 * Apropos

[edit] user@SRX240# help apropos ssh
 * If you remember one or two parts of a command but cant remember the full command, you can use help apropos to help you find that command

Taking Debug in SRX
set traceoptions file filename files                           (default 10) size                            (default 128k) read permissions                (e.g. world-readable) set traceoptions flag  (define what you want to look at)
 * Configure Traceoptions:

Packet Flow Trace
edit set security flow traceoptions file Debug_log.txt size 1M files 5 set security flow traceoptions packet-filter f0 source-prefix 10.1.1.1/32 destination-prefix 172.16.1.1/32 set security flow traceoptions packet-filter f1 source-prefix 172.16.1.1/32 destination-prefix 10.1.1.1/32 set security flow traceoptions flag basic-datapath exit commit and-quit                                                       (Logging starts after the commit)

Verify changes: show security flow traceoptions show | compare show configuration security flow

Check the output: show log Debug_log.txt show log Debug_log.txt | match route show log Debug_log.txt | last 20 show log Debug_log.txt | trim 42                                        (remove timestamps)

Realtime Monitor (similar to tail –f cmd): monitor start interface.txt monitor stop interface.txt

Check the output using tail cmd: start shell srx% tail -f /var/log/ Debug_log.txt | grep -Evi ^$ srx% tail -f /var/log/ Debug_log.txt | grep -Evi ^$ | grep 10.10.10.1 srx% tail -f /var/log/ Debug_log.txt | grep -Evi ^$ | grep session srx% tail -f /var/log/ Debug_log.txt | grep -Evi ^$ | grep tcp

Deleting filters & stopping debugs: deactivate security flow traceoptions commit OR delete security flow traceoptions commit

Delete Files & Filters: edit del packet-filter f0 source-prefix 10.1.1.1/32 destination-prefix 172.16.1.1/32 del packet-filter f1 source-prefix 172.16.1.1/32 destination-prefix 10.1.1.1/32 del flag basic-datapath clear log Debug_log.txt file delete /var/log/Debug_log.txt commit and-quit

Note:
 * It is security flow traceoptions, with a flag of basic-datapath (similar to debug flow basic in ScreenOS).
 * show | compare - This command displays the lines which will be added to your config)

Interface State Trace
Basic trace to monitor interfaces going up and down: set interfaces traceoptions file interface.txt size 1M files 5 set interfaces traceoptions flag config-states commit and-quit

Capture control traffic to Routing Engine
Packet Capture of control traffic to and from the RE of the SRX :

> monitor traffic interface layer2-headers > monitor traffic interface e1-0/0/0.0 no-resolve

Packet capture on J-Series or SRX branch device
Source: juniper.net, fir3net.com

set forwarding-options packet-capture file filename pcap files 10 size 10000 set forwarding-options packet-capture maximum-capture-size 1500

set firewall filter PCAP term 1 from source-address 10.209.144.32 set firewall filter PCAP term 1 from destination-address 10.204.115.166 set firewall filter PCAP term 1 then sample set firewall filter PCAP term 1 then accept set firewall filter PCAP term 2 from source-address 10.204.115.166 set firewall filter PCAP term 2 from destination-address 10.209.144.32 set firewall filter PCAP term 2 then sample set firewall filter PCAP term 2 then accept set firewall filter PCAP term allow-all-else then accept

set interfaces ge-0/0/0 unit 0 family inet filter output PCAP set interfaces ge-0/0/0 unit 0 family inet filter input PCAP commit and-quit                 (This will start the capture)

The term allow-all-else is used to make sure that the SRX does not drop any other traffic, but do not sample it either.

Verify capture file: > file list /var/tmp/ | match pcap* pcap.ge-0.0

Display Capture: start shell cd /var/tmp/ tcpdump -r pcap.ge-0.0.0

Remove Capture Config: delete interfaces ge-0/0/0 unit 0 family inet filter input PCAP delete interfaces ge-0/0/0 unit 0 family inet filter output PCAP delete firewall filter PCAP delete forwarding-options packet-capture

A quick way to revert config is using rollback: rollback 1 commit

Packet Capture on High-End SRX
Packet Capture on High-End SRX devices(SRX1400 or above):

Important CLI Commands
Monitoring commands:

show version 			 		Software version show chassis hardware detail 			Hardware and Serial numbers show chassis environment 			Temperatures, Fan and Power Supply show chassis routing-engine 			Temperatures, Memory, CPU Load show interfaces terse 			 	Interface States show interfaces extensive 			Interface and Zone Counters monitor interface 		 		Real-time interface statistics show security flow session 			Current sessions show system alarms 			 	Alarms show chassis alarms

Log Files:

show log					List all Logfiles available show log messages				Show Log File from beginning show log messages | last			List last Log Messages show log messages | match LOGIN			Search within the Log monitor start 				Send Logs to terminal (like tail -f)

SRX vs ScreenOS

 * Security policy enforcement is entirely handled on the data plane. This protects from succumbing to DoS attacks that can leave the management engine unavailable. ScreenOS do at least the policy lookup on the control plane.
 * The SRX 210 has a whopping 1gb of flash.
 * Changes made to the SRX aren’t put into action as soon as you hit enter. After changes are made a “commit” must be done to save changes and put them into the running configuration.
 * Unit checks changes to ensure config makes sense before committing. Otherwise an error is returned and config is not committed.
 * The SRX makes a backup of the current config when you perform a “commit”, this way if the changes you made don’t work, you can roll back to the last config. You can have up to 49 rollback points. You can also setup the SRX ftp the backup config to a server every time you perform a commit.
 * You can create a rescue config save point. So that  when you default a box, it goes to the Rescue config rather than the factory default.
 * Can do pattern search and replace commands in the config “ex replace 1.1.1.1 with 2.2.2.2” without having to manually scour the config.
 * Configuration is a bit cumbersome at first. Commands are long winded and wordy, but the autocomplete works very well!
 * With a root login, you are able to access the underlying BSD OS. This can be very dangerous in the hands of a inexperienced user, but also has its advantages (can perform administrative functions that are unavailable in most other vendor devices).
 * ScreenOS cannot separate the running of tasks from the kernel. All processes effectively run with the same privileges. Because of this, if any part of ScreenOS were to crash or fail, the entire OS would end up crashing or failing.
 * The modular architecture of Junos allows for the addition of new services.


 * With its ASIC-focused architecture, it allowed for amazing performance for stateful firewalling but poor performance deeper in the packet. Junos had the necessary underpinnings to allow for deeper inspection.


 * ScreenOS introduced the concept of zones to the firewall world. It increases the overall speed of policy lookup, and because multiple zones are always used in a firewall, it separates the overall firewall rulebase into many subsets of zone groupings. Junos also uses the same concept.

MIP in SRX
InternetSRX---Webserver 1.1.1.10           192.168.1.10

Interfaces: ge-0/0/1.0 = Internet  1.1.1.1/24 ge-0/0/0.0 = Internal  192.168.1.1/24

IP addresses: MAPPED IP		 1.1.1.10 HOST IP ADDRESS        192.168.1.10

Required Configuration: set security nat proxy-arp interface ge-0/0/1.0 address 1.1.1.10/32 set security nat static rule-set static-nat from zone Internal set security nat static rule-set static-nat rule rule1 match destination-address 1.1.1.10 set security nat static rule-set static-nat rule rule1 then static-nat prefix 192.168.1.10 set security zones security-zone Internet address-book address webserver 192.168.1.10 set security policies from-zone Internal to-zone Internet policy static-nat match source-address any destination-address webserver application junos-http set security policies from-zone Internal to-zone Internet policy static-nat then permit

Enable SSH
set system services ssh set system services ssh protocol-version v2 set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ssh

Configurational hierarchy

 * Interface-level configuration overrides the zone-level configuration.

user@host# set security-zone HR host-inbound-traffic system-services all
 * Can configure the statement under the entire zone stanza:

user@host# set security-zone HR interfaces ge-0/0/1 host-inbound-traffic system-services http
 * Can configure the statement under an interface stanza within a zone(If both configured,this one will take effect):

HA Log processing Bug

 * Data plane will process traffic logs.
 * Data & Controll plane should be in same HA Node.
 * If Data plane is in Node 1, but control plane on Node0, logs will be generated by node 1 but not sent to node 0.
 * So no logs will be sent to control plane hence no logs will be generated.

Enable SRX Cluster
Source: juniper.net & rtoodtoo.net

Logical Interfaces: IFD.IFL       IP/mask           Security Zone reth0.0       10.10.10.1/24     Trusted reth1.0       20.20.20.1/24     Untrusted


 * Disable ethernet switching, vlans, control link, management ports(fxp0), Logical interfaces

set chassis cluster cluster-id 1 node 0 reboot set chassis cluster cluster-id 1 node 1 reboot
 * Add both firewalls into cluster

set groups node0 system host-name SRX-001 set groups node0 interfaces fxp0 unit 0 family inet address 172.16.20.1/24 set groups node1 system host-name SRX-002 set groups node1 interfaces fxp0 unit 0 family inet address 172.16.20.2/24 set apply-groups "${node}"
 * Setup host names and management IP addresses

set groups node0 system backup-router xx.xx.xx.xx destination 10.100.0.0/16 Since routing process is not running on Backup node, we require to configure backup router.
 * Managing both nodes from fxp0

xx.xx.xx.xx is the Backup Router IP address (device shown above along with 2 SRX firewalls).

10.100.0.0/16 is the subnet from where SRX is being accessed.KB15580,KB17161

set interfaces fab0 fabric-options member-interfaces ge-0/0/0 set interfaces fab1 fabric-options member-interfaces ge-3/0/0
 * Configure fabric links (data-plane, used to sync RTO’s)

set chassis cluster reth-count 2 set chassis cluster redundancy-group 0 node 0 priority 200 set chassis cluster redundancy-group 0 node 1 priority 100 set chassis cluster redundancy-group 1 node 0 priority 200 set chassis cluster redundancy-group 1 node 1 priority 100
 * Redundancy Group Config

set interfaces reth0 unit 0 family inet address 10.10.10.1/24 set interfaces ge-0/0/1 gigether-options redundant-parent reth0 set interfaces ge-3/0/1 gigether-options redundant-parent reth0 set interfaces reth0 redundant-ether-options redundancy-group 1 set security zones security-zone Trusted interfaces reth0.0
 * Redundant Ethernet Config

set interfaces reth1 unit 0 family inet address 20.20.20.1/24 set interfaces ge-0/0/2 gigether-options redundant-parent reth1 set interfaces ge-3/0/2 gigether-options redundant-parent reth1 set interfaces reth1 redundant-ether-options redundancy-group 1 set security zones security-zone Untrusted interfaces reth1.0

>show chassis cluster status >show chassis cluster data-plane interfaces >show chassis cluster interfaces >show chassis cluster status redundancy-group 1
 * Verifying configuration
 * 1) show chassis cluster

Note: In order to manage SRX Cluster, we need 3 IP address. 1 Common Interface IP address (reth0 or reth1) 2 IP addresses from a different subnet to be assigned to fxp0 interfaces

SRX Site to Site VPN

 * Route based VPN
 * Policy based VPN


 * References