- ScreenOS Architecture:
- ScreenOS Flow order
- Sanity Check
- 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 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
- 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.
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.
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
- 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.
- 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 188.8.131.52/24, then you can assign WebAuth an IP address in the 184.108.40.206/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
- 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.
Refer ScreenOS Troubleshooting page
blog comments powered by Disqus