(I suppose we're talking about 18.06 box) You mean it should have a port FORWARDING rule AND a normal firewall rule to accept packages to that port? If so, I tried all possible/impossible combinations in firewall section. Didn't work. Only thing worked is those custom rules. And it works without any forwarding rule configured in LuCi.
And I don't understand what you mean by "normal" gateway. Three interfaces WAN, LAN, IPSEC. All is up and working. Trying to open a port on WAN and send traffic to/from LAN web-server. Worked (with those custom rules).
On 22.03 trying to open port on WAN and send traffic to/from a web-server in IPSEC. (Server is reachable and pinging).
It's be helpful at this point to see the complete network and firewall configs (/etc/config/network and /etc/config/firewall). There's nothing particularly special about the port forward you're trying to use and a uci rule should work just fine.
What reports? I'm not aware of any particular issues with OpenWRT and port forwarding. I know that a uci rule consisting of all the same elements as yours (with different variables obviously) does work fine.
As it is, a fairly obvious issue would seem to be that your uci rule has a src_dport of 2222, but your custom rule is using 1111. Which is it?
Have you checked that the target device doesn't have a firewall that's blocking the connection? If the port forward rule wasn't working then I'd expect you to get a connection refused rather than a timeout.
And as for the thread you posted, if you read through it you'd have realised that the device in question wasn't actually using vanilla OpenWRT. It was using a version that had been customised (with god knows what changed) by a third party vendor. So again, there's no specific issue (as far as I'm aware) with OpenWRT and port forwarding.
Yes, I can connect to it from other WAN (by the way it's exactly 18.06 with those custom rules set).
And it was the same situation with 18.06 (connection timeout), until I also added custom SNAT back reply rule. It was no way to get it worked via LuCi. (And I suppose after I add forwarding rule reply-back rule should have be added automatically, but it's not).
So I think I need something like I did with iptables, but for newer nftables...
Notice the topic name. These 200 issues mentioned are not about vanilla OWrt. I say that because I read most of them to find a solution to my case. I understand that every case is individual, but numerous cases talk itself on that issue persists for a very simple router operation. (But let's forget about it)
config redirect
option dest '*'
option target 'DNAT'
option name 'test'
option src 'wan'
option src_dport '2222'
option dest_ip '192.168.1.48'
option dest_port '1111'
list proto 'tcp'
and
config redirect
option dest 'lan'
option target 'DNAT'
option name 'test'
option src 'wan'
option src_dport '2222'
option dest_ip '192.168.1.48'
option dest_port '1111'
list proto 'tcp'
Both work exactly as expected, i.e. trying to connect externally to my public IP on port 2222 reaches the listener on my local device using port 1111.
Port forwarding works. The fact that whatever you're connecting to doesn't appear to be able to respond without SNAT is not an issue with OpenWRT itself. It's either an issue with whatever you're connecting to or your wider setup.
It's an Apache server (in LAN zone for 18.06). Nothing special. If OpenWrt handles it WITH SNAT, I don't see why it doesn't WITHOUT it. So probably OpenWrt is responsible? Still digging...
Probably because it's something to do with how you've setup the Apache server. I would guess something like it's been set up to only respond to requests from 192.168.1.1 (or possibly a subnet containing that address). That'd be why it responds when the incoming packets (with a public IP) have had their source address rewritten, but doesn't when they haven't.
