Bug #8233
openNAT reflection back to originating host broken when using FQDN-based IP aliases
0%
Description
It appears NAT reflection is slightly broken when targeted at an IP alias which is defined via FQDN (rather than IP address). In this case, reflection works from hosts on subnets other than the one that the NAT target is on, but not from the same subnet. Within the same subnet, it appears traffic it redirected to the target host, but the originating IP is not translated.
To put this in context, let's say I have a host ns.example.com at IP 10.0.0.10, and I want to redirect traffic sent to 1.2.3.4 to this host. Let's say I create an alias "NameServer", and create a NAT rule to translate traffic arriving on the WAN interface destined for the address 1.2.3.4, port 53 to "NameServer" port 53, and enable reflection. ("Enable NAT Reflection for 1:1 NAT" and "Enable automatic outbound NAT for Reflection" are enabled and 1.2.3.4 is an IP alias with an outbound NAT rule mapping traffic from "NameServer" to the NAT address 1.2.3.4, FWIW.)
If the alias "NameServer" points at the FQDN ns.example.com (which resolved internally to 10.0.0.10), then I run into this problem. If I make a DNS request to 1.2.3.4 from outside the server's subnet (let's say outside 10.0.0.0/24), everything is fine (even from interfaces other than WAN, so reflection is working… sort of). If I make a request from within the same subnet, I do see a response, but it comes directly from 10.0.0.10, not 1.2.3.4. (i.e. The request packet was clearly redirected to 1.2.3.4, but it doesn't actually seem to have gone through NAT.)
If the alias "NameServer" points at the IP 10.0.0.10, then everything works, and I see several additional translation rules:
no nat on lagg0 inet proto tcp from 10.0.0.1 to <NameServer> port = domain no nat on lagg0 inet proto udp from 10.0.0.1 to <NameServer> port = domain nat on lagg0 inet proto tcp from 10.0.0.0/24 to <NameServer> port = domain -> 10.0.0.1 port 1024:65535 nat on lagg0 inet proto udp from 10.0.0.0/24 to <NameServer> port = domain -> 10.0.0.1 port 1024:65535
These are in addition to rules of the following form, that exist either way:
nat on igb1 inet from <NameServer> to any -> 1.2.3.4 static-port no rdr proto carp all rdr-anchor "relayd/*" all rdr-anchor "tftp-proxy/*" all <Above rules here> rdr on igb1 inet proto tcp from any to 1.2.3.4 port = domain -> <NameServer> round-robin rdr on igb1 inet proto udp from any to 1.2.3.4 port = domain -> <NameServer> round-robin rdr on igb0 inet proto tcp from any to 1.2.3.4 port = domain -> <NameServer> round-robin rdr on igb0 inet proto udp from any to 1.2.3.4 port = domain -> <NameServer> round-robin rdr on lagg0 inet proto tcp from any to 1.2.3.4 port = domain -> <NameServer> round-robin rdr on lagg0 inet proto udp from any to 1.2.3.4 port = domain -> <NameServer> round-robin
(The DNS server is located on lagg0, on which the router has the IP 10.0.0.1. igb1 is WAN, and igb0 is the regular LAN interface.)
It appears the problem is that pfSense can't resolve the interface the host pointed to by "NameServer" will lie on at the time of rule creation, so is unable to create the necessary NAT rules to allow reflection to work within the same subnet. Perhaps either a new kind of "rdr" style rule that performs NAT when reflecting back out to the same subnet is necessary, or an option to specify an interface in addition to (perhaps connected to) a host alias is needed, to enable creation of these rules.