I'm setting up a new R7800 with LEDE Reboot 17.01.4 r3560-79f57e422d.
I have a port-forward to an internal host (with "NAT Loopback" checked) which works properly from the WAN, and at first worked properly from the LAN (e.g., I can connect from lan to the external IP address/port and get a response from the internal host).
But now, the NAT loopback stopped working, in that packets aren't reaching the internal server. So I installed tcpdump on the router to try to diagnose it. And found that while tcpdump is running (capturing from br-lan) the NAT loopback started working again. And if I stop the tcpdump, the NAT loopback stops working.
Weird huh? Any ideas? (Other than to tell me to just keep a tcpdump running, which is what I'm doing )
One more thing which is relevant: I have two IP addresses on the WAN interface. Both IP addresses are on the same /29 subnet. I also have port forwards associated with each public address; and they both work (via NAT loopback) when tcpdump is running and both stop working when I stop the tcpdump.
I couldn't use the ip command to set promisc, but ifconfig br-lan promisc seemed to work. So now, the port forwards are working with br-lan set to PROMISC instead of a tcpdump running. Makes sense, as tcpdump also puts the port in promiscuous mode.
So now the question is, why is the port forwarding only working with the lan in promiscuous mode?
(Another question: what's the proper way to edit the configuration to make br-lan be promisc?)
I am running into the EXACT same problem. Is it normal that NAT loopback is completely broken without the bridge being in promiscuous mode? Are there any downsides to simply enabling it on the bridge at all times? For example, in terms of performance?