NAT Reflection + Alias (configured with hostname) = Fail
-
First time poster. pfSense rocks!
I see some similar topics, but nothing quite this simple.
I have a WAN interface with a public internet IP and a LAN interface handling 10.1.0.0/16. All good -- everything works as it should.
I then set up NAT rules to forward WAN ports 80 and 443 to an internal IP (10.1.1.5), using "pure NAT" for reflection. Works perfectly from both inside and outside my LAN.
I then discovered the Alias feature, and went for that because I don't like to manage IPs everywhere. I configured the alias with the same IP address as I had configured for the NAT (10.1.1.5). Works perfectly from both inside and outside my LAN.
I then discovered that Aliases could refer to hostnames instead of IPs and I have a static mapping for the server I'm NATting to. Even better! Now there's just one place to manage IPs. So I set up the alias to point to the FQDN of the internal IP ("nginx.lan."). Works perfectly from outside the network, but not from inside.
Diagnostics ... Tables ... my alias shows the correct IP.
Changing the destination of the alias back to the IP address (10.1.1.5) returns it to a fully working state.
Is this a bug, or did I miss a warning about this?
Thanks!
-
I was about to post the same issue for pfSense+ 23.01-RELEASE and to me it appears to be a bug.
If an IP address or an alias pointing to an IP address is used in the NAT rule, NAT reflection works as expected.
If an alias is used in the NAT rule and that alias points to an FQDN, NAT reflection (PURE or NAT+PROXY) does not work: port is unreachable from the local LAN, no matter how long you wait.
@zsteinkamp did you ever end up filing an official bug report?
-
@deekayw0n I have not. Please feel free, or let me know if you'd like me to.