Basics

ScreenOS Architecture:

ScreenOS Flow order

Sanity Check
Screening
Session lookup
Route Lookup
Policy lookup
Session creation
ARP lookup

Route preference order

Policy Based Routing
Source Interface Based Routing
Source Routing
Destination Routing

Timeout Values

Pseudo Session  =  20 sec
TCP             =  30 min
UDP             =  1 min
DNS             =  1 min; DNS-ALG closes session after reply.
ICMP            =  1 min; Reply closes session.
Phase 1         =  8 hours
Phase 2         =  1 hours

Functions of ALG:

Dynamically open/close ports
Perform NAT (wherever required)
UTM features
Open and close sessions

Preference vs Metric:

Preference: A weight that determines the best path for traffic to reach its destination. Enter a value between 0 and 255.
Metric: Indicates the priority associated with the route being added to the route table. Enter a value between 1 and 65535
The Netscreen will look at preference value first.  If the preference on two routes are the same the it will use metric value

SYN Flood Protection:

Threshold = Proxy connections above this limit
If Syn-cookie is enabled, no sessions established between client & firewall or firewall & server directly
Alarm Threshold = Alarm/Alert (to log)
Queue Size = The number of proxied connections held in queue
After this the firewall starts rejecting new connection requests
Timeout Value is maximum time before a half-completed connection is dropped from the queue
The range is 0–50s; default is 20s

NAT

NAT Preference order

1. Mapped IP
2. Virtual IP
3. Policy Based NAT (NAT-Src & NAT-Dst)
4. Interface Based NAT

MIP: One to one bidirectional natting. Requires policy from Untrust to Trust. Can be used to Map whole subnet depending upon mask.
VIP: Outside to inside unidirectional NAT for internal resource accessing. Can be achieved by NAT-Dst+Internal route+DIP entry for Public IP.
VIP cannot be pinged or tracert as there is no port number for ping

Fragmentation

Three types of MSS in ScreenOS Firewalls:

set flow all-tcp-mss 1460 command is applicable to clear-text traffic i.e. it can be used to change the MSS value for the SYN packet of the TCP handshake outside the tunnel; that is clear text traffic. It is required when using PPPoE, as PPPoE adds considerable overhead and fragmentation will occur, if this command is not enabled. For example, when accessing a web site and not all images are displayed, this symptom could be due to fragmentation. Applying the set flow all-tcp-mss command can resolve this issue.
set flow tcp-mss 1350 command is applicable to only VPN traffic i.e. it can be used to change the MSS value for the SYN packet of the TCP handshake within the Tunnel
set tcp mss 1460 command (without the 'flow' parameter)is applicable to the TCP/IP stack of the firewall and communication from/to the firewall; that is management of the firewall.

Explanation:

The set flow tcp-mss command is applicable for only VPN traffic. It affects only the firewall that performs the encrypting. For example, with the following topology:

   PC-A -----FW1--------VPN TUNNEL-----------FW2--------PC-B

Only FW2 is set with this command:

   FW2-> set flow tcp-mss 1350

Then, if the session is established from PC-A to PC-B, PC-A sends the SYN packet via the tunnel. FW1 does not change the TCP-MSS setting. When the packet is received by FW2, the TCP-MSS setting will not be changed, as the packet is already decrypted. In other words, the TCP-MSS setting will be changed, only if the command is set on the firewall on which the packet is encrypted; not on the firewall on which the packet is being decrypted.

If you want to change the MSS setting for the sessions that originate from PC-A via the tunnel, then set flow tcp-mss 1350 has to be set on FW1.

set flow all-tcp-mss settings are applied to only clear traffic. It is bi-directional; so the MSS value in the SYN packet is modified for the clear traffic.

For example, in the above scenario/topology, assume that the following command is also added to FW2:

   FW2-> set flow all-tcp-mss 1350

Then, when PC-A establishes a session with PC-B, FW2 will change the TCP-MSS setting for the sessions that originate from PC-A to PC-B, as it is applicable to the packet, after it is decrypted.

Verify:

SSG320-> get flow(when mss has not been set)
flow action flag: 0094
flow GRE outbound tcp-mss is not set
flow GRE inbound tcp-mss is not set
flow change tcp mss option for all packets is not set
flow change tcp mss option for outbound vpn packets is not set
flow change tcp mss option for bi-directional vpn packets is not set
flow deny session disabled
TCP syn-proxy syn-cookie disabled
Log dropped packet disabled
Log auth dropped packet disabled

SSG320-> set flow tcp-mss 1350
SSG320-> set flow all-tcp-mss 1460

SSG320-> get flow(when mss has been set)
flow action flag: 0495
flow GRE outbound tcp-mss is not set
flow GRE inbound tcp-mss is not set
flow change tcp mss option for all packets = 1460
flow change tcp mss option for outbound vpn packets = 1350
flow change tcp mss option for bi-directional vpn packets is not set
flow deny session disabled
TCP syn-proxy syn-cookie disabled
Log dropped packet disabled
Log auth dropped packet disabled

Traffic Shaping

In Traffic Shaping, there are eight queues:

High priority
2nd priority
3rd priority
4th priority
5th priority
6th priority
7th priority
Low priority (default)

For Guaranteed Bandwidth, the bandwidth is reserved for the policy and is dedicated for that policy only.

Maximum Bandwidth can be shared.

WebAuth IP

The WebAuth address must be in the same subnet as the interface that you want to use to host it. For example, if you want auth users to connect to WebAuth via ethernet3, which has IP address 1.1.1.1/24, then you can assign WebAuth an IP address in the 1.1.1.0/24 subnet.

You can put a WebAuth address in the same subnet as the IP address of any physical interface, subinterface, or virtual security interface (VSI). (For information about different types of interfaces, see “Interfaces” on page 47.)

Webauth IP should not be same as Interface IP address.

If you want to use WebAuth while in transparent mode, you can put a WebAuth address in the same subnet as the VLAN1 IP address.

You can put WebAuth addresses on multiple interfaces.

If you have multiple interfaces bound to the same security zone, you can put a WebAuth address in a subnet on one interface, and traffic from the same zone but using a different interface can still reach it.

You should be aware that after a security device authenticates a user at a particular source IP address, it subsequently permits traffic—as specified in the policy requiring authentication via WebAuth—from any other user at that same address. This might be the case if the users originate traffic from behind a NAT device that changes all original source addresses to a single translated address.

You can direct the device to accept only SSL (HTTPS) connections for WebAuth sessions.

Firewall = Self traffic auth
WebAuth = Pass thru traffic auth

Manage IP

The Manage IP address differs from the VLAN1 address in the following two ways:
- When the security device is in transparent mode, the VLAN1 IP address can be the endpoint of a VPN tunnel, but the Manage IP address cannot.
- You can define multiple Manage IP addresses—one for each network interface—but you can only define one VLAN1 IP address—for the entire system.

The restriction for configuring Manage-ip addresses is that it must be in the same subnet as the associated interface address, and it must also be unique.

ARP to restrict IP

Add a static ARP entry in the Firewall/Router if you want the next hop device to be reachable by only a single IP address. This will enable only a single IP to be able to resolve the MAC address queries. All others will fail.

Troubleshooting

Refer ScreenOS Troubleshooting page

{{#widget:DISQUS |id=networkm |uniqid=ScreenOS |url=https://aman.awiki.org/wiki/ScreenOS }}