Chain INPUT (policy ACCEPT 24893 packets, 2043K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 391 packets, 74963 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 420K packets, 30M bytes)
pkts bytes target prot opt in out source destination
327K 33M SNAT all -- * vlan2 172.16.100.0/24 0.0.0.0/0 to:68.15.12.178
0 0 RETURN all -- * br0 0.0.0.0/0 0.0.0.0/0 PKTTYPE = broadcast
390 74629 MASQUERADE all -- * br0 172.16.100.0/24 172.16.100.0/24
root@DD-WRT-MAIN-BEACH:~#
Thank you for this, this matches my IP tables...didn't see any packets hitting your port forward (8080-->80) but for mine, packets come in but nothing goes back out.
Hi all,
Is there a solution for this issue?
A working iptables rule?
With CTF enabled i'm getting up to 900Mbit, but its no option if i can't access my own nextcloud anymore from internal. _________________ Netgear R7000
Hi all,
Is there a solution for this issue?
A working iptables rule?
With CTF enabled i'm getting up to 900Mbit, but its no option if i can't access my own nextcloud anymore from internal.
Hi cyberdev - nothing yet and MARK method to have forwarded traffic bypass CTF in iptables did not work either (for me). Tried a couple of new ddwrt release since 47206... still doesn't work. For now, I use Wireguard to access all forwarded services behind firewall... works well enough but taxing on my device(s) and R7000 CPU for prolonged sessions.
Btw.: If i remember correct, the Port forwarding was working fine, only i'm not able to connect to the external address from my internal network (loopback) _________________ Netgear R7000
Btw.: If i remember correct, the Port forwarding was working fine, only i'm not able to connect to the external address from my internal network (loopback)
Not sure if this is the official process and this thread (here) seems to have run its course in terms of fixes for this issue. I also tried a clean (NVRAM reset) with a more recent (3 days old build - r47474) and the same issue comes up - Port forwarding works until I enable CTF as the Shortcut Forwarding Engine.
I guess for now I can keep hoping/trying a new build to see if this gets fixed but do you know what BS/others would need to delve into why this is not working or get some progress on that side of things (dev.)? I can't ship them a router and from what I have read, this CTF is a closed source module that ddwrt dev. wouldn't know much about it works and interacts (with iptables)?
I was having the same problem, port forwards won't work only when using CTF.
Wiped all, flash newest firmware (DD-WRT v3.0-r47495), and now it works.
(Don't use any nvram backups)
Hi diogosena - thank you for sharing this information. I will try the current release (r47495) with my R7000 and confirm if this is working again. What port forward did you test/confirm with (non-standard port like 15000 etc. or with a standard SSH (22)?
I was having the same problem, port forwards won't work only when using CTF.
Wiped all, flash newest firmware (DD-WRT v3.0-r47495), and now it works.
(Don't use any nvram backups)
Hi diogosena - thank you for sharing this information. I will try the current release (r47495) with my R7000 and confirm if this is working again. What port forward did you test/confirm with (non-standard port like 15000 etc. or with a standard SSH (22)?
Thanks.
J
Hi @diogosena - I went ahead and installed 47495 with an NVRAM/restart. Unfortunately, with a basic setup and a single port forward (port 32400), I am still unable to reach my NAT'd internal IP (192.168.100.99) from outside my network. I tested this after 2 restarts once the R7000 was flashed so that CTF/FA options were available in the Setup tab. Once I selected these, the port forward rule for 32400 timed out. I then select the Shortcut Forwarding Engine to 'SFE' and almost immediately traffic to 192.168.100.99:32400 started to flow and I could reach the service listening on that port.
Hopefully Brainslayer/others know what is causing this (just can't fix at the moment)? I reverted back to 47206 and will continue to use Wireguard to bypass using port forward rules...CTF is just too good to not use with my 1Gbps up/down ISP connection and hardwired Ethernet clients!
Joined: 08 May 2018 Posts: 14126 Location: Texas, USA
Posted: Fri Oct 01, 2021 19:42 Post subject:
Either I have completely missed the information, or you have not specified if your R7000 is behind any other device connected to your ISP. There is also the possibility that you are over-engineering this situation. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Either I have completely missed the information, or you have not specified if your R7000 is behind any other device connected to your ISP. There is also the possibility that you are over-engineering this situation.
Setup is simple - R7000 is behind a fiber to ethernet OTN. R7000 was flashed and NVRAM reset... no configuration was restored in testing the latert ddwrt build. Takes 2 reboots for CTF to be a selectable kernel module in ddwrt UI. I selected that and then set a simple port forward rule to forward traffic to my device connected to R7000 ethernet at 192.158.100.99 port 32400. With CTF emabled connection times out. Selecting SFE as ShortCut Forwarding Engine (under Setup tab) immediately, traffic flows to this IP and port (didn't even have to restart R7000).
I would keep using Wireguard to avoid these port forward rules but not all my devices have that client that need to connect to my home network.
Hi @kernel-panic69- any other suggestions or is the MARK method in firewall confirmed not to work with CTF/FA enabled? New firmware release I should try?