ELI5: How do I do a "Business Rule" in v18 (firewall rule + NAT rule)

You would basically use NAT. 

NAT will take the decision "Should XG change the traffic?".

Then you need a firewall rule, which allows this traffic. 

There are two different approaches.

Ether use the Destination or Interface Way.

I would recommend Destination. 

So put in "Original Destination" your WAN Interface.

In "Translated Destination" you would select the "Going to" Destination. So to speak your Server. 

You could select Service now: Original Service would be RDP. 

In Case you want to change the Source or Service, select it by the drop down menu. 

You can now select Interface matching criteria, if you want. But this is not needed. 

Additionally, you need a Firewall, which allows this connection. 

WAN to LAN Port RDP should be enough. Be more specific if you want. 

As always, please put a Feedback loop, if you notice a lack of documentation! 

Ok, so I played in my test environment and got the following results.

NAT Policy:

Original Destination: 192.168.12.90 (the "wan" interface on the lab)
Translated Destination: 172.16.16.17 (the Windows 7 VM for testing purposes)

Firewall Rule Results:

First try:
Source: Any Zone, Any Host. Destination: Any Zone, Any Host. Service: 3389 TCP. Results: Works.

Second try:
Source: Wan Zone, Any Host. Destination: Any Zone, Host. 172.16.16.17 Service: 3389 TCP. Results: Fails.

Third try:
Source: Wan Zone, Any Host. Destination: Lan Zone, Any Host. Service: 3389 TCP. Results: Works.

Last try:
Source: Wan Zone, Any Host. Destination: Lan Zone, Host 172.16.16.17. Service: 3389 TCP. Results: Fails.

Any time I put an IP address in the Destination Host, it fails. The thing is that in packet capture, it shows the IP address of the host and its the same

When destination host in firewall rule is the IP Host (same NAT policy):

When destination host in firewall rule is any (same NAT policy):

So unsure why it doesnt take effect the IP host.

-----------------------------------------------------------

Edit:

Did one more try, with the following config:

Source: Wan Zone, Any Host. Destination: Lan Zone, Host 192.168.12.90. Service: 3389 TCP. Results: Works.

This kinda  confuses me: The 192.168.12.90 is the WAN and not LAN (I know the NAT translate it, but visually is confusing). 

It matches prior to NAting? In that case, it makes sense that it works with 192.168.12.90, but why LAN zone?
Or it semi-matches prior to NATing but then, the destination zone (and not host) matches after NATing?

I mean, it will be confusing for clients trying to understand the flow of the NATs.

Thanks!

Hi,

When you create firewall rule for NAT rule in which destination is translated, you would need to match Dst zone as the ultimate zone in which the traffic would terminate (that is mostly the 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. Industry implements DNAT in similar way. With v18, XG Firewall’s enterprise NAT capability is now at par with other competitive players.

 As we are moving to the new design, some confusion is bound to happen for existing users. We will soon support our veterans with detailed FAQs on community. Improvements in on-screen assistive text and online help is already in progress, along with the how-to-videos.

Thank you very much for evaluating v18 early access. Appreciate your support.

PMParth said:

4. Industry implements DNAT in similar way. With v18, XG Firewall’s enterprise NAT capability is now at par with other competitive players.

 As we are moving to the new design, some confusion is bound to happen for existing users. We will soon support our veterans with detailed FAQs on community. Improvements in on-screen assistive text and online help is already in progress, along with the how-to-videos.

Thank you very much for evaluating v18 early access. Appreciate your support.

Are you sure about that? This will bring a lot of confusion, dissatisfaction and a lot of Sophos customers call.

Match on the public IP adds flexibility? More confusion, also, in this way NAT tab is becoming more important than Firewall tab. If you are troubleshooting or audit what is opening from external, you know that from internet, https or whatever is opened toward the XG WAN ip address.

I cannot believe this! You are reiventing the wheel. NAT was much easier with v17. If you want to really copy, copy from other industry or even better for what you have in house (Astaro).

Hello PMParth,

OK, I get it now. The developers' lack of ability to implement properly standard security functions, which are used in the "original form" for quite a long time and EVERY firstly understand at first glance what the principle is, they now pretend to be a completely logical and innovative approach?
Hmm, very good acting performance. So I am really curious how this new approach will appreciate the market and especially the administrators. I heard something very similar in 2015 when you released v15. I also heard from Sophos that it was a completely innovative approach, and for more than three years you patched and repaired the disaster and is it back?

You NEVER learn!

Regards

alda

From beta v18 training course