Aliases not working with NAT reflection
-
I have the latest fixes for NAT reflection in 2.0 and it is working fine if I enter in an IP address directly in the port forward rule. However, if I use an alias instead of the IP address, that alias ends up in inetd.conf and then the entry doesn't work, giving this error over the connection: "nc: getaddrinfo: hostname nor servname provided, or not known"
Sample non-working line:
19000 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 $mywebserver 80If I change the port forward to use the actual IP address instead of the alias, I get this in inetd.conf instead and then it works:
19000 stream tcp nowait/0 nobody /usr/bin/nc nc -w 2000 192.168.0.24 80I don't really know whether inetd.conf can or cannot use the aliases in some way, but for now I'm assuming it can't. On my own pfSense box, I've modified the function in filter.inc that adds rules for NAT reflection so that it resolves the aliases, and now NAT reflection appears to be working as it is supposed to.
-
Open up a bug report in redmine and attach your fix as a patch, it might speed up the process.
-
Committed another fix. Thanks for reporting.
-
I suppose I should have been more specific. The variable called $target in that function will currently receive an alias instead of an IP address if the port forward uses an alias for the destination and then this ends up getting put into inetd.conf and not working.
By the way, something to be aware of if you do check the target's alias for whether it is an IP address: in my case, I'm seeing leading spaces after expanding the alias, which I did not add when I created the alias, making is_ipaddr fail if I try to use it on the expanded alias as-is. I wasn't sure whether the port forwards also accept host names or only accept IP addresses, though.
-
That commit from about an hour ago should fix the issue. It should all be working now. I'll try it out when there are new snapshots again.
By the way, the other change, the one affecting $extaddr, is probably not necessary though, as that is only used for the redirect rule, which should be able to use the same value for $extaddr as the code for the port forwards.As for $target, that is going into inetd.conf, which doesn't appear to know anything about the aliases from the rules file. -
Thinking about it more, what would happen and what should happen with NAT reflection if the user selects "any" for external address? Maybe that change you made with $extaddr might prevent the case I'm thinking of where it might possibly redirect all outgoing connections on that port if the user selected "any" for the external address. For example, if it does what I'm thinking it might, forwarding port 80 on an external address of "any" with NAT reflection on might redirect all web sites to the local web server that the port forwarding rule directs it to. What I'm describing sounds related to a bug I recall reading about in a recent forum post (on 1.2.3, I think).
update:
Actually, the bug I was thinking of was mentioned early December on the 1.2.3 rc forum, but it did not ever get any replies, probably because of the 1.2.3 release shortly after.
