NAT reflection woes...

[meyergru]

Well, yesterday, I had some bad experience using NAT reflection on port forwards...

I was trying to setup HAProxy when I noticed that my backend server could not be reached. This was strange, since I had disabled the port forward that I had for ports 80 and 443 to my main server.

After much trial and error, I narrowed this down to that my Opnsense could not reach the main server on ANY port, but could ping it. I gave the main server an additional IP and that worked. I was not aware of any firewall rule that could cause this, but after I disabled all packet filtering, I could access the ports again from my Opnsense.

Since I could not lay my fingers on anything specific by enabling all firewall logging, I suspected a NAT issue, because I still had some inbound WAN rules for my main server for other ports than 80 and 443. After I disabled them, all was fine.

I narrowed the problem down to one port forwarding rule which had a "mail" port alias with ports 143 and 587 in it and for which NAT reflection was enabled. The alias was used in both the port range and redirect target port. NAT reflection was enabled.

This rule had the side effect of blocking all ports on the destination server from the Opnsense itself. When I changed that to two separate rules for the ports, only the ports in the rules were affected.


So there are two problems with NAT reflection:

1. When you use a port forwarding rule with a port alias containing two ports and enabled NAT reflection, Opnsense cannot access any port on the target IP. There is surely a bug in how port aliases are handled there as all ports are affected and not only the ones in the alias.

2. Even when you do without port aliases and NAT reflection on a port forwarding rule to an IP X on only a single redirect target port Y, that specific combination of X:Y will not be reachable for your Opnsense box itself any more. While it is somehow intended to have NAT reflection for any incoming LAN traffic, it should never lead to the target port being masked from the Opnsense itself. To say the least, this is most unexpected and very difficult to find once you stumble on it, as there is no logging for NAT reflection.

These problems are only visible from the Opnsense box itself, as any other LAN clients usually reach the target X directly without Opnsense interfering, i.e. NAT reflection comes only into play when you access the external IP for X (and also, the port could be != Y).

[axsdenied]

There have been numerous posts regarding aliases behaving differently in the latest builds.  I believe it's being investigated.

For now are you able to manually port forward each port rather then using aliases? Does that still work?

[meyergru]

Yes, it works with separate rules, as I wrote:

"When I changed that to two separate rules for the ports, only the ports in the rules were affected."


I reported the specific problem in the "aliases" thread - however, the 2nd problem with NAT reflection is unrelated to aliases: there seems to be no exception for the firewall itself on the reflection rule, so that it cannot reach the target on the original port (or more probably, get the answers back).

[despised]

I had the same problem.  Port forwarding rules were failing when I implemented them myself (anti-lockout rules).

This is what I changed to make them work (it's the firewall rules, not the port forward).

Create port forwarding rule (no redirect).  (no tricks)

Create firewall rule, however add the following ->
1. Make the rule as you would.
2. Check allow options
3. Checkmark `SYN` in the `set` column
4. Checkmark `SYN` and `ACL` in the `out of` column.
5. Ensure `Keep State` is checked.

Without those additional elements

PROFIT.  This took me ages to work out.