SFOS v18.0.379 - Hairpin Nat / Loopback rule can't get to work

Hi des villar 

I would advise you to select Create loopback rule when you create a DNAT rule. This option is only available when you add a new DNAT rule, please try to create a new DNAT rule and select Create loopback rule and let us know how it turns out for you.

Thanks,

i've already tried it, i also studied what the settings of the loopback and tried to recreate it, tried putting to different sequences (hnat top, dnat mid, snat lowest)

i've also tried making firewall rules from LAN to ANY.

Hi,

we´ve the same problem with multiple Sophos XG boxes. All running either 18.0.379 or 18.0.339

It´s just not working. I took one test-box and started with an empty ruleset for the sole reason to get DNAT with loopback running.

Tried multiples ways:

- "Server access assisstant (DNAT)" from NAT tab.

- created rules manually

- created firewall rule and linked nat rules

No success. Externally everything is fine. Internally no connection. Connecting to the internal ip directly works, but is not what my customer is asking for. We need to connect to the external ip. Split DNS is the last resort to fix that. But hairpin NAT should be working.

When I create a firewall rule at the bottom to allow everything it works. Logged that traffic and tried to create a rule with the contents from what I found in the logs. But this doesn´t fix it. It only works with an "allow all" rule, which isn´t useful in production.

Contents of logs:

I can see traffic from lan-interface (port1) to lan-interface (port1) with source ip within the range of the lan-interface and destination ip of port2 (wan). I created a rule to allow everything from port1 and to port1. Nothing.

I think there is a bug in v18.

Please fix it!

Hi,

we´ve the same problem with multiple Sophos XG boxes. All running either 18.0.379 or 18.0.339

It´s just not working. I took one test-box and started with an empty ruleset for the sole reason to get DNAT with loopback running.

Tried multiples ways:

- "Server access assisstant (DNAT)" from NAT tab.

- created rules manually

- created firewall rule and linked nat rules

No success. Externally everything is fine. Internally no connection. Connecting to the internal ip directly works, but is not what my customer is asking for. We need to connect to the external ip. Split DNS is the last resort to fix that. But hairpin NAT should be working.

When I create a firewall rule at the bottom to allow everything it works. Logged that traffic and tried to create a rule with the contents from what I found in the logs. But this doesn´t fix it. It only works with an "allow all" rule, which isn´t useful in production.

Contents of logs:

I can see traffic from lan-interface (port1) to lan-interface (port1) with source ip within the range of the lan-interface and destination ip of port2 (wan). I created a rule to allow everything from port1 and to port1. Nothing.

I think there is a bug in v18.

Please fix it!

Hi Christopher Linn 

I am sharing 2 articles, which may help you to understand the NAT functionality in SFOS v18.

https://community.sophos.com/products/xg-firewall/f/recommended-reads/116102/understanding-new-decoupled-nat-and-firewall-changes-in-v18

https://community.sophos.com/products/xg-firewall/f/recommended-reads/118888/sophos-xg-firewall-v18-how-to-choose-the-gateway-for-a-firewall-rule

Hope this helps!

Hi Keyur,

thanks, I already found those articles and I don´t see how they help with this bug.

DNAT assisstant is not creating the result one would expect. Please take a XG box start with a fresh ruleset, have a i.e. webserver in the LAN and configure a DNAT rule. With v18 it won´t work to connect to this server from a lan-address to the wan-ip.

I even played around with choosing static round above sd-wan policy-routing. No change.

Best regards,
Christopher

Hi Christopher Linn 

I understand your concern but there is no bug found for the DNAT functionality, Could you please try with this article - https://docs.sophos.com/nsg/sophos-firewall/18.0/releasenotes/en-us/nsg/sfos/releasenotes/rn_DNATServerAccessAssistant.html?

Hi Keyur,

of course I did this like explained. On multiple boxes. All with the same result: externally reachable, internally not.

I even created a test setup. It only works with an "allow all" firewall rule on the bottom added after running the assistant.

Best regards

Hi Christopher Linn 

Please allow me some time to check and I will update this thread further.

if you only have 1 public ip which is the current ip address used by the WAN that is working using the assistant, but if you have a subnet of public ip and the DNATted public ip is not the ip of of your wan interface then this is our current problem..

i've read everything that concerns hairpin nat and i know how to use it since i have this working on version 17.5 sfos.. i also have other fortigates that can do this, only in version 18.0+ i have encountered this, and i've already triend every single bit of combination of firewall rules, nat rules and routing rules.. but no avail..

i manage to have 3 hops to get but

1 hop is the local gateway

2 hops are the public ip

then everything stops here by the reply of network

Hi des villar 

I would recommend you to open a support request to investigate the issue further.

Hi Keyur,

just a short update. Did a factory reset on my test-box, deleted all default rules and started from scratch. On my test-box it´s working now. It must have something to do with rules existing before migration from older version. All my production boxes have those issues.
But at least I know it works.

Best regards,
Christopher

i've also tried deleting all the rules on my box, but not factory reset, but if this is only the solution well that sucks for me having 400 server and tons of vpn tunnel.. i'll just downgrade to the latest version 17.5 for now

Hello All, 

Thank you for reporting this issue to our attention. We have identified an issue as a BUG ID NC-59809.

We have targeted the fix in V18Mr3. 

Workaround: Open the loopback rule and click on  Save to make it working again.