It's 99.9999% an issue with the setup on the device you're connecting to.
You mean the end-device where ports are forwarded to?
Yep, it's an issue with the device, not OpenWRT.
Other WAN?
Can you show this rule that makes it work?
Are there any hits on the current rule? Your rule was named 2222 before. If it’s changed, replace it below.
nft list ruleset | grep 2222
2 Likes
nft list ruleset | grep 2222
meta nfproto ipv4 tcp dport 2222 counter packets 2 bytes 112 dnat ip to 192.168.1.188:3389 comment "!fw4: 2222"
meta nfproto ipv4 udp dport 2222 counter packets 0 bytes 0 dnat ip to 192.168.1.188:3389 comment "!fw4: 2222"
Please see above, it's an iptables second rule (pls note, this is for 18.06 box, NOT this 22.03 one I'm testing)
1 Like
Not sure. ANY DEVICE (hardware or virtual) ports are forwarded to, ANY port (22, RDP, 80) - no connection is established.
LOOK, scheme is:
OpenWrt22 ---> ipsec -> OpenWrt18 ---> (hardware/virtual)
OpenWrt22 can ping all hardware/virtual
ALSO, I can access Apache (virtual) via OpenWrt18. From outside in whole of my network, used cell internet.
I agree with others, something is wrong with your server setup.
Unless you prefer all traffic to have a SRC IP of 192.168.1.1 - traffic should work successfully with the original SRC [Public] IP of the sender on WAN.
2 Likes
Needing to change the packet's source IP to get the device to respond means (pretty much certainly) that it's something on the device that's interfering. Either that or something else in-between the router and the device.
Packets have been matched against the port forwarding rule so the OpenWRT firewall isn't getting in the way.
1 Like
Guys, thanks but...
- It was the same problem with 18.06, until I added those DNAT/SNAT rules
- NOTHING is between 18.06 and 192.168.1.188 (it's plugged into its LAN directly, no firewalls, I can connect to it from any device)
Because it's got nothing to do with OpenWRT. Changing the OpenWRT version isn't going to fix an issue on a completely separate device.
The issue is the device only accepting connections from certain addresses (from the sounds of it, the subnet it is part of). All you did when you added a SNAT rule was work around that restriction.
3 Likes
You don't understand. BOTH BOXES are used at the same time in my scheme. I'm not switching them one to another to check the network.
Not sure what this means. Are you testing this rule locally or from WAN?
We agree it works from LAN.
Can you better explain this?
i.e. - Are you making one rule and expecting them to apply on all OpenWrt devices, do you have 2 Internet connections, etc.?
From WAN. And yes. other WAN.
Please look at the scheme I described above. Made it bold.
So we've gone from "simple" port forwarding to a setup containing two routers, a VPN, and virtualisation....
I'm even more convinced now that it's going to be a configuration issue somewhere along the line.
1 Like
Can you post the output of these? You can hide you public IP.
nft list chain inet fw4 dstnat
nft list chain inet fw4 dstnat_wan
1 Like
This is the only text I see in boldface:
@krazeh - do you see some configs for a second WAN or policy-based routing to handle that?
I'm confused, there's a second router/firewall/Internet somewhere?
How is that related to the device in question then?
NOpe, if you consider ONLY 18,06 box and connected to it laptop 192.168.1.18 (or whatever else, including VM Apache server, which CAN BE OPENED FROM OUTSIDE, if those 2 iptables rules were implemented)
Forget about tunnel, virtualization etc. Simple forwarding should work without those 2 iptables rules, right?
And there's a reason for that, especially if you have a second gateway/router/firewall available on 192.168.1.0/24 that you're telling us not to consider.
That's what posters are suggesting you fix.