Yes this is for a Plex server and I would like to be to restore my SFTP server too. These work but just not with CTF enabled and max throughput without CTF is 400mbit vs. my ISP's 1gbit (900mbit on R7000 due to overhead/latency).
As mentioned Wireguard is a short term workaround to have CTF.
Joined: 08 May 2018 Posts: 14222 Location: Texas, USA
Posted: Sat Oct 09, 2021 17:20 Post subject:
Outside of what you have already tried that should work, and without me looking much deeper into why it doesn't work... or nobody else coming forward in open public forum with a working solution... that's the easiest way to go since you won't need any NAT acceleration with a proper x86 router and since SFE is benign to the situation of port forwarding working out of the box, you can use it if you need to without issue. _________________ "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
Posted: Sat Oct 08, 2022 6:05 Post subject: UPDATE: 10/7/2022 - Port forwarding special case with CTF
Hello,
After a lot of iptables -vnL sniffing, I have finally gotten my port forward to work in dd-wrt r49934 with my Netgear R7000. Here is what I had to configure to get this port forward rule to work:
1.) Add port forward rule in Admin. UI (NAT/QoS-->Port Forwarding)
2.) Add the following nat and INPUT rules to your Startup script (Administration-->Commands edit/save Startup script (change these for your LAN IP/port):
For some reason when I added these to the Firewall startup script, they did not take effect as expected (no traffic hitting these rules in iptables). After adding to Startup, my Plex server becomes immediately available/visible remotely via this forwarded port. I did not have to add any mangle rules either and it appears the issue the whole time was the Admin. UI Port Forward not creating these additional rules and then me trying to create them "too early" in post-restart of router.
Will post back if this changes/breaks but so far so good.
Side note:
The DDWRT Admin. UI shows the previous port forward rules I saved in the UI in /tmp/.ipt however, I don't see ANY of these rules post-startup in iptables -vnL - isn't /tmp/.ipt supposed to be added to the iptables chains during startup?
here is my current iptables -vnL output:
>>>>
Chain INPUT (policy ACCEPT 9308 packets, 1432K bytes)
pkts bytes target prot opt in out source destination
0 0 DROP tcp -- vlan2 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
1 44 DROP tcp -- vlan2 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
17 692 DROP tcp -- vlan2 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23
2 80 DROP tcp -- vlan2 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT all -- oet1 * 0.0.0.0/0 0.0.0.0/0 state NEW
0 0 ACCEPT udp -- vlan2 * 0.0.0.0/0 0.0.0.0/0 udp dpt:51820
Chain FORWARD (policy ACCEPT 9127 packets, 1507K bytes)
pkts bytes target prot opt in out source destination
265 13749 ACCEPT tcp -- * * 0.0.0.0/0 192.168.100.99 tcp dpt:32400
0 0 ACCEPT all -- oet1 * 0.0.0.0/0 0.0.0.0/0 state NEW
Chain OUTPUT (policy ACCEPT 6930 packets, 2059K bytes)
pkts bytes target prot opt in out source destination
Chain advgrp_1 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_10 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_11 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_12 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_13 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_14 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_15 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_16 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_17 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_18 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_19 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_2 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_20 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_3 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_4 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_5 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_6 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_7 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_8 (0 references)
pkts bytes target prot opt in out source destination
Chain advgrp_9 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_1 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_10 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_11 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_12 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_13 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_14 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_15 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_16 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_17 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_18 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_19 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_2 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_20 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_3 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_4 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_5 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_6 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_7 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_8 (0 references)
pkts bytes target prot opt in out source destination
Chain grp_9 (0 references)
pkts bytes target prot opt in out source destination
Chain lan2wan (0 references)
pkts bytes target prot opt in out source destination
Chain logaccept (0 references)
pkts bytes target prot opt in out source destination
Chain logbrute (0 references)
pkts bytes target prot opt in out source destination
Chain logdrop (0 references)
pkts bytes target prot opt in out source destination
Chain logreject (0 references)
pkts bytes target prot opt in out source destination
Chain trigger_out (0 references)
pkts bytes target prot opt in out source destination
Chain upnp (0 references)
pkts bytes target prot opt in out source destination
Also, it appears the default policy is ACCEPT for all iptables chains - don't see a DROP/REJECT in rule appended to any chains in iptables (is this normal)?
But what you are saying is that when those rules are made when the router starts the firewall they are not working but they do work if you make them 60 seconds later?
But what you are saying is that when those rules are made when the router starts the firewall they are not working but they do work if you make them 60 seconds later?
About your other question, there should be DROP rules on the last entry of INPUT and FORWARD if not your firewall is seriously flawed
@egc - yes, this is strange behavior and as to the latter point about having a DROP rule... I can try doing a firmware refresh to see if the default firmware install has this but I am not sure how that catchall DROP rule got dropped - maybe a bug in this release?
This chasing of different iptables rules all started after I did a clean install of r49934 (hard reset of router and reset to 'Default').
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Sat Oct 08, 2022 7:20 Post subject:
To be sure this is related to CTF+FA.
If you do not have CTF+FA enabled then Port Forwarding works but if you have this enabled then you have to make the Port Forward rules after 60 secs and then it works?
But what you are saying is that when those rules are made when the router starts the firewall they are not working but they do work if you make them 60 seconds later?
About your other question, there should be DROP rules on the last entry of INPUT and FORWARD if not your firewall is seriously flawed
To clarify, my rules worked when I added them to Startup (Commands) with a 60 sec. delay but not when they were added to rc_firewall (Firewall startup rules).
Also, shouldn't /tmp/.ipt rules show in iptables -vnL? My point about that file was that these saved rules (created via the UI were NOT showing post-boot with iptables -vnL from command line.
I will try adding a DROP rule to the INPUT and FORWARD chains (-A append) before doing a full firmware reset.
If you do not have CTF+FA enabled then Port Forwarding works but if you have this enabled then you have to make the Port Forward rules after 60 secs and then it works?
P.S. You really should try it with the normal Port Forward rules, the POSTROUTING and INPUT rule do not make sense (but CTF is a black box so who knows)
Yes, I need CTF/FA and without it enabled, port forwarding works without issue using the UI-built rules. This was the first thing I tested after upgrading to this release of ddwrt. Port forwarding with CTF/FA has not been working with standard port forwarding config... wish it would but that is where things are. I just wanted to share how I was able to get this port forward working and in the process it seems to have 'tweaked' other iptables rules somehow (missing DROP rule in the INPUT and FORWARD chains for example).
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Sat Oct 08, 2022 8:12 Post subject:
If the DROP rules are not present then there is something seriously wrong, just adding them is not the solution.
The solution is to find out what is wrong.
.ipt is the save.restore file of the internal rules including the Port FORWARD rules but the rules you add via Startup and Save Firewall are not
What I try to establish is if it is a timing issue with CTF+FA, so if you make normal portforward rules after 60 sec then it works
My .ipt
*mangle
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -p icmp -d xxxxxxxxx -j DNAT --to-destination 192.168.0.1
-A PREROUTING -p tcp -m tcp -d xxxxxxxxx --dport xxxxx -j DNAT --to-destination 192.168.0.2:xxxxx
-A PREROUTING -p udp -m udp -d xxxxxxxxx --dport xxxxx -j DNAT --to-destination 192.168.0.2:xxxxx
-A PREROUTING -p udp -m udp -d xxxxxxxxx --dport 51811 -j DNAT --to-destination 192.168.0.2:51811
-A PREROUTING -p tcp -m tcp -d xxxxxxxxx --dport xxxxx -j DNAT --to-destination 192.168.0.6:xxxxx
-A PREROUTING -p udp -m udp -d xxxxxxxxx --dport xxxxx -j DNAT --to-destination 192.168.0.6:xxxxx
-A PREROUTING -p udp -m udp -d xxxxxxxxx --dport xxxxxxxxx -j DNAT --to-destination 192.168.0.6:xxxxxxxxx
-A PREROUTING -d xxxxxxxxx -j TRIGGER --trigger-type dnat
-A POSTROUTING -s 192.168.0.1/24 -o eth0 -j SNAT --to-source xxxxxxxxx
-A POSTROUTING -s 192.168.111.1/24 -o eth0 -j SNAT --to-source xxxxxxxxx
-A POSTROUTING -o br1 -m pkttype --pkt-type broadcast -j RETURN
-A POSTROUTING -o br1 -s 192.168.111.1/24 -d 192.168.111.1/24 -j MASQUERADE
-A POSTROUTING -o br0 -m pkttype --pkt-type broadcast -j RETURN
-A POSTROUTING -o br0 -s 192.168.0.1/24 -d 192.168.0.1/24 -j MASQUERADE
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
:logreject - [0:0]
:trigger_out - [0:0]
:upnp - [0:0]
:lan2wan - [0:0]
:grp_1 - [0:0]
:advgrp_1 - [0:0]
:grp_2 - [0:0]
:advgrp_2 - [0:0]
:grp_3 - [0:0]
:advgrp_3 - [0:0]
:grp_4 - [0:0]
:advgrp_4 - [0:0]
:grp_5 - [0:0]
:advgrp_5 - [0:0]
:grp_6 - [0:0]
:advgrp_6 - [0:0]
:grp_7 - [0:0]
:advgrp_7 - [0:0]
:grp_8 - [0:0]
:advgrp_8 - [0:0]
:grp_9 - [0:0]
:advgrp_9 - [0:0]
:grp_10 - [0:0]
:advgrp_10 - [0:0]
:grp_11 - [0:0]
:advgrp_11 - [0:0]
:grp_12 - [0:0]
:advgrp_12 - [0:0]
:grp_13 - [0:0]
:advgrp_13 - [0:0]
:grp_14 - [0:0]
:advgrp_14 - [0:0]
:grp_15 - [0:0]
:advgrp_15 - [0:0]
:grp_16 - [0:0]
:advgrp_16 - [0:0]
:grp_17 - [0:0]
:advgrp_17 - [0:0]
:grp_18 - [0:0]
:advgrp_18 - [0:0]
:grp_19 - [0:0]
:advgrp_19 - [0:0]
:grp_20 - [0:0]
:advgrp_20 - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p udp --sport 67 --dport 68 -j ACCEPT
-A INPUT -i eth0 -p icmp -j DROP
-A INPUT -i eth0 -p igmp -j DROP
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -i br0 -m state --state NEW -j ACCEPT
-A INPUT -i br1 -p udp --dport 67 -j ACCEPT
-A INPUT -i br1 -p udp --dport 53 -j ACCEPT
-A INPUT -i br1 -p tcp --dport 53 -j ACCEPT
-A INPUT -i br1 -m state --state NEW -j DROP
-A INPUT -i br1 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -i br1 -j ACCEPT
-A INPUT -j DROP
-A OUTPUT -o br0 -j ACCEPT
-A OUTPUT -o br1 -j ACCEPT
-A FORWARD -i br1 -d 192.168.0.1/255.255.255.0 -m state --state NEW -j DROP
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j upnp
-A FORWARD -i br1 -j lan2wan
-A FORWARD -j lan2wan
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -o eth0 -s 192.168.0.1/24 -p tcp --dport 1723 -j ACCEPT
-A FORWARD -o eth0 -s 192.168.0.1/24 -p gre -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.0.2 --dport xxxxx -j ACCEPT
-A FORWARD -p udp -m udp -d 192.168.0.2 --dport xxxxx -j ACCEPT
-A FORWARD -p udp -m udp -d 192.168.0.2 --dport 51811 -j ACCEPT
-A FORWARD -p tcp -m tcp -d 192.168.0.6 --dport xxxxx -j ACCEPT
-A FORWARD -p udp -m udp -d 192.168.0.6 --dport xxxxx -j ACCEPT
-A FORWARD -p udp -m udp -d 192.168.0.6 --dport xxxxxxxxx -j ACCEPT
-A FORWARD -i eth0 -o br0 -j TRIGGER --trigger-type in
-A FORWARD -i br0 -j trigger_out
-A FORWARD -i eth0 -o eth1 -j TRIGGER --trigger-type in
-A FORWARD -i eth1 -j trigger_out
-A FORWARD -i eth1 -m state --state NEW -j ACCEPT
-A FORWARD -i eth0 -o wlan0 -j TRIGGER --trigger-type in
-A FORWARD -i wlan0 -j trigger_out
-A FORWARD -i wlan0 -m state --state NEW -j ACCEPT
-A FORWARD -i eth0 -o wlan1 -j TRIGGER --trigger-type in
-A FORWARD -i wlan1 -j trigger_out
-A FORWARD -i wlan1 -m state --state NEW -j ACCEPT
-A FORWARD -i eth0 -o wlan1.1 -j TRIGGER --trigger-type in
-A FORWARD -i wlan1.1 -j trigger_out
-A FORWARD -i wlan1.1 -m state --state NEW -j ACCEPT
-A FORWARD -i br0 -o br1 -m state --state NEW -j DROP
-A FORWARD -i eth0 -o br1 -j TRIGGER --trigger-type in
-A FORWARD -i br1 -j trigger_out
-A FORWARD -i br1 -m state --state NEW -j ACCEPT
-A FORWARD -i br0 -m state --state NEW -j ACCEPT
-A FORWARD -i br0 -o eth0 -j ACCEPT
-A FORWARD -i br1 -o eth0 -j ACCEPT
-A FORWARD -j DROP
-A logaccept -j ACCEPT
-A logdrop -j DROP
-A logreject -p tcp -j REJECT --reject-with tcp-reset
COMMIT _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
An old post from 2014 -- obviously these days DD-WRT does support CTF & CTF & FA on supported hardware, clearly the manufacturers kernel patches that he talks about are not present in DD-WRT for port forwarding to work like RMerlin explains it.
Joined: 26 Mar 2013 Posts: 1857 Location: Hung Hom, Hong Kong
Posted: Sat Oct 08, 2022 9:32 Post subject:
jacdc wrote:
To clarify, my rules worked when I added them to Startup (Commands) with a 60 sec. delay but not when they were added to rc_firewall (Firewall startup rules).
Also, shouldn't /tmp/.ipt rules show in iptables -vnL? My point about that file was that these saved rules (created via the UI were NOT showing post-boot with iptables -vnL from command line.
egc wrote:
What I try to establish is if it is a timing issue with CTF+FA, so if you make normal portforward rules after 60 sec then it works
Ha ha ha.. This trick really worked with my Asus RT-N18U!!
1. I deleted all port-forwarding and port-range-forwarding rules
2. I disabled STP, SFE, CTF, hit Apply and waited for DD-WRT's reboot
3. I enabled CTF (just CTF, no FA, no SFE), hit Apply
4. I wait for DD-WRT to reboot again
5. 5 or more minutes after DD-WRT came back from reboot, I added a simple port-forwarding rule, one port only.
6. I hit Apply and wait
7. Port-forwarding worked!
...
8. DD-WRT had been up for over 36 minutes, port-forwarding was still working.
I think jacdc was right about the sysinit issue. Why were processes restarted multiple times during start-up when they all should have been done once? I don't think the firewall was restarted that many times.
Next, I will just restart the firewall 5 minutes after startup, with the same simple port-forwarding rule added before enabling CTF.
BTW, I don't see any button in the WEBUI to restart JUST the firewall.
