SRX
Architecture
Source: juniper.net
- JUNOS runs on top of FreeBSD.
Details of Flow
- What happens in "TCP" section of the flow?
3 Way Handshake check Sequence no check Acknowledge check
- Where are the TCP parameters checked?
It is check in First path & Fast path both.
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).
- 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.
200.200.200.1-------SRX-------192.168.1.10(FTP) | | 192.168.2.10
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 { <PHYSICAL PROPERTIES HERE> 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 { <LOGICAL PROPERTIES HERE> } } }
- There are many different protocol families that you can configure. Some of them include inet (IPv4), inet6 (IPv6), iso, mpls, and ethernet-switching.
- 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 "<interface> unit <#>" or "<interface>.<#>.
[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
- 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.
- To configure multiple protocol families on an interface, you do it like this
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; } } } }
- 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 Config
- Junos Stores 49 previously committed configurations on its storage device.
- The factory default for the maximum number of backup configurations allowed is 5.[1]
- Rollback number 0 is the current running configuration - before commit, If after commit = rollback 1
rollback 5 commit
- 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
- 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
user@SRX240>
- Configuration Mode
- 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#
- 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] user@SRX240# edit interfaces [edit interfaces] user@SRX240# show ge-0/0/0 { unit 0 { family inet { address 6.6.6.6/30; } } }
- We can also view a specific section of the tree by specifying it in the show command like so
[edit] user@SRX240# show interfaces ge-0/0/0 { unit 0 { family inet { address 6.6.6.6/30; } } }
- You can also run any Operational Mode command in Configuration Mode by appending "run" to the beginning of it like so:
[edit] user@SRX240# run ping 4.2.2.2 rapid count 5
- Show
- This shows everything in the configuration from the current level down
[edit] user@SRX240# show
- Reference
- Help reference will show you everything you need to know about a given command
[edit] user@SRX240# help reference interfaces address
- Apropos
- 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
[edit] user@SRX240# help apropos ssh
Taking Debug in SRX
- Configure Traceoptions
set <option> traceoptions file filename files (default 10) size (default 128k) read permissions (e.g. world-readable) set <option> traceoptions flag (define what you want to look at)
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
Packet Captures
Capture control traffic to Routing Engine
Packet Capture of control traffic to and from the RE of the SRX :
> monitor traffic interface <int> 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):
This section is under construction. |
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 <file> Send Logs to terminal (like tail -f)
SRX vs ScreenOS [2]
- 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.
Comparison of SRX & ScreenOS commands
Session & Interface counters
ScreenOS | SRX |
---|---|
get session | show security flow session |
get interface | show interface terse |
get counter stat | show interface extensive |
get counter stat <interface> | show interface <interface> extensive |
clear counter stat | clear interface statistics <interface> |
Debug & Snoop
ScreenOS | SRX |
---|---|
debug flow basic | # edit security flow # set traceoptions flag basic-datapath # commit |
set ff | # edit security flow # set traceoptions packet-filter |
get ff | > show configuration | match packet-filter | display set |
get debug | > show configuration | match traceoptions | display set |
get db stream | View stored log: (recommended option) > show log <file name> (enter h to see help options) View real-time: (use this option with caution) |
clear db | > clear log <filename> (clears contents of file) |
undebug <debug> (stops collecting debugs) | # edit security flow # deactivate traceoptions OR # delete traceoptions (at the particular hierarchy) # commit |
undebug all | Not available. You need to deactivate or delete traceoptions separately. |
debug ike detail | > request security ike debug-enable local <local gw> remote <remore peer> level 7 |
Event Logs
ScreenOS | SRX |
---|---|
get event | > show log messages > show log messages | last 20 (helpful cmd because newest log entries are at end of file) |
get event | include <string> |
> show log messages | match <string> |
clear event | > clear log messages |
Snoop
This section is under construction. |
Config & Software upgrade
ScreenOS | SRX |
---|---|
get config | > show config (program structured format)
> show config | display set | no-more (set command format) |
get license | > show system license keys |
get chassis (serial numbers) | > show chassis hardware detail > show chas environment |
exec license | > request system license [add | delete |save] (Does not require a reboot on SRX, but does on ScreenOS) |
unset all reset |
load factory-default set system root-authentication plain-text-password commit and-quit request system reboot |
save config from tftp <tftp_server> <configfile> to flash | > start shell and FTP config to router, i.e. /var/tmp/test.cfg. Then: # load override /var/tmp/test.cfg |
save software from tftp <tftp_server> <screenosimage> to flash | request system software add ftp:1.1.1.11/jsr/junos-srxsme-9.5R1.8-domestic.tgz reboot -TFTP is not supported. Use only FTP. HTTP, or SCP -'request system software rollback' to rollback to previous s/w package |
save | # commit OR # commit and-quit |
reset | > request system reboot |
Policy
ScreenOS | SRX |
---|---|
get policy | > show security policies |
get policy from <zone> to <zone> | > show security policies from <zone> to <zone> |
VPN
ScreenOS | SRX |
---|---|
get ike cookie | > show security ike security-associations |
get sa | > show security ipsec security-associations > show security ipsec sa |
clear ike cookie | > clear security ike security-associations |
clear sa | > clear security ipsec security-associations |
High Availability
ScreenOS | SRX |
---|---|
get nsrp | > show chassis cluster status
> show chassis cluster interfaces |
exec nsrp vsd <vsd> mode backup (on master) | > request chassis cluster failover redundancy-group <group> node <node> |
> request chassis cluster failover reset redundancy-group <group> |
DHCP
ScreenOS | SRX |
---|---|
get dhcp client | > show system services dhcp client |
exec dhcp client <int> renew | > request system services dhcp renew (or release) (DHCPD) OR
> request dhcp client renew (JDHCPD) |
Routing
ScreenOS | SRX |
---|---|
get route | > show route |
get route ip <ipaddress> | > show route <ipaddress> |
get vr untrust-vr route | > show route instance untrust-vr |
get ospf nei | > show ospf neighbor |
set route 0.0.0.0/0 interface <int> gateway <ip> | # set routing-options static route 0.0.0.0/0 next-hop <ip> |
NAT
ScreenOS | SRX |
---|---|
get vip | > show security nat destination-nat summary |
get mip | > show security nat static-nat summary |
get dip | > show security nat source-nat summary
> show security nat source-nat pool <pool> |
Other
ScreenOS | SRX |
---|---|
get perf cpu | > show chassis routing-engine |
get net-pak s | > show system buffers |
get file | > show system storage |
get alg | > show security alg status |
get service | > show configuration groups junos-defaults applications |
get tech | > request support information |
set console page 0 | > set cli screen-length 0 |
Common Config commands
MIP in SRX
Internet------------SRX-----------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.
- Can configure the statement under the entire zone stanza:
user@host# set security-zone HR host-inbound-traffic system-services all
- Can configure the statement under an interface stanza within a zone(If both configured,this one will take effect):
user@host# set security-zone HR interfaces ge-0/0/1 host-inbound-traffic system-services http
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
- Add both firewalls into cluster
set chassis cluster cluster-id 1 node 0 reboot set chassis cluster cluster-id 1 node 1 reboot
- Setup host names and management IP addresses
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}"
- Managing both nodes from fxp0
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.
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
- Configure fabric links (data-plane, used to sync RTO’s)
set interfaces fab0 fabric-options member-interfaces ge-0/0/0 set interfaces fab1 fabric-options member-interfaces ge-3/0/0
- Redundancy Group Config
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
- Redundant Ethernet 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
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
- Verifying configuration
#show chassis cluster >show chassis cluster status >show chassis cluster data-plane interfaces >show chassis cluster interfaces >show chassis cluster status redundancy-group 1
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
- References
{{#widget:DISQUS
|id=networkm
|uniqid=SRX
|url=https://aman.awiki.org/wiki/SRX
}}