Dump
Windows Script Backup ScreenOS
@echo off
REM ================================================================
REM ===This Script may give following error:
REM ===FATAL ERROR: Network error: Connection timed out ==> Check IP addresses
REM ===FATAL ERROR: Network error: Connection refused ==> Check SSH Parameters on Firewall
REM ===WARNING - POTENTIAL SECURITY BREACH! ==> SSH Public Keys changed/recalculated
REM ===Access denied ==> Password wrong
REM ================================================================
REM ===No of times "Access denied" message appears ==> no of wrong firewalls with wrong pwds
REM ================================================================
REM ===Configurable Parameters
REM ================================================================
set username=aman
set CFGFILE=BackupList.txt
set DESTDIR=Backups\
REM ================================================================
REM ===Script code starts here
REM ================================================================
SET TIMESTAMP=%date:~-4,4%.%date:~-7,2%.%date:~-10,2%
for /F "tokens=1,2,3 delims=," %%A in (%CFGFILE%) do (
IF NOT EXIST "%DESTDIR%%TIMESTAMP%" mkdir "%DESTDIR%%TIMESTAMP%"
plink -ssh -C -batch -pw %%C %username%@%%B get config > "%DESTDIR%%TIMESTAMP%\%%A.cfg"
)
echo Backup completed
"BackupList.txt" file:
R1,192.168.1.3,cisco R2,192.168.1.4,cisco2
Need to download Plink from this Link
HA Best Practices
Basic: 1. Two Firewalls should have same Hardware(Model, Modules, Ram, Ports, etc) 2. Firmware should be exactly same i.e. Major, Minor as well as Patch version 3. Licenses & features on both firewalls should be same (Basic, Advanced, AV, DI, AS, Web filtering, etc) 4. One firewall with expired license should be not put in cluster with a firewall with no license as it may cause them to become out of sync & different free memory. 5. It is recommended to configure cluster with 2 dedicated HA links. 6. VSD Group should be 0. If it is not 0, need to assign interfaces to that VSD Group on both firewalls. 7. Console access is always recommended before Configuring/ Implementing/ Troubleshooting NSRP issues. 8. Hostnames of the firewalls should be different to differentiate between devices. Preempt: 1. Preempt should be enabled. 2. Hold-down timer should have a higher value (~120-180 seconds) to prevent NSRP failover flapping. 3. Preempt need not be configured on the backup device. 4. It should not be configured in environments with dynamic routing protocols due to protocol re-convergence. 5. The priority of the preferred backup should be a higher value, as the lower priority takes precedence. Interface Monitoring: 1. Only add critical interfaces to Monitoring to avoid unnecessary failovers/preempts. Track-IP: 1. Track-IP is necessary to achieving a successful failover event, when the primary Juniper firewall stops passing traffic; but the monitored interfaces remain up while using interface monitoring only. 2. Need to determine one or more hosts that can reliably respond to ICMP/ARP traffic. Master-Always-Exist: 1. With NSRP monitoring enabled, both NSRP peers can become 'Inoperable'. Enabling the master-always-exist option will ensure that the cluster remains available. 2. Run the command “set nsrp vsd-group master-always-exist” only on Master & it will sync to Backup automatically. Secondary-path: 1. To avoid Split Brain, Configure NSRP with 2 dedicated HA links. 2. The secondary-path option allows NSRP to poll the peer via an alternate, non-dedicated interface. The purpose is only to prevent a split-brain scenario, so NSRP sync data is not carried across this link, only heart-beat messages. RTO Sync: 1. Backup Session Timeout Acknowledge should be enabled 2. Route Synchronization should not be used unless Dynamic Routing Protocol is running. HA probe: 1. HA probe must be enabled if the HA links are connected through a layer 2 switch. 2. It should NOT be used if they are directly connected. 3. Duplex settings on the switch and firewall interfaces should match. Authentication & Encryption password: 1. Use NSRP Authentication & Encryption if the HA Cables connect through a layer 2 switch. 2. No need to use Authentication & Encryption if they are directly connected. Misc: 1. While adding secondary firewall in a cluster, Interface-based Default Route such as “set interface <interface name> gateway <gateway address>” will result in loss of communication as the Interface will become Inactive. Need to add regular Default Route before proceeding. 2. Duplicate MAC address seen when 2 set of NSRP Clusters with same Cluster ID and VSD-Group are attached to the same switch/or are in same Broadcast Domain. Changing the Cluster ID or VSD group number will resolve the issue. KBs Referred: http://kb.juniper.net/KB9311 http://kb.juniper.net/KB9309 http://kb.juniper.net/KB11432
SRX Import config
1. load system terminal Merge|Replace|~~~
{}{}{}{}
Cntl+D
commit
2. Edit
Set...
set... one by one
commit
Juniper SRX Firewalls
**********************
Juniper SRX Firewalls
**********************
run = used in configure mode to use operational mode commands
//Show Routes
show route brief
show route best x.x.x.x
set routing-options static route 10.2.2.0/24 next-hop 10.1.1.254
//Forwarding Table
run show route forwarding-table destination x.x.x.x/24
//TraceOptions settings
root@fw1# show security flow | display set
set security flow traceoptions file matt_trace
set security flow traceoptions file files 3
set security flow traceoptions file size 100000
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter f0 source-prefix 10.0.0.1/32 destination-prefix 200.1.2.3/32
set security flow traceoptions packet-filter f1 source-prefix 10.0.0.1/32 destination-prefix 200.1.2.3/32
activate security flow traceoptions
commit
monitor start matt_trace
monitor list
!! Kill the capture
monitor stop <captureFileName>
clear log <captureFileName> !! Clear the log file
delete security flow traceoptions
commit
file delete <captureFileName>
//Show Traceoptions
show security flow session source-prefix 10.124.80.42 destination-prefix 117.1.1.25
start shell
egrep ‘matched filter|(ge|fe|reth)-.*->.*|session found|create session|dst_xlate|routed|search|denied|src_xlate|outgoing phy if’ /var/log/matt_trace | sed -e ‘s/.*RT://g’ | sed -e ‘s/tcp, flag 2 syn/–TCP SYN–/g’ | sed -e ‘s/tcp, flag 12 syn ack/–TCP SYN\/ACK–/g’ | sed -e ‘s/tcp, flag 10/–TCP ACK–/g’ | sed -e ‘s/tcp, flag 4 rst/–TCP RST–/g’ | sed -e ‘s/tcp, flag 14 rst/–TCP RST\/ACK–/g’ | sed -e ‘s/tcp, flag 18/–TCP PUSH\/ACK–/g’ | sed -e ‘s/tcp, flag 11 fin/–TCP FIN\/ACK–/g’ | sed -e ‘s/tcp, flag 5/–TCP FIN\/RST–/g’ | sed -e ‘s/icmp, (0\/0)/–ICMP Echo Reply–/g’ | sed -e ‘s/icmp, (8\/0)/–ICMP Echo Request–/g’ | sed -e ‘s/icmp, (3\/0)/–ICMP Destination Unreachable–/g’ | sed -e ‘s/icmp, (11\/0)/–ICMP Time Exceeded–/g’ | awk ‘/matched/ {print “\n\t\t\t=== PACKET START ===”}; {print};’
//Show Sessions
run show security flow session destination-prefix x.x.x.x
//Match Policy
run show security match-policies from-zone zonea to-zone zoneb source-ip x.x.x.x destination-ip x.x.x.x protocol tcp source-port 1024 destination-port xx
//Check for Block Group
show security policies from-zone untrust to-zone trust | display set | grep deny
//Find Syntax for an Existing Command
show | display set | xxxxxxxxx
//VPN Troubleshooting
show security ike security-associations [index <ID>] [detail]
show security ipsec security-associations [index <ID>] [detail]
show security ipsec statistics [index <ID>]
//VPN
//Set proxy ID’s for a route based tunnel
set security ipsec vpn vpn-name ike proxy-identity local 10.0.0.0/8 remote 192.168.1.0/24 service any
//Packet Capture
set security datapath-debug capture-file my-capture
set security datapath-debug capture-file format pcap
set security datapath-debug capture-file size 1m
set security datapath-debug capture-file files 5
set security datapath-debug maximum-capture-size 400
set security datapath-debug action-profile do-capture event np-ingress packet-dump
set security datapath-debug packet-filter my-filter action-profile do-capture
set security datapath-debug packet-filter my-filter source-prefix 1.2.3.4/32
//Super SRX Packet Capture Filter
egrep ‘matched filter|(ge|fe|reth ) -.*- > .*|session found|Session \(id|session id|create|dst_nat|chose interface|dst_xlate|routed|search|denied|src_xlate|dip id|outgoing phy if|route to|DEST|post’ /var/log/mchtrace | uniq | sed -e ‘s/.*RT://g’ | awk ‘/matched/ {print “\n\t\t\t=== PACKET START ===”} ; {print} ;’ | awk ‘/^$/ {print “\t\t\t=== PACKET END ===”}; {print};’ ; echo | awk ‘/^$/ {print “\t\t\t=== PACKET END ===”}; {print};’
// Policy commands
show | display set (shows policy)
set system syslog
set security log
set interfaces ge-0/0/3 gigether-options auto-negotation (redundant-parent)
set security policies from-zone xxx to-zone xxx policy policy_name match
set security zones security-zone untrust address-book address
set security nat source rule-set zone-to-zone rule rule-source-nat match source-address 10.0.0.0
set routing-instances
set applications
set security ike proposal
set security ike policy
set security ike gateway
set security ipsec proposal
set security ipsec policy
set security ipsec vpn
show|compare
commit check
commit comments ticket#2222 and-quit
set security policies from-zone dmz to-zone trust policy 12 match source-address h_10.124.0.1 destination-address h_1.2.3.4 application tcp_22
set security policies from-zone dmz to-zone trust policy 12 then permit
set security policies from-zone dmz to-zone trust policy 12 then log session-init session-close
+ match {
+ source-address h_10.124.0.1;
+ destination-address h_1.2.3.4;
+ application tcp_22;
+ }
+ then {
+ permit;
+ log {
+ session-init;
+ session-close;
+ }
+ }
+ }
Various:
show system uptime Uptime
show version Version of platform (host/model)
show chassis firmware Firmware loaded on FPCs
show system software detail
show chassis routing-engine CPU, Memory for Routing-Engine
show chassis fan Speed and status of fans
show chassis environment Temperature status of components
show chassis hardware detail Hardware inventory (backplane)
show system core-dumps Core-dumps
show system alarms System alarms
show chassis alarms Alarms for hardware and chassis
show system boot-messages Logs from boot sequence
show log chassisd Logs for SRX chassis (Cards)
show log messages Recent system messages
show configuration security log Syslog configuration
show system buffers Utilization of memory buffers
show system virtual-memory Virtual memory utilization
show system processes Processes running on system
show security idp memory IDP memory statistics
show security monitoring performance session Session counts on each FPC
MIP in a policy-based VPN [1]
This work-around is for configuring a Mapped Internet Protocol (MIP) address in a policy-based VPN, where they are typically created on tunnel interfaces in a route-based VPN. This workaround applies when the customer requirement does not allow for a route-based VPN.
Customer requirements:
A site-to-site VPN tunnel between a Juniper firewall and a Cisco. The Cisco Peer IP address and the Remote subnet must use the same Public IP address. MIPs need to be configured for the servers behind the Juniper Firewall.
For these requirements, a route-based VPN on the Juniper firewall is not an option because a route is needed to the remote network pointing to the tunnel interface. If the peer IP and remote IP addresses are the same for both devices, the IKE negotiation can not be established.
A policy-based VPN can be configured for this design, since only a default route is needed and then a policy can be used to determine the VPN.
On the Juniper firewall, a MIP needs to be configured for the servers on the private network, which need to be accessed via a VPN from the Cisco site. However, MIPs are not directly supported in policy-based VPN.
If the outgoing interface is in a zone other than Untrust (for example, zone is ISP), follow KB27122- [ScreenOS] How to configure a MIP in a policy based VPN when outgoing interface is in zone other than Untrust
Untrust-Tun is the Tunnel type zone, carrier zone that helps encryption-decryption
set interface tunnel.1 zone Untrust-Tun
Fixed IP on the tunnel interface
set interface tunnel.1 ip 4.4.4.10/24
MIP will be used by the cisco-remote network to connect to server behind the Juniper firewall's local network
set interface tunnel.1 mip 4.4.4.11 host 20.20.20.5 netmask 255.255.255.255
A route needs to be added to send the traffic to the tunnel interface:
set route 25.34.5.7 interface tunnel.1
Phase 1 configuration:
set ike gateway Netscreen-Cisco-IKE address 25.34.5.7 main outgoing-interface ethernet4 preshare test sec-level standard
Phase 2 configuration:
set vpn Netscreen-Cisco-VPN gateway Netscreen-Cisco-IKE sec-level standard
Bind Tunnel Zone (Juniper firewall will recognize the MIP configured on the tunnel interface):
set vpn Netscreen-Cisco-VPN bind zone Untrust-Tun
Then an appropriate access-list needs to be configured on the Cisco end to support Proxy-IDs generated by the polices in the Juniper firewall.
set policy from untrust to trust 2.2.2.2/32 MIP (4.4.4.10) any tunnel vpn Netscreen-Cisco-VPN log set policy from trust to untrust 20.20.20.5/32 2.2.2.2/32 any tunnel vpn Netscreen-Cisco-VPN log
Note:
The MIP will work in only one direction. If traffic needs to be initiated from the Netscreen Trust zone over the tunnel and that traffic must use NAT, then a DIP is required, and the DIP cannot use the same IP as the MIP. This is a limitation. If a bi-directional MIP is required a route based VPN must be used.
Workaround if outgoing is other than Untrust Zone
If the outgoing interface is in a zone other than Untrust (for example, zone is ISP) proceed with following:
set zone "ISP" set internet ethernet0/2 zone "ISP"
ISP is the zone for outgoing interface ethernet0/2:
set internet ethernet0/2 ip 1.1.1.1/24
ISP-Tun zone is the carrier zone for the tunnel for NAT-ing:
set zone "ISP-Tun" tunnel ISP
Untrust-Tun is the Tunnel type zone, carrier zone that helps encryption-decryption:
set interface tunnel.1 zone ISP-Tun
Fixed IP on the tunnel interface
set interface tunnel.1 ip 4.4.4.10/24
MIP will be used by the remote network to connect to server behind the ScreenOS firewall's local network:
set interface tunnel.1 mip 4.4.4.11 host 20.20.20.5 netmask 255.255.255.255
A route needs to be added to send the traffic to the tunnel interface; for the translation to take place:
set route 6.7.8.9/32 interface tunnel.1
Phase 1 configuration:
set ike gateway Netscreen-IKE address 2.2.2.2 main outgoing-interface ethernet0/2 preshare test sec-level standard
Phase 2 configuration:
set vpn Netscreen-VPN gateway Netscreen-IKE sec-level standard
Bind Tunnel Zone (ScreenOS firewall will identify the MIP configured on the tunnel interface):
set vpn Netscreen-VPN bind zone Untrust-Tun
Then an appropriate access-list must be configured on the remote end to support Proxy-IDs generated by the polices in the ScreenOS firewall.
set policy from ISP to trust 6.7.8.9/32 MIP (4.4.4.11) any tunnel vpn Netscreen-VPN log set policy from trust to ISP 20.20.20.5/32 6.7.8.9/32 any tunnel vpn Netscreen-VPN log
get sa detail
CORPORATE-> get sa total configured sa: 1 HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys 00000001< 2.2.2.2 500 esp:3des/sha1 c2e1f0e4 3296 unlim A/- -1 0 00000001> 2.2.2.2 500 esp:3des/sha1 74098e47 3296 unlim A/- -1 0
We can see that the remote peer is 2.2.2.2. The State shows A/-. The possible states are below:
I/I SA Inactive. VPN is currently not connected. A/- SA is Active, VPN monitoring is not enabled A/D SA is Active, VPN monitoring is enabled but failing thus DOWN A/U SA is Active, VPN monitoring is enabled and UP
Gateway IP address for Next Hop
Why is it necessary to specify 'Gateway IP address for Next Hop' during the configuration of static default route?
- Scenario I
- Next-hop gateway IP address is not specified in the static default route.
SSG-> set route 0.0.0.0/0 int eth0/1 SSG-> get db st route to 4.2.2.2 cached arp entry with MAC 000000000000 for 4.2.2.2 add arp entry with MAC 000000000000 for 4.2.2.2 to cache table wait for arp rsp for 4.2.2.2 ifp2 ethernet0/1, out_ifp ethernet0/1, flag 10000e00, tunnel ffffffff, rc 0 outgoing wing prepared, not ready SSG-> get route | i 4.2.2.2 * 16 0.0.0.0/0 eth0/1 0.0.0.0 S 20 1 Root
Because the next-hop IP address is not specified in the default route, the firewall is doing an ARP for 4.2.2.2.
When the firewall needs to forward a packet via the default route, it needs the MAC address of the default router in order to build the frame to forward the packet.
The reason for the failure is that the firewall is waiting for an ARP response from 4.2.2.2, as if it was on a connected segment. This is indicated by the 'wait for arp rsp for 4.2.2.2', which it never receives.
It then drops the packet with the message 'outgoing wing prepared, not ready' which indicates that there is no ARP response;
- Scenario II
- Next-hop gateway ip address is specified in the static default route.
SSG-> set route 0.0.0.0/0 int eth0/1 gateway 1.1.1.2 SSG-> get db st route to 1.1.1.2 cached arp entry with MAC 000000000000 for 1.1.1.2 add arp entry with MAC 002688e8c305 for 1.1.1.2 to cache table arp entry found for 1.1.1.2 ifp2 ethernet0/1, out_ifp ethernet0/1, flag 10800e00, tunnel ffffffff, rc 1 outgoing wing prepared, ready SSG-> get route | i 4.2.2.2 * 15 0.0.0.0/0 eth0/1 1.1.1.2 S 20 1 Root
In this scenario, the firewall found the MAC address for the next-hop gateway (ISP router with ip 1.1.1.2) in its ARP table.
It was then able to build the frame and forward the packet to the ISP router, which in turn routed the packet to its next hop, until the packet reached the destination IP 4.2.2.2.
SRX Stuck on old technology
The SRX uses stateful inspection which relies on port and protocol for policy decisions, a technique that is ineffective at controlling applications that use dynamic ports, encryption, or tunnel across often used/allowed ports to bypass firewalls.
Stateful Inspection
This solution allows calls to come from any port on an inside machine, and will direct them to port 25 on the outside.
So why is it wrong?
Our defined restriction is based solely on the outside host’s port number, which we have no way of controlling. Now an enemy
can access any internal machines and port by originating his call from port 25 on the outside machine.
What can be a better solution ?
The ACK signifies that the packet is part of an ongoing conversation Packets without the ACK are connection establishment messages, which we are only permitting from internal hosts
Sub interface number
The maximum permitable number for sub interface number in Juniper SSG140 firewall is 100. The firewall will accept a number in the range of 1-100 only. Sub Interface names in Juniper Netscreen firewalls are like: eth0/1.50, eth0/2.100. A name like eth0/2.101 or eth0/2.200 will not be acceptable.
Window size smaller that MTU
If window size is smaller than MTU, packet retransmissions will occur. This is an application issue. This means buffer size is smaller & lager packets are received.
- ↑ www.bt.com/india