[26.1] NAT reflection not working

[maarten90]

Hi everyone,

i'm on 26.1.8 currently and I migrated my rules to the new rules feature. However it seems that NAT reflection has stopped working since then. Port forwarded services can be accessed from the internet just fine, but not from the local network. The three boxes on the "Firewall > Advanced" are ticked. But even after re-applying the configuration by clicking the apply button, it won't work. Any tips on where I should look to make this work again? Thanks!

[nero355]

If possible you should avoid Reverse NAT a.k.a. NAT Loopback anyway, so maybe a good moment to consider moving away from it ?!

[maarten90]

You're right. Time to implement split DNS I guess. Thanks for motivating me to finally do it :D

[Patrick M. Hausen]

Or use a proxy instead of destination NAT. E.g. Caddy listening on the WAN interface can be used from internal networks just like from the Internet with just the public IP address in DNS.

[Kinerg]

If possible you should avoid Reverse NAT a.k.a. NAT Loopback anyway, so maybe a good moment to consider moving away from it ?!

Why? Genuine question.

[nero355]

If possible you should avoid Reverse NAT a.k.a. NAT Loopback anyway, so maybe a good moment to consider moving away from it ?!

Why? Genuine question.

To be honest I can't remember the whole theory behind it anymore (It's been like 20 years or so... LOL!) but in the past it has always been considered as a possible security issue and something that shouldn't have ever existed in the first place and thus deprecated technology basically :)

[keeka]

If possible you should avoid Reverse NAT a.k.a. NAT Loopback anyway, so maybe a good moment to consider moving away from it ?!

Why? Genuine question.

It's considered a sub-optimal workaround, less secure. I decided to pass on NAT reflection options, for both pfsense and OPNsense, probably some point after reading documentaion, beginning with https://docs.netgate.com/pfsense/en/latest/nat/reflection.html. I then thought split DNS might be affected by TTL, so avoided that solution. Eventuallly addressing it only when needed, with my own NAT rules. AIUI it's only considered NAT reflection if the redirected traffic 'hairpins' via the WAN.