Sophos Flow: Firewall and NAT

Hello IT Hero,

Thank you for reaching out to the community, have you referred the following two Docs related to the DNAT, they might help:

1.) Create DNAT and firewall rules for internal servers: https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/RulesAndPolicies/NATRules/RulesPoliciesCreateDNATAndFirewallRulesForInternalServers/index.html

2.) Add a DNAT rule with server access assistant: https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/RulesAndPolicies/NATRules/NATDNATServerAccessAssistant/index.html

Essentially you have to understand: There are three different actions of traffic: Routing, Firewalling(Allow/Deny) and NATing (changing the traffic). 

See: https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/122357/life-of-a-packet-sophos-firewall

One of the confusions starts, when NAT kicks in, changing the Destination but not the Zone. 

I have a rule of thumb for this, which worked great for me: Change the Destination Zone, not the Destination IP in the Firewall rule.

Means: FW Rule IP #Port1 and Zone LAN. This will work. 

If your firewall is not hitting, it is not matching. Simple as that. So NAT will hit without firewall has to hit. See above. It works independly. So the NAT will do its stuff, and if the firewall denies the traffic (not matching-Default drop) or another rule hits, your rule will not match.

Check the packet capture on the Webadmin of your firewall to see NAT and FW rule for the traffic. Use the configure - BPF String to dump specifically for your traffic. 

I am very familiar with route, firewall and translation. The problem is that I find DNAT configuration not aligning with how the rest of scenarios are configured in the fw rules. When we do MASQ or SNAT, our destination zone and IP are in the same "realm" (i.e. WAN Zone, WAN IP). Same thing with Inter-LAN rules (Destination Zone DMZ, IP will also be in the DMZ). It's only the DNAT that has Zone = Internal and IP = External.

If the firewall rule is processed before NAT, then there is no way the packet can match the LAN zone without being translated first.

I am sure Sophos has an implementation that makes it all work, perhaps some sort of NAT "simulation" right before the FW rule that doesn't actually translate the DstIP, but only "checks" in which zone the packet would land after translation, so that the firewall can process it as Dst.Zone=LAN. The question is  - why it's not doing the same thing with the IP address and the service?

It just doesn't make sense to me that "we indicate LAN zone becasue that's what is going to happen after translation, but we indicate WAN IP and pre-NAT service right in the same rule, because that's what will happen before translation.

Also this - 

The link you provided confirms once again that the ingress order of processing of a packet is DoS > FW Rules > DNAT > Route. If the firewall rule isn't hitting and the packet is discarded, then how come I am seeing NAT counters go up? I have no other inbound rules allowing WAN>LAN. The packet is discarded 100%

You are right with "it is so counter intuitive" for creating DNAT rules.

Because of this, i use the DNAT- wizzard every time and has 0 problems (but i delete the 1-2 additional unnecessary NAT rules)

So let me put some things into context. NAT is not aware of Zones. So you are actually not changing the Zone in any terms with NAT. 

Firewall will hit multiple times in fact in this terms. So the life of a packet is actually some sort of "wrong" as it has multiple steps within this step "Firewall rule processing". There is a lot going on in this step. It is not wrong in terms of processing, instead it is not completely lay out, what this firewall rule processing is doing. So the "lookup of zones" is actually aware of NAT. So it actually checks for the NAT rule table. But it does not change anything (as NAT is not done here). 

The DNAT Implementation will actually do something with the traffic. 

Think about life of a packet as: This is what is the firewall is doing with a packet. So Changing the Zone is nothing, the packet is aware of. The packet does not know, which zone it belongs. It only knows the meta data (destination Ip, source ip, payload etc.). Zone is not something, the header is aware of. So the firewall processing unit is already changing the zone. Because otherwise we cannot do it anymore. DNAT cannot change the Zone, as DNAT implementation is not aware of zones. 

BTW: Even if firewall is dropping the traffic, the other decisions will still be handled. So to speak, if firewall denies, the firewall still goes trough the other ingress steps. After the Routing decision is met, the firewall will drop the traffic. So the firewall module is not dropping the traffic, it flags the traffic to be dropped. 

I understand that Zones are not a part of OSI stack. It's an extension of Sophos implementation. I also understand that NAT isn't Zone aware. However. The firewall rule is zone aware because it contains the Zone criteria that has to match. Meaning that there is a pre-NAT, pre--FW process that adds the Zone data to the packet before it's matched against the firewall. Most likely the Zone is determined based on the pre-NAT, pre-FW "lookup" you mentioned above.

My point is that when you know what is going on under the hood (i.e. lookups, zone tagging, etc) it is easy to make sense why the UI configuration is the way it is (i.e. Dst zone is internal, but the Dst IP is external).

Not knowing that makes it all look inconsistent with configuration of the firewall rules for other scenarios (MASQ, SNAT, Inter-LAN/VLAN).

NAT before FW would have resolved this inconsistency, but I guess there is a serious reason why Sophos decided to place NAT after FW.

Lastly, I didn't know that all other ingress steps will take place even if the firewall dropped the packet? Doesn't that seem like a waste of resources?

Changing the processing flow to drop the packet before those decision are made is actually worse. 

And one important part: The change was implemented in V18. V17.5 and earlier had NAT within a firewall rule. So no confusion there. So Sophos implemented a NAT by not changing the inner works of the platform, instead changing the implementation of the configuration part. This means, the inner works is still "the same" but the NAT rules are decoupled. 

You can even see this: By looking at a drop packet capture on the CLI, you see all criteria are already there (PBR, NAT zones etc.). 

Most people, like above mentioned, are using the Wizard for a quick implementation. People aware of the way the firewall works, will use there own firewall rules. In the end, as long as there is a simple way to implement a DNAT, it is fine for me.

DNAT wizard is good when you don't need port translation, only forwarding. During the wizard you're only prompted for the post-NAT listening port. Then it uses the same port number for original service. I killed WebAdmin access to the firewall this way years ago :))

Thanks for the replies. I hope it will be more intuitive and easier to remember the "zone - internal ; IP:service - external" after this conversation.