Understanding New decoupled NAT and firewall changes in v18

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 XG firewall v18? What is Decoupled NAT? Why we changed?

with v18, XG 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 XG 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, XG Firewall’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, XG 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 – many of them could be with similar source NAT translation, for example – 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 – many of them could be with similar source NAT translation, for example – 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, XG Firewall evaluated these rule types independently to find matching criteria. For system-destined traffic (example: accessing XG 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, XG 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 XG)?

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 – DMZ or LAN). However, you would (want to) match against the original destination IP (WAN IP on XG), here’s why:

  1. 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.
  2. Also, when admins add new servers in network, they need not to again modify firewall rule. With how this is implemented now – we can just edit NAT rule and we are good to go. This is true decoupled NAT/ Enterprise NAT power.
  3. 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.
  4. v18 implements more standard and industry common NAT design. With v18, XG Firewall’s enterprise NAT capability and configuration flow is now at par with other competitive players.

 

6) What is LinkedNAT?

With v18, XG 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, XG 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, XG 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 “Drop ALL” 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.

  1. New admins are confused about the default behavior on firewall rule table – that is the behavior when no rule matches. The new disabled Drop ALL non-editable rule is a step to resolve this.
  2. Logviewer should show traffic being dropped by the default-drop behavior of firewall rule table – this is planned to be released post v18.

Currently, the logs that you see with firewall rule id ‘0’ are NOT for the traffic dropped by Drop ALL rule. In later EAP releases, we would replace them with “N/A” as those are for the traffic dropped before the firewall rule matches – for example – invalid traffic. And actual logs for traffic dropped by Drop ALL default behavior will be available in the release post v18. Meanwhile – 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 XG 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 XG 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 XG Firewall Product Team



Added Tags
[edited by: Erick Jan at 4:34 AM (GMT -7) on 28 Sep 2022]
Parents
  • dear all 

     

    i have working with xg form the first day the lunch it and before that i was working with cyberoam 

    also i have experience with cisco and fortigate product but i relay got confused form how to handle with the New NAT method and how they created 

    for example i upgrade form v17.5 to 18 so i found the linked NAT rule but when  i try to create new rule i can not use the old nat one and i have to create it again ??? why i can not use the linked one 

    i know that you try to be more similar to the other vendor in the market 

     

  • Hello MarcKamel,

    welcome to hel*!

    Regards

    alda

    [:@]

  • Hi,

    migrated my v17.5 XG to V18 EAp. Initially the NAT rules look good until you try to use them.

    1/. too much unused screen sopace

    2/. each NAT rule has a number of IDs from what I can see

    3/. the NAT rules bear no relationship to the firewall rules

    4/. the migration tool could have at the very minimum used the firewall rules name in the identity as it stands there is no meaningful way of identifying which NAT rule applies yo which firewall rule (yes, there is a number but can you remember what each firewall rule does?).

    5/. there does not appear to be a way to swap between firewall rule and NAT rule pages, so you will need two monitors and two firewall sessions open to create firewall rules and manage the firewall.

    The above is a from my quick exploration after initial installation.

    Ian

    XG115W - v19.5 GA - Home

    Test machine - Asus P10S-i E3-1225v5, 6gb, 4 intel NICs, v19.5 GA

    If a post solves your question please use the 'Verify Answer' button.

  • Hello rfcat_vk

    1/. Ok for the screen space lost.  But that may due to a programming package Sophos is using, like Infragistics on Windows platform.  In such cases, layout are done via librairies, and the programing language just calls it. Sophos programing is somewhat locked.  The alternative is to program windows manually.  A heck of a job.

    2/. to 5/. I really don't get it.  Why on earth one want to have side by side NAT rules and Firewall rules.  Sounds absolutely useless to me.  NAT are not that much related to firewall rules.  They are related to conditions and/or networking.  For example, default NAT rule for all Firewall on this planet is "all hidden behind the firewall".  Or call it "Masked behind the firewall". Since most small business now are granted a unique firewall IP address, chances are that "a little more complicated NAT" will be:

    1- default NAT: all hidden behind firewall.  Why would you link that one ???  It simply applies to all firewall rules by default.

    2- conditional NAT: External HTTPS NATed to a specific internal WEB or MAIL server IP.  Obviously, you could also do a linked NAT here. But it is gonna be one of the very, very few you will have to implement.

    And it is not gonna be more complicated than that for a lot of users.

    Besides the non-intuitive screen layout, what's the fuzz about v18 NAT implementation ?  

    So.  We need a better layout, AND templates (WEB Servers, EXCHANGE servers, et.c.) We also need an automatic NAT rule generator like all other firewall products on the planet.

    But I also wish no one touches to the welcome flexibility we just gained !!!

    My 2 cents ...

    Paul Jr

  • Sophos should invest some partners during the design phase as changing things in the design phase can require very small effort. Car houses use prototypes before starting to manifacturing cars.

    As I said, I am open to partecipate (with some notices of course) when they are thinking of re-designing something new. They did not invest Parterns that I know here on community. No one is happy with the new NAT and the wizard removal.

    I like the concept of decoupling NAT and Firewall as UTM9 but not Linked NAT. Wizard is very very helpful and falls into "Security made simple".

    Anyway, I already expressed my idea and the test I performed is clear. If someone from Sophos would like to contact me, feel free to do it. I am always available.

    Regards

  • Yeap.  Those who have 300 firewalls rules and more, will find themself with 300 rules NAT after upgrade, and 290 of those 300 NAT rules will be exactly the same as the logical default MASK / Hidden all rule.  So they will have to create / edit a default NAT rule, and then delete manually 290 NAT rules.

    I can hardly find something more unproductive.

    That's a job for a script I can only tell.

    Paul Jr

     

    N.B. Oups.  I forgot.  Multiply this by two if you have IPv6 as well.  A job for a munk.

Reply
  • Yeap.  Those who have 300 firewalls rules and more, will find themself with 300 rules NAT after upgrade, and 290 of those 300 NAT rules will be exactly the same as the logical default MASK / Hidden all rule.  So they will have to create / edit a default NAT rule, and then delete manually 290 NAT rules.

    I can hardly find something more unproductive.

    That's a job for a script I can only tell.

    Paul Jr

     

    N.B. Oups.  I forgot.  Multiply this by two if you have IPv6 as well.  A job for a munk.

Children
  • The question is why has some much resources been wasted (my opinion) on bringing XG upto parity with opposition devices for a dying requirement eg IPv6 does not need NAT, when the resources would have been better employed bring XG v18 IPv6 upto UTM parity at the very minimum. You still cannot use country blocking in IPv6 firewall rules. You still need seperate firewall rules for IP4 and IPv6.

    Ian

    XG115W - v19.5 GA - Home

    Test machine - Asus P10S-i E3-1225v5, 6gb, 4 intel NICs, v19.5 GA

    If a post solves your question please use the 'Verify Answer' button.

  • ...  bringing XG upto parity with opposition devices for a dying requirement eg IPv6 does not need NAT ...

     

    Hello

    You must have spotted the "IPv6" button under "NAT rules" tab in the "Rules and Policies" menu ?

    Paul Jr

     

     

  • In addition to the long list,

    to add a new item, I do not like the drop-down menu as implemented for translated as the it is not user-friendly. A possigle implementation of NAT rule could be like this:

    Simple and easy to understand. Maybe to adjust the titlle but the main idea I have is this. What do you think?

    Thanks

  • I would put them vertically instead of horizontally, because, for some reasons, the width available on XG WEB pages is very limited.  As of now, they could not put 4 colones ...

    Paul Jr

  • Hello Luk and Big_Buck too,

    I think Luk's design is more sophisticated and substantially more logical than the current Sophos implementation. However, Big_Buck is also right, as the current XG GUI layout supports only 3 columns.

    I suggest the last column on the right with the interfaces move to the left column down under Original source and Translated source. This would solve the problem with only 3 colums.

    What do you think?

    Regards

    alda

    P.S. What a paradox, "amateurs" advise "professionals" how to design a firewall!

  • Hi,

    It's interesting to hear the varied opinions on this topic.  As it would appear, everyone has a different view of their preferred UI layout.  Putting aside the debate on drop-down options, let me help explain why we have chosen the implementation of left to right in the configuration for NAT. 

    In most languages, at least in English, the default reading style is left-right followed by top-down.   In the case of NAT, the original src, dest, and service are treated as a collective match. In other words, they all have to match for a policy to take effect.  So the items on the left all must match before something on the right is applied.  Based on other NAT configurations with different UI structures, we saw that it required more time to scan the page to understand how the policy was constructed and applied.  With an understanding of how the NAT policy works, aligning the configuration in this way reduced scan time and made it easier to understand the policy based on our user testing.    

    Attached is a picture to illustrate this concept in case it is not clear to those who have not worked with other more flexible NAT systems.  

  • We don't do that in the firewall rules.  We are reading left to right for source, then move down, left to right for destination, etc.

    I think you have a good opportunity to fix these small UI issues that in the long run will make a much larger impact.

  • Rob Andrews said:
    Hi,

    It's interesting to hear the varied opinions on this topic.  As it would appear, everyone has a different view of their preferred UI layout.  Putting aside the debate on drop-down options, let me help explain why we have chosen the implementation of left to right in the configuration for NAT

    Rob read the multiple answers with more attention!

    Our 3 agree to have source on top and destination on bottom. Other people are just saying that the fourth column would not fit.

    Also this design is used inside Firewall rule already.

    In addition drop-down lost is not user-friendly at all.

    Your picture comes from the training and for me and other people I showed the UI is not clear at all.

    Just received a confirmation today from a customer moving to cxxxxxxxxt as XG is too complicated to troubleshoot.

    530 users client moving to cxxxxxxxxt.

  • Helo Rob,

    Your great community system does not allow you to upload pictures! Otherwise I would only answer by two pictures to understand what we all don't like about your NAT rules design ...

    Regards

    alda

  • Hi,


    My intent is not to dismiss the feedback but to explain the current approach.  It sounds that based on the feedback we have in this thread, moving the position of the boxes and not using a drop down (source top, followed by left right) (translated bottom, followed by left right) would solve a good portion of the UI angst in this thread.