Understanding New decoupled NAT and firewall changes in v18

Question

Hi, 
 Based on the discussion and queries we have observed on various threads, here is the things to know about new decoupled NAT and firewall changes in v18. 
 Update - This in-depth video has been produced to help explain the new NAT changes in SFOS v18: https://player.vimeo.com/video/376241042 
 1) What is changed related to NAT in Sophos firewall v18? What is Decoupled NAT? Why we changed? 
 with v18, Sophos Firewall has moved towards more standardized NAT design in which network translation configuration is now decoupled from firewalling configuration for better manageability in the larger sized deployments. 
 Starting Sophos firewall v18, NAT is now a separate rule table that will be traversed from top to bottom prioritized rule set for network translation decisions. The configuration offers better flexibility, manageability with less number of NAT & firewall rules. With v18, Sophos Firewall&rsquo;s enterprise NAT capability is now at par with other competitive players. 
 
 The new design offers ease of configuration and management for all NAT capabilities: 
 
 Admin can configure Source translation, Destination translation or Full NAT translation in one NAT rule. 
 Admin can now create loopback (hair pinning) and reflexive NAT rule with One-Click UI options; created loopback and reflexive rule will be now visible on NAT table UI 
 Many to Many, One to Many, Many to one like load balance scenario and redundant network translations are now easy to configure in the same NAT rule with load balancing and health check methods. 
 admin can now configure NAT rule matching based on In and Out Interface as an added granular matching criteria. 
 
 Based on what we have been hearing from our customers, v18 now removes confusing business application firewall rule type existing in v17.x and earlier. destination NAT capability of the biz apps rule has been folded into the same NAT rule. Single firewall rule type can now achieve WAF (as a part of action) and other security configurations. 
 For customers who don't want to manage a separate NAT rule table, Sophos firewall v18 offers a differentiating LinkedNAT functionality - refer LinkedNAT specific FAQs for details. 
 
 2) I am running v17.x; will there be any impact/ behavior change on my existing deployment (specific to NAT) if I upgrade to v18? 
 No. We have implemented the migration in such a way that it will automatically migrate v17.x NAT configuration (integrated into firewall rule) to v18 NAT configurations. You need not to take any manual steps. 
 When you migrate from v17.x to v18, you would see many LinkedNAT rules already created &ndash; many of them could be with similar source NAT translation, for example &ndash; many rules with MASQ as source translation. We cannot consolidate/ optimize the same automatically during migration as there could be deployments with firewall rules on v17.x without any NAT configured. You can decide to manually optimize the NAT table by creating single source translation NAT rule that takes care of translating source for multiple firewall rules, for example - single MASQ rule at the bottom of the NAT table. And you can delete multiple LinkedNAT rule created during migration. 
 
 3) After upgrading to v18, I see many LinkedNAT rule created on the NAT rule table. Is this normal? Can you not optimize this further in the migration? 
 We have implemented the migration in such a way that it will automatically migrate v17.x NAT configuration (integrated into firewall rule) to v18 NAT configurations. You need not to take any manual steps. 
 When you migrate from v17.x to v18, you would see many LinkedNAT rules already created &ndash; many of them could be with similar source NAT translation, for example &ndash; many rules with MASQ as source translation. We cannot consolidate/ optimize the same automatically during migration as there could be deployments with firewall rules on v17.x without any NAT configured. You can decide to manually optimize the NAT table by creating single source translation NAT rule that takes care of translating source for multiple firewall rules, for example - single MASQ rule at the bottom of the NAT table. And you can delete multiple LinkedNAT rule created during migration. 
 
 4) After upgrading to v18, I see a non-editable checkbox on migrated firewall rules that says "Do not apply this migrated rule to system-destined traffic". Why it is there? 
 This is to retain the rule matching behavior of v17.x even though we have removed Business application rule type. 
 In SFOS 17.x and earlier, although business application rules and user-network rules were listed in a single rule table, Sophos Firewall evaluated these rule types independently to find matching criteria. For system-destined traffic (example: accessing Sophos Firewall services) and incoming traffic (example: to internal servers) that matches a destination NAT business application rule, it ignored user-network rules and matched the traffic with business application rules. 
 From v18, Sophos Firewall has removed the distinction between business application and user-network rules. It now offers both as firewall rules. To ensure that the consolidation does not affect the rule-matching behavior of earlier versions, it will continue to ignore migrated user-network rules positioned above migrated business application rules for system-destined traffic and incoming traffic. 
 This is a read-only checkbox in the firewall rule that tells system to retain rule matching behavior of v17.x even after migrating onto v18. 
 
 5) I am creating a firewall rule for DNAT (destination translation) rule. Why should I configure Dst Zone match in firewall rule as (mostly) local zone (LAN/ DMZ). And, why should I configure Dst network match in firewall rule as original Dst IP (WAN IP on Sophos Firewall)? 
 When you create firewall rule for NAT rule in which destination is translated, you would match Dst zone as the ultimate zone in which the traffic would terminate (that is local zone &ndash; DMZ or LAN). However, you would (want to) match against the original destination IP (WAN IP on Sophos Firewall), here&rsquo;s why: 
 
 Usually one public IP would translate to different internal server IPs based on services. Admins can have one firewall access rule matching public IP; And NAT can take care of translating to different servers. 
 Also, when admins add new servers in network, they need not to again modify firewall rule. With how this is implemented now &ndash; we can just edit NAT rule and we are good to go. This is true decoupled NAT/ Enterprise NAT power. 
 Existing behavior makes it easier to configure in 1-to-Many DNAT scenario in which 1 public IP is translated against multiple local IPs. Match on the public IP adds flexibility. 
 v18 implements more standard and industry common NAT design. With v18, Sophos Firewall&rsquo;s enterprise NAT capability and configuration flow is now at par with other competitive players.

6) What is LinkedNAT? 
 With v18, Sophos firewall has moved towards more standardized NAT design in which network translation configuration is now decoupled from firewalling configuration for better manageability in the larger sized deployments. 
 However, For customers who don't want to manage a separate NAT rule table, Sophos firewall v18 offers a differentiating LinkedNAT feature to grandfather existing customers over to the new design in the long run. The linkedNAT feature is fundamentally designed to provide inline source NAT rule creation from firewall rule. Matching criteria for the LinkedNAT rule is linked with the respective firewall rule, admin only needs to configure or edit the Src translation decision in the LinkedNAT rule. 
 This means LinkedNAT rule will only be applied to the traffic matching that specific firewall rule. However, if standard NAT rules are placed before the linkedNAT rule that match the traffic, the matching NAT rule would apply. That means, LinkedNAT does NOT guarantee that it will be matched for respective firewall rule traffic (if admin creates standard NAT rule before LinkedNAT). NAT rule table will always be matched from top to bottom priority order. There is no special or reserved priority in execution for LinkedNAT rule. 
 LinkedNAT rule is only possible for SNAT (source translation) configuration, not for Destination translation (DNAT). 
 
 7) Is it mandatory to use LinkedNAT? Where should I use LinkedNAT? 
 It is not mandatory to use LinkedNAT. With v18, Sophos firewall has moved towards more standardized NAT design in which network translation configuration is now decoupled from firewalling configuration for better manageability. 
 If you have a small scale deployment (small set of firewall rules) and you don't want to manage a separate NAT rule table, you can create LinkedNAT directly from the firewall rule and ONLY configure Src translation decision while matching criteria are automatically linked with the respective firewall rule. 
 If you have to differentiate SNAT configuration based on Users or Schedules criteria, LinkedNAT rule becomes mandatory there. However, such configuration need is very rare, we have NOT observed such configuration in practical deployments. Also, LinkedNAT rule is only possible for SNAT (source translation) configuration, not for Destination translation (DNAT). 
 
 8) What is the new disabled &ldquo;Drop ALL&rdquo; rule at the bottom of the firewall rule table? 
 The default drop rule provides visual indication to user / admin that if none of the firewall rule gets match, traffic will be dropped. 
 You reported about two specific challenges that admin faces in v17.x. 
 
 New admins are confused about the default behavior on firewall rule table &ndash; that is the behavior when no rule matches. The new disabled Drop ALL non-editable rule is a step to resolve this. 
 Logviewer should show traffic being dropped by the default-drop behavior of firewall rule table &ndash; this is planned to be released post v18. 
 
 Currently, the logs that you see with firewall rule id &lsquo;0&rsquo; are NOT for the traffic dropped by Drop ALL rule. In later EAP releases, we would replace them with &ldquo;N/A&rdquo; as those are for the traffic dropped before the firewall rule matches &ndash; for example &ndash; invalid traffic. And actual logs for traffic dropped by Drop ALL default behavior will be available in the release post v18. Meanwhile &ndash; as a workaround, one can add a drop rule at the bottom to log the dropped traffic not matched by any other firewall rule. 
 
 9) Do I have any demo/ training on how to configure various NAT in the new design? 
 To help you evaluate Sophos firewall v18 better in this early access program, here is the interactive training/ work through course - video along with the PDF handout and speaker notes. Here is the interactive course to work through Sophos Firewall v18.0: 
 https://community.sophos.com/products/xg-firewall/sfos-eap/sfos-v18-early-access-program/f/recommended-reads/115874/interactive-training-course-on-xg-firewall-v18-0 
 
 Sincerely, 
 Your Sophos Sophos Firewall Product Team

lferrara · Answer

Let me try to put some experience I had during these days. The goal was migrating 27 DNAT rules from another Firewall to XG v18. Since it is a DR site and no disasters were "planned" for the testing time, I dediced to share with 5 guys the project of migrating the DNAT configuration from the current product to XG v18. I did not tell them how to create the DNAT. Since Sophos is "security made simple" I told them: lets migrate the rules you have on XXX to v18 but without using online help, documentation, only with your experience and Sophos XG v18 interface. 
 
 All the DNAT were documented on an Excel files (source zone, listener interface/ips, destination zone, destination internal server). 
 XG installed by using 3 NICs: internal, wan1 and wan2. All IPs used were different from the current XXX ip addresses scheme 
 Creation of internal server. Since here no issue for the 5 guys. They have 3 years of experience on XXX and Cisco CCNA certified 
 Creation firewall rule. None of the 27 firewall rules were correct. None. 
 NAT? How does the NAT works here on XG v18? 
 What is linked NAT? 
 How can NAT source service to multipe WAN IPs? 
 
 Then, I decided to show them v17 interface from a customer site. Apart some questions regarding NAT, the Wizard helped them to understand how to create the rule and they did it correctly on v17 environment (it was a test on a production installation, so the rule was disabled and deleted afterwards) 
 Back to v18, they tried again: still wrong. Then I showed them the Sophos v18 training course.pdf and they said "no way, really?" At the end, in the firewall rul: 
 
 Destination zone: they putted LAN 
 Destination network: here the problem comes. Here they putted the list of servers or the single server where the internal service run 
 Service: some of them putted the internal service and some the external service (in the cases where the external service port was different from the internal) 
 
 On the NAT, what the guys have done: 
 
 Source: Any 
 Original destination: confused. Some putte WAN port, some the WAN ip addresses, some the internal server ip 
 Original service: all agreed with the external service 
 Translated source: and now what we put here? Confused! Maybe here WAN Ip address goes here 
 Translated destination: all agreed with the internal server ip 
 Translated service: all agreed with interna service 
 Inbound interface: WAN and WAN1 (where required) 
 Outbound Interface: LAN 
 
 This is the test I conducted with the help of 5 guys. Thanks to them. So my considerations are: 
 Firewall section: 
 
 Consider to bring back Wizard as used in v17. In your pdf and training course, PMParth , WAF is not even documented. Now WAF is an action like allow, deny, block. Since the history of first firewalls, actions are considered 3 and not more. 
 Wizard option was really appreciated from Sophos Community and Sophos Partners. Thanks to Community, I have contact with some Sophos Gold Partner and they do not like the absence of Wizard. They are scared to reply as the reply will be deleted or their answer will have some reflection on their business. 
 Wizard was a nice idea since the ISA Server age. I used and appreciated a lot Wizard on Microsoft and then on XG. Well done for the Wizard, nice feature. 
 Creating DNAT is a pain now. The problem are the destination network and nomenclatures. You need to put the pre-nat section in one line and post-nat section in another line. My suggestion for source are:
 
 Source zone 
 Source network 
 Source service 
 Listener: here you put the ports or the WAN ip addresses.

For destination and services: 
 
 Destination zone: LAN or DMZ or whatever 
 and destination service: here the pre-nat service

For NAT tab:
 
 Put in one line: Original Source, listeners or pre-nat ip, original service 
 Put in a second line: Translated source, destination ip, translated service

Names you used are just confusing. Listeners are much better that what you use at the moment. Decoupling NAT and Firewall rules is a nice feature and idea, but better names and wizard can reduce confusion and ticketing to Sophos. 
 Other improvements: 
 
 Remove the linked NAT. One the user has putted source, destination, services and so foth, before the Web protection section, a NAT button that says something like:
 
 This rule matches the NAT rule id. If you leave the mouse on it, the button gives you details of the NAT rules in the next tab. From here, users can be allowed to edit the NAT and a message should say, if you edit this NAT, other firewall rules are impacted or these firewall rules are impacted. Do you want to continue. 
 NAT icon for DNAT. Once all source and destination filtered are filled, the NAT icon will tell you how the firewall rule will be translated too.

Bring back the Firewall icons. Use different icons for WAF, DNAT, Firewall rules and Users firewall rules. 
 If the firewall rule has no linked NAT, the NAT icon is greyed out, so it seems no NAT is matching. This should occur only if no NAT rules are matching the firewall rule. Like in this case:

The firewall rule works as the last nat catches the traffic. NAT icon should be coloured. 
 I will take a sceenshot of my reply. Just in case the reply is deleted.