NAT Reflection with FW rules containing aliases for IP addresses do not work
-
pfSense 2.4.2-RELEASE-p1
Having FW Rules and NAT setup with aliases for IP addresses. (Works great with split DNS)
When using NAT Reflection:
a.) Using aliases for IP addresses work but NAT Reflection DOES NOT. (Port aliases are ok)
You need to enter fixed IP addresses to make NAT Reflection work
b.) I have not found a note in the documentation about this issue.
This drove me nuts as all seemed to be setup correctly…It was only by chance finding a sidenote while searching the internet about a proper setup for this combination.
-
If you think you have found a bug you need to give specific steps to duplicate using specifics like IP addresses and stuff. Else nobody will know how to confirm what you are seeing or fix it.
-
Setup:
- WAN: DHCP
- LAN: 10.168.x/24
- One external IP (domain name = a.b.c.d) routed to the FW to access webservices, it is not the WAN address
- DNS resolver to resolve internal hosts on the LAN
- pfSense is gateway and DNS for LAN clients
- FW aliases for webservice_IP -> a.b.c.d, webserver_hostname -> 10.168.x.y, webserver_ports -> 80, 443
- FW NAT/Port-Forward: WAN, TCP, source: any, dest:host:webservice_IP, dest:port: webserver_ports, redirect:target: 10.168.x.y, NAT:Reflection: default
- FW Rule/WAN: IPv4, source: any, dest:host:10.168.x.y, dest:port: webserver_ports
- System/Advanced/FW&NAT, NAT Reflection mode for port forwards: Pure NAT, Enable automatic outbound NAT for Reflection: On
The above setup works. This means if you are in the LAN, you can access the webserver with his domain name. Traffic is routed thru the FW (NAT Reflection works). No split DNS used.
It stops working for clients on the LAN = no access for LAN clients to the webserver with his domain name, if you exchange 10.168.x.y with the alias: webserver_hostname
Using aliases is a great thing as you have only one place to edit things and changes pass thru. It also helps for better readability of the setup.
The issue comes up in the combination of aliases and NAT Reflection and is very hard to detect as the setup looks correct.
Either make this combaination work (preferred) and/or document the behaviour.
-
What kind of alias are you using? Host(s) or Network(s)?
-
webserver_hostname has a host alias
webservice_IP has a network alias -
I could not duplicate this.
WAN VIP: 172.25.228.10, Inside server 172.25.233.100
Redirect to address 172.25.228.10
NAT Inbound Redirects
rdr on re1 proto tcp from any to 172.25.228.10 port 80 -> 172.25.233.100
Reflection redirect
rdr on { re0 re2 enc0 openvpn } proto tcp from any to 172.25.228.10 port 80 -> 172.25.233.100
OPT1 tcp 192.168.1.100:36433 -> 172.25.233.100:80 (172.25.228.10:80) ESTABLISHED:ESTABLISHED 2 / 1 112 B / 60 B
LAN tcp 192.168.1.100:36433 -> 172.25.233.100:80 ESTABLISHED:ESTABLISHED 2 / 1 112 B / 60 BRedirect to Host Alias web_server
table <web_server>{ 172.25.228.10 }
web_server = "<web_server>"NAT Inbound Redirects
rdr on re1 proto tcp from any to $web_server port 80 -> 172.25.233.100
Reflection redirect
rdr on { re0 re2 enc0 openvpn } proto tcp from any to $web_server port 80 -> 172.25.233.100
OPT1 tcp 192.168.1.100:36434 -> 172.25.233.100:80 (172.25.228.10:80) ESTABLISHED:ESTABLISHED 2 / 1 112 B / 60 B
LAN tcp 192.168.1.100:36434 -> 172.25.233.100:80 ESTABLISHED:ESTABLISHED 2 / 1 112 B / 60 BRedirect to Network alias web_server_net
table <web_server_net>{ 172.25.228.10/32 }
web_server_net = "<web_server_net>"NAT Inbound Redirects
rdr on re1 proto tcp from any to $web_server_net port 80 -> 172.25.233.100
Reflection redirect
rdr on { re0 re2 enc0 openvpn } proto tcp from any to $web_server_net port 80 -> 172.25.233.100
OPT1 tcp 192.168.1.100:36435 -> 172.25.233.100:80 (172.25.228.10:80) ESTABLISHED:ESTABLISHED 2 / 1 112 B / 60 B
LAN tcp 192.168.1.100:36435 -> 172.25.233.100:80 ESTABLISHED:ESTABLISHED 2 / 1 112 B / 60 B</web_server_net></web_server_net></web_server></web_server> -
@Derelict I can confirm this bug in 2.4.4-RELEASE-p3
Here's how subtle and "awesome" it is.
- using an alias as the destination in normal nat works fine
- using an alias as the destination to an ip address works fine for nat reflection
- using an alias as the destination to a fqdn FAILS for nat reflection
So yeah...
Kurt
-
All aliases are IP addresses and networks under the hood. It makes no difference whether or not those IP addresses were entered directly or obtained via DNS lookup. NAT reflection won't care one bit. The rules using those aliases have no way to know and don't care whether it was a DNS lookup or not.
There are lots of nuances that can come up in NAT reflection. You are probably hitting one of those.
-
Maybe not related, but :
@kneufeld said in NAT Reflection with FW rules containing aliases for IP addresses do not work:
... this bug in 2.4.4-RELEASE-p3
So tests or reproduction can't be done, as it needs an ancient version.
Most of us use 2.4.5-p1, two versions ahead. -
-
Just sayin' that the NAT in pfsense (the pf firewall) that does NAT reflection has NO CONCEPT of an FQDN.
I would check the contents of the alias in Diagnostics > Tables in both cases. That is what pf will be operating on. See if you can spot the reason for it there.
It is much more likely that you are seeing something like the connecting client resolving the FQDN differently than the firewall is when it creates the alias table or something along those lines.
-
I just did it again. The Diagnostic > Table showed the same ip address both times. Yes I know it makes zero sense but maybe give it a try instead of saying how it's impossible.
Anyhow, I verified a reported bug, found a workaround, and then reported it. It's up to you if you want to act on it.
Kurt
-
Show, exactly, every step you have taken, what the name is, what it resolves to on the firewall and the client you are testing with.
There are no FQDNs in the pf configuration file. There is no reason for me to build it. There is another explanation for what you are seeing.
