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