I noticed a couple of funny side-effects to the recent changes (mostly this commit) that switched the router to listening for remote ssh / http connections directly, instead of redirecting these through the NAT to the local-access listeners:
1) Connecting to [wan ip]:[remote access port] on these services from *inside* the LAN now fails unless NAT loopback is set to "all"; whereas they used to also work when set to "forwarded only" (which is the default).
This will confuse people who use DDNS-based bookmarks for both local and remote access — these will stop working when they are inside the LAN. Lots of simple ways to fix this, but I'm not sure what the best answer is.
2) Packets from these connections pass through the QOS rules with the WAN IP as the source IP. Previously, because of the redirection, it would be the router's LAN IP.
This is somewhat unintuitive, since (conceptually) QOS rules are applied as traffic leaves the LAN, before the NAT changes the headers, and one would expect that if traffic from the router is included in QOS, its LAN IP would be the way to match it.
If you have a dynamic IP, there really isn't an easy way to match these connections (short of entering your ISP's whole dynamic IP pool, eg, "18.104.22.168/18"). Source MAC rules might work in some cases, but not for PPP-based connections.
I was thinking there might be some value in defining a certain reserved name that is automatically replaced by the WAN IP (if one exists) when rc/qos.c writes out the iptables rules. Since the WAN IP is hardcoded in NAT rules, all the firewall/QOS rules get rewritten with wan-up already, so this should be enough to ensure the rule is always using the current WAN IP.
Alternately: watch for instances of the router's LAN IP, and then silently duplicate the iptables entry using the WAN IP.
Does this make sense? Any suggestions, alternatives?
3) This relates specifically to the switch back to not having httpd listen on IPADDR_ANY: if you use ssh port forwarding to connect to httpd remotely, the typical way of specifying the forward — [whateverport]:localhost:80 — doesn't work (on IPv4), since httpd is not listening on the local loopback IP. It's easy enough to work around, just a bit confusing.
… Actually, hold on, "localhost" isn't even being set, unless Samba server is in the build. Hmm. That's odd. Any reason for that?
The previous point still stands, if localhost *was* set, or "127.0.0.1" is specified instead. I'm not sure if this is enough of a concern to bother fixing, although with TB's brand-new rewritten httpd listener functions (awesome job btw!) it would be a simple addition.