Project

General

Profile

Bug #8233

NAT reflection back to originating host broken when using FQDN-based IP aliases

Added by Alfred Barnat over 1 year ago. Updated 27 days ago.

Status:
New
Priority:
Very Low
Assignee:
-
Category:
NAT Reflection
Target version:
-
Start date:
12/22/2017
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.2
Affected Architecture:

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.

History

#1 Updated by Jim Pingle about 1 month ago

  • Category set to Rules / NAT
  • Priority changed from Normal to Very Low

#2 Updated by Jim Pingle 27 days ago

  • Category changed from Rules / NAT to NAT Reflection

Also available in: Atom PDF