I'm trying to open a port but without success, I'm not in cgnat (i have public ipv4)
I tested other devices and OS (Windows, Linux, Mac) but unsuccessful, my isp onu is bridge
config redirect
option dest 'lan'
option target 'DNAT'
option name 'Torrent'
option family 'ipv4'
option src 'wan'
option src_dport '57340'
option dest_ip 'MY LAPTOP IP'
option dest_port '57340'
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):
Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
What are first 2 numbers in WAN IP address?
Why not (mini)upnp(d-nftables) ?
If you really have a public IP, forget about rules for a while and use tcpdump on OpenWrt to check if anything comes from the Internet.
You can use any external service like https://canyouseeme.org to test various ports.
1234567890
config redirect
- option dest 'lan'
option target 'DNAT'
option name 'Torrent'
option family 'ipv4'
option src 'wan'
option src_dport '56464'
option dest_ip '192.168.2.158'
- option dest_port '56464'
"version": "24.10.2",
You can upgrade it to current with owut or luci-app-attendedsysupgrade
First numers is 191
Thats ok, now fix the rule.
So a leave blank both red options (internal port / destionation zone) but still doesn't work
Leave the rule alone!
Please see [SOLVED] Port forwarding not working on wan - #8 by AndrewZ and below.
tcpdump -i wan -Q in tcp port 56464
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Great, your problem has nothing to do with OpenWrt.
I don't have any router with PPPoE at the moment, so I'm not 100% sure that wan is the right interface to use here.
Run tcpdump -D to see the list of interfaces, then if something like PPP* is there - retest with another interface name.
torrent is udp too....
Rule example: https://github.com/openwrt/firewall4/blob/b6e5157527d361f99ad52eaa6da273cb0f2dfd59/tests/03_rules/07_redirect#L63
Resulting nft rule (note the counter)
https://github.com/openwrt/firewall4/blob/b6e5157527d361f99ad52eaa6da273cb0f2dfd59/tests/03_rules/07_redirect#L293
I added a rule in "Traffic Rules" and it worked for a few minutes
Success: We can see your service on 2804 xxx on port (56464) Your ISP is not blocking port 56464
Success: We can see your service on 191 xxx on port (56464) Your ISP is not blocking port 56464
but now " Failed: We can NOT see your service on 191 on port (56464)
Reason: Connection refused"
Ipv4 and ipv6
You don't need any rules for the initial test and external service is required only to generate the traffic.
For results please refer to tcpdump output on your local system.
See if pppoe-wan is the interface name you should use with tcpdump.
My point is to set up the rule, then use builtin test in the torrent client.
Sorry for the delay but I finally found the problem.
I just make a software reset and now port forwarding is working again, perhaps some package caused this conflict.
I want to thanks everyone for their help.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
