Analysis
#1
Whenever you experience any unexpected behavior with routing, web filter or Application filter, you can consider two exercises,
- With the help of Packet Capture, monitor how the traffic is forwarded and which fw-rule ID forwards the traffic. This will give you a brief insight about what is happening with the packet.
- Check “drop-packet-capture” log and look for the reason and fw-rule ID for the drop.
- While capturing the drop logs, you can also look at the log-id to verify what is the cause of the drop. To understand the format for Log-ID refer the attached system log file to this post.
#2
This information will be helpful for SF internal working understanding and action to be taken on any packet received on SF interface which will be handled by any one in order,
Fragment Reassembly Module > Strict Policy Checking> Connection Bypass Module > DOS policy > Spoof checking > Connection tracking module for Stateful Inspection > Sequence checking > policy marking and firewall rule matching > Web Access Policy/AV/AS > IPS.
#3
Asymmetric routing is an unwanted situation in an IP network. It occurs when packets flowing in the same TCP connection flow through different routes.
Asymmetrical routing is when a packet takes a certain path from source host A across the network to destination host B but then a return packet takes a separate path from the source host B to destination host A. For normal data, this is not an issue, but for some special cases, like data traveling through stateful-inspection firewalls, this routing behaviour can cause problems.
To overcome Asymmetric Routing-
Logon to CLI Console via Telnet or SSH, go to option 4. Device Console. Execute:
console> set advanced-firewall bypass-stateful-firewall-config add source_network 10.x.x.0 source_netmask 255.255.255.0 dest_network 192.168.1.0 dest_netmask 255.255.255.0 console> set advanced-firewall bypass-stateful-firewall-config add source_network 192.168.1.0 source_netmask 255.255.255.0 dest_network 10.x.x.0 dest_netmask 255.255.255.0 show advance-firewall
Note:
- It is assumed that XG has all the routing information required to reach the remote subnet 10.x.x.0/24.
- If you are bypassing specific network from the advance firewall, Scanning and NATing will not apply to that network.
#4
If you face slow browsing/throughput or ping timeouts then execute, ifconfig (in advance shell) or show network interfaces (in device console) and check for errors, collisions, dropped numbers on the communicating interfaces. Try these steps in sequence, to find a resolution.
- Confirm that Quality of Service (QoS)’ is not limiting bandwidth.
- When you discover Error on interface output, Edit the interface object, and in the ‘Advanced Settings’ drop down menu, set the MTU to 1350. If that works, check with your ISP to help find the largest setting that works. If this doesn’t work, set the MTU back to its original value.
- If you discover Dropped packets, Change the Ethernet cable.
- If connected to a switch, change the switch port.
- If connected to a router or modem, change that device.
- On the ‘Hardware’ tab in ‘Interfaces & Routing >> Interfaces’, experiment with different settings of fixed speeds and duplex. Make the same settings on the router/switch/modem to which the interface connects. Before testing the change, reboot both devices to force them to renegotiate their connection speed.
- Finally, place a non-manageable switch intermediate to the ISP and Firewall.
#4.1
If Dropped, error and collision packets are not observed then the slowness can be associated with DNS, DoS, IPS and ISP.
- Check if DoS Settings are enabled from System > System Services > DoS & Spoof Protection. Note- Never restrict TCP Flood flag. If you discover dropped packet values here configure the DoS value at a value suitable for your network architecture.
- Check DNS configuration- If there is an Internal DNS server is configured for LAN users and all DNS requests are directed to it. Issues with the Internal DNS Server or the External DNS Server, to which it forwards requests, may result in overall slow browsing.
Resolution: To resolve this issue, contact appropriate administrators or Server vendors.
#4.2
If multiple ISP Links are terminated on XG and user systems are configured with a particular ISP’s DNS. In this case, the outgoing DNS traffic gets load balanced. Hence, Two (2) possibilities occur:
- If a DNS request travels through the ISP Link whose DNS is configured in user’s system, the request is resolved and turnaround time is good.
- If a DNS request travels through another ISP Link, the request is dropped because the DNS configured in user’s system does not match ISP’s DNS.
This results in only partial DNS requests in the network to be resolved, which ultimately leads to slow browsing.
Resolution: Configure a Static Route in XG that forwards all DNS Traffic to the ISP Link whose DNS is configured on user’s systems. You can configure Static Routes from Network > Static Route > Unicast.
XG LAN IP is configured as DNS in user systems. Issues with DNS configuration in XG may lead to slow browsing.
Go to System > Diagnostics > Services to check if DNS Service is running. If service is stopped, restart it by clicking Start.
XG resolves queries using DNS Servers in a top to bottom order. Hence, compare the response times of each Server and place the Server with the least response time at the top.
Refer https://community.sophos.com/kb/en-US/123191.
#5
High CPU, I will not go deep into this module but the best practice I would like to suggest will be to check if the Telnet or SSH Access is kept open on WAN in System > Administration > Device Access> WAN. Always disable SSH and Telnet access on the WAN side when it is not required.
Look for the IPS settings, take Telnet or SSH and go to option 4. Device Console. Execute: show ips-settings. If you discover maxpkts set to a higher value than 8, set it back to 8, unless it is configured via support for something particular.
#6
If you discover any glitches or misbehavior on the GUI section for XG then, restart TOMCAT service from the advance shell. Tomcat service is responsible for generating the opcode for the GUI configurations in the backend. command: service tomcat:restart -ds nosync
#7 – High Availability Prerequisites
Same model, numbers of ports and vendor details should be same, the Same version.
- HA is not supported if WAN links are configured with DHCP or PPPoE. It means HA is also not supported for wireless models.
- HA must be disabled on the auxiliary appliance. You would need to enable HA from a primary appliance and it will automatically enable HA for the auxiliary appliance.
- Dedicated HA port should be in DMZ zone and SSH access should be enabled for DMZ in both the appliances.
- HA peers are physically connected using a crossover cable through this port. The same port must also be used as an HA link port on the peer device. For example, if port E is configured as HA link port on the primary device then use port E only as HA link port on the auxiliary device. Make sure that the IP address of the HA link port for both, the primary device and auxiliary devices are in same subnet.
- No alias or VLAN should be configured on dedicated HA port.
- MTU/MSS and link speed should be default on dedicated HA port. We recommend connecting dedicated HA link directly between two appliances.
Models that do not support HA- All wireless models of XG, SG and CR series as well as CR15i.
#8 – STAS
One of the smallest configuration mistakes while configuring STAS is the TIME. The time difference between the XG firewall and the Domain Controller should not be more than 5 minutes. When the STAS logs have the user information but the user is not authenticated on the XG firewall & the live user UI is not populated with the User, then this could be related to the time settings.
#9 – DNAT/FullNAT
If you find the option, Mapped Port is greyed out in the “Forward to” section, then you might want to verify the service definition with these points:
- If no TCP/UDP Service Selected -> Disable mapped port option
- If multiple services are selected -> Disable mapped port option
- If Service selected is with TCP/UDP combination -> Disable mapped port option
- If service group is selected -> Disable mapped port option
- If Service selected has only TCP or UDP ports, then it must not exceed 16 ports
- Public service cannot have both ports and range
- Public service should have a single range of ports
- Mapped port should have equal number of ports as given in public service or mapped port should have a single port.