While I have some Checkpoint certifications, and my job title is Network Security Engineer, this does not make me an expert across all firewall products. Certainly, there are many similarities, and there is indeed a lot of transferable knowledge and skills, each product has it own set of unique things. This can vary as widely as how a packet is inspected, the order of NAT vs. firewall rules, etc... I came across a forum post on Sophos' website which I have been referring to quite often. For my own personal notes, I will put the important details below.

First off, let me be clear that I did not write these "rules"... I got them from the following Sophos forum page:

https://www.astaro.org/gateway-products/general-discussion/49065-rulz.html

All credit goes to "BAlfson" who made the original post. I just copy/pasted and fixed up some formatting.

The Zeroeth Rule:
Start with a hostname that is a unique (not used for anything else) FQDN resolvable in public DNS to your public IP. If you didn't do that, use slickone27's trick to get CAs, certificates, hostname entries, etc. all aligned; it will save you hours and frustration.

Rule #1:
Whenever something seems strange, always check the Intrusion Prevention, Application Control and Firewall logs. If 'Advanced Threat Protection' on the Dashboard is not zero, check that log also.

Rule #2:
In general, a packet arriving at an interface is handled only by one of the following, in order: the connection tracker (conntrack) first, then Country Blocking, then DNATs, then VPNs, then Proxies, then manual Routes and manual Firewall rules, which are considered only if the automatic Routes and rules coming before hadn't already handled the traffic and, finally, Applications Control. (see attachment below)

Rule #3:
Never create a Host/Network definition bound to a specific interface. Always leave all definitions with 'Interface: <<Any>>'.

Rule #3.1: Other solutions to routing problems include:

• Devices in the LAN must have the IP of "Internal (Address)" as their default gateway.
• Never connect two NICs into the same, physical Ethernet segment unless bridging or creating a LAG.
• When adding an interface, don't forget the Masquerading rule for the new network behind the UTM.

Rule #4:
When creating DNATs for traffic arriving from the internet, in "Going to:" always use the "(Address)" object created by WebAdmin when the interface or the Additional Address was defined. Using a regular Host object will cause the DNAT to fail as the packets won't qualify for the traffic selector.

Rule #5:
In NAT rules, it is a good habit to leave a field blank when not making a change. In the case of a service with a single destination port, this makes no difference. In the case of a service with multiple ports, or a Group, repeating the service makes the NAT rule ineffective.

Rule #6:
There are only six reasons to sync users from AD to the ASG/UTM:

1. The user is to be added to 'Allowed Administrators' or given a 'Role' on the 'Access Control' tab in 'WebAdmin Settings'.
2. The user needs access to the User Portal.
3. The user should be able to log on to a Remote Access VPN that uses certificates to authenticate the user.
4. Email Protection is enabled and the user should receive Quarantine Reports and be able to manage personal black/whitelists and/or use Email Encryption/Signing.
5. You want to do Reporting by Department for Web Protection.
6. You want to use the Authentication Agent to populate "username (User Network)" objects.

There's no other reason to sync users to WebAdmin - certainly not with AD-SSO.

Rule #7:
If you have slow throughput and/or ifconfig shows errors, collisions, etc., try these steps, in sequence, until your problem goes away:

1. If you have a Realtek, Marvel or 3Com NIC, skip to the last step.
2. Confirm that 'Interfaces & Routing >> Quality of Service (QoS)' is not limiting bandwidth. Also confirm that 'TCP window scaling' is enabled on the 'Advanced' tab of 'Network Protection >> Firewall'.
3. Edit the interface definition, and, in the 'Advanced' section, 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.
4. Change the Ethernet cable.
5. If connected to a switch, change the switch port.
6. If connected to a router or modem, change that device.
7. 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.
8. Move the interface definition to another eth on the UTM or replace the NIC with an identical one. If you have a Realtek, Marvel or 3Com NIC, you should replace the NIC with an Intel (NOT an Intel 82574 based NIC due to bugs from Intel that aren't fixed - the 210 series is good). Note that if you don't already have an Intel NIC, you will need to reload from ISO in order to install the driver for the new NIC

Rule #8:
Before changing the hardware the UTM runs on, go to 'Interfaces & Routing >> Interfaces' and, on the 'Hardware' tab, edit each NIC to have a 'Virtual MAC Address' that copies the existing MAC. This will cause your new NICs to be recognized immediately after the configuration is restored. The alternative is to make certain that each router/switch connected to the various NICs has cleared its ARP table:

• When changing UTM hardware or NICs, Always power-cycle any cable modems or other devices that lock MAC addresses.
• Some ISPs (FiOS) require calling ISP to break the lease, unless one does it manually (from the UTM console) when switching UTM hardware

I have beel diligently referring to these rules as I have been building out my Sophos Gateway. Like I said at the start of the article, there are many skills and knowledge that is equally applicable to Checkpoint or Sophos here. But these rules are helping my further understand some of those unique differences that exist between products.

Add comment