I’m not sure what you think the connection between NAT reflection and network security is. NAT reflection exists because NAT exists, which in turn exists because of the IPv4 address space shortage. In a perfect world (i.e. a world where everyone uses IPv6) we wouldn’t need NAT because every IP address is routable on the internet. Network security is an entirely separate issue.
Say you have a set of local networks with internet-routable addresses (as with IPv6 for example) connected to your router (which also has firewall functionality), one is an intranet and one is a DMZ. Inside the DMZ, you have a bunch of servers. Additionaly, the router is connected to the internet:
When a node “A” on the internet wants to access a node “B” inside the DMZ, it can do so simply by using B’s IP address. What is more likely though, is that it will perform a DNS lookup for B’s domain name first in order to get B’s IP address. The router will eventually receive the packet because all hops in between know that B’s IP address is behind your router. The router will then route the packet into the DMZ.
When a client “C” from the intranet wants to access B, it can do the same thing as A did. This time, the router will receive the packet on its intranet interface, but will still know to route it into the DMZ.
Firewall rules (“security”) can and should be used at this stage to decide whether the router will indeed route the packets into the destination network (“pass”) or not (“drop” / “reject”).
Now say there is only one internet-routable IP address that is routed to your router (as opposed to one for each node in your local networks). Nodes in your local networks will have to be assigned private addresses. When B and C want to communicate with each other using their respective private IP addresses, the router can simply route the packets between the two networks. When they want to connect to the internet, the router could simply route the packets into the internet, however the receiver wouldn’t be able to send a reply because the source address of the packet (which the reply would be sent to) is not routable on the internet.
Therefore, the router has to perform NAT. Simplified, that means it will change the packet’s source address to its own, internet-routable address before sending it out its internet network interface. It will also change the source port number and log all that information in a state table, so when a reply comes back, the router knows which internal network to route it to. This type of nat is called “source NAT”.
In the opposite case, when A wants to connect to B, it has to address the router instead. There is no way for A to know B’s IP address (since it is private) and even if it did, intermediate hops on the route would not know where to find it. So again, the router has to perform NAT. But while the source NAT is usually done automatically (so that local nodes can always connect to the internet), in this case the router will only perform NAT when the incoming packets match a (user-)defined rule. This type of NAT is called “destination NAT”.
In pfSense at least, these rules will always be bound to a specific interface, in this example the internet network interface (otherwise called “WAN interface”).
Now, I stated above that when B and C want to communicate, they can do so using their private IP addresses and that statement still holds. But when domain names are used instead, C’s domain name must resolve differently based on where the lookup is made from. When looked up from the intranet or the DMZ, it must resolve to C’s private IP address. When looked up from the internet, it must resolve to the router’s public IP address. This is called “split-horizon DNS” or just “split DNS”.
But what happens when B does not resolve C’s domain name to its private address, but to the routers public address instead, same as a node on the internet would? In this case, the router would receive the packet and don’t know what to do with them because the NAT rule is bound to the WAN interface. However, the packet will be coming in from the intranet network interface, so the rule won’t match. This is (finally
) where NAT reflection comes in. When NAT reflection is enabled and the router receives a packet on the DMZ or the intranet interface which has the router’s public IP address set as the destination, the packet will be treated as if it were coming in from the WAN interface. Therefore, the NAT rule will now match the packet and NAT will be performed.
So…
To answer the question “why would you need NAT reflection” - in most cases you don’t - if you have split DNS set up. Split horizon is to be preferred over NAT reflection because when a packet originates in the DMZ and is destined for another node in the DMZ, it doesn’t have to leave the DMZ at all.