I did some additional tests as follows:
a) if I run udpxy not on the router itself, but on a computer on the LAN (192.168.1.101) and do 7881 port forwarding, it works as expected.
b) if I do 7881 port forwarding on the router but not to the udpxy service but to web service (Luci interface) it works as expected.
So the conclusion is that port forwarding works and a request is received by the udpxy from WAN. However it does not respond as needed if request comes from outside LAN. At the same time it responds if this request comes from within LAN.
I checked it using another router with the same OPENWRT build and the result was the same. Could anybody check it too? Run udpxy and access its open port from outside on OpenWrt Chaos Calmer 15.05.1?
I found the following basic check list to run through before considering port forwards "broken":
a) the destination ip is actually correct, check static lease, check local ip config of destination host - this is OK
b) the source ip is either unset (should be this way) or it is indeed matching the host trying to use the port forward - 99% of the cases should have the source ip unset ("src_ip" option, not "src_dip") - source ip unset
c) the source port is either unset (should be this way) or it is indeed matching the local outgoing port used by the client - 99% of the cases should have the source port unset ("src_port" option, not "src_dport") - source port unset
d) ports, protocol match the traffic that should be forewarded - this is OK
e) a service is actually listening on the destination port of the destination host - it does
f) accessing the own public ip from within the lan is not the same as actually testing a port forward from the outside. OpenWrt will attempt to setup some loopback rules but they only work by default if your lan network is called "lan" - my lan is called lan
g) traffic rules might overrule traffic redirects. So if you have a rule somewhere that says that tcp/22 should be rejected, it might prevent a port forward on tcp/22 from working - port 7881 is non-standard port, I use it for udpxy only
h) services listening on forwarded ports might interfere, so if you try to forward tcp/22 to an internal host but dropbear is listening on tcp/22 as well then it might fail under certain circumstances, so try a different port first - this could be a reason? No idea
i) use "{ iptables -nvL; iptables -t nat -nvL; } | grep port-nr" to see if you rules are actually reached, a counter of 0 means that either no traffic ever arrived or that the arriving traffic was not matched, because e.g. a bad "src_ip" is set - I understand that a request is received by udpxy but it is not treated properly if this request is from WAN
j) make sure the destination host uses the OpenWrt router as default route! - the router runs udpxy on 192.168.1.1
k) make sure the destination host does not firewall its local port incoming or outgoing! - I am sure
l) make sure the destination host is actually properly reachable from the router (arp & routing-wise) - I am sure
m) make sure the outgoing traffic is masqueraded (should be by default) - normally yes
n) make sure there are no NOTRACK rules in "iptables -t raw -nvL" that prevent conntracking from working - checked
o) make sure you actually created a DNAT rule. SNAT rules are a completely different thing - checked
p) "it works on the vendor firmware" means nothing without ensuring that the final rules are actually the same - agreed
q) if port forwards would be truly broken for everyone there would be a lot of reports about it. So far the overwhelming majority of cases turned out to be misconfigurations - could somebody check if udpxy is reacheable on 15.05.1?
