BTW, speed-wise and compared to SFE, CTF seemed to increase transfer rate a little bit, BUT, I am merely using a 100M broadband.
Also, DNS over TLS test (aka Unbound) results are far more consistent with CTF than SFE.
Lastly, I remember some users talking about marking packets using iptables could make CTF + port-forwarding work. I think these users could also stop doing it and just try a firewall restart.
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
BTW, speed-wise and compared to SFE, CTF seemed to increase transfer rate a little bit, BUT, I am merely using a 100M broadband.
Also, DNS over TLS test (aka Unbound) results are far more consistent with CTF enabled and SFE disabled.
Lastly, I remember some users talking about marking packets using iptables could make CTF + port-forwarding work. I think these users could also stop doing it and just try a firewall restart.
Ok - I think as @egc mentioned earlier, I have a bigger issue with the firewall service. NONE of the rules here - /tmp/.ipt are being loaded/used after reboot. I have disabled CTF/FA and am just using SFE at this point and no matter what, my iptables -L is just 'empty'. The only rules that appear to show up are for Wireguard (nat POSTROUTING rule and a INPUT rule). When I issue a 'restart firewall' command post-boot, the only rules showing with iptables -L are the above WG rules.
Any ideas why 'restart firewall' is not pulling the rules in nvram or in /tmp/.ipt? Is there a way to see if the firewall service is actually running? Here is what I see in /var/log/messages when issuing a 'restart firewall':
Oct 8 09:58:01 jb-home kern.alert kernel: [ 719.869801] fast-classifier: shutting down
Oct 8 09:58:01 jb-home user.info : [sfe] : shortcut forwarding engine successfully stopped
Oct 8 09:58:01 jb-home user.info : [sfe] : shortcut forwarding engine successfully started
Oct 8 09:58:01 jb-home kern.alert kernel: [ 720.055962] fast-classifier (PBR safe v2.1.6b): starting up
Oct 8 09:58:01 jb-home kern.alert kernel: [ 720.061697] fast-classifier: registered
Oct 8 09:58:02 jb-home kern.alert kernel: [ 720.534841] fast-classifier: shutting down
Oct 8 09:58:02 jb-home user.info : [sfe] : shortcut forwarding engine successfully stopped
Oct 8 09:58:02 jb-home user.info root: WireGuard number of non failed tunnels in fail set: 0
Oct 8 09:58:02 jb-home user.info root: Flush delete PBR interface oet1, table : 21
Oct 8 09:58:02 jb-home user.info root: Enable WireGuard interface oet1 on port 51820
Oct 8 09:58:02 jb-home kern.info kernel: [ 721.117770] device oet1 entered promiscuous mode
Oct 8 09:58:02 jb-home user.info root: WireGuard 10.4.0.1/24 added to oet1
Oct 8 09:58:02 jb-home user.info root: WireGuard acquiring /tmp/oet.lock for 3510
Oct 8 09:58:02 jb-home user.info root: WireGuard /tmp/oet.lock acquired for 3510
Oct 8 09:58:02 jb-home user.info root: WireGuard waited 1 seconds to set routes for oet
Oct 8 09:58:02 jb-home user.info root: WireGuard route 10.4.0.6/32 added via oet1
Oct 8 09:58:02 jb-home user.info root: WireGuard route 10.4.0.7/32 added via oet1
Oct 8 09:58:03 jb-home user.info : [vpn modules] : vpn modules successfully unloaded
Oct 8 09:58:03 jb-home user.info : [vpn modules] : nf_conntrack_proto_gre successfully loaded
Oct 8 09:58:03 jb-home user.info : [vpn modules] : nf_nat_proto_gre successfully loaded
Oct 8 09:58:03 jb-home user.info : [vpn modules] : nf_conntrack_pptp successfully loaded
Oct 8 09:58:03 jb-home user.info : [vpn modules] : nf_nat_pptp successfully loaded
Oct 8 09:58:03 jb-home user.info root: WireGuard Inbound Firewall deactivated on oet1
Oct 8 09:58:03 jb-home kern.alert kernel: [ 722.352440] fast-classifier (PBR safe v2.1.6b): starting up
Oct 8 09:58:03 jb-home kern.alert kernel: [ 722.358252] fast-classifier: registered
Oct 8 09:58:03 jb-home user.info : [sfe] : shortcut forwarding engine successfully started
Oct 8 09:58:04 jb-home user.info root: WireGuard released /tmp/oet.lock for 3510
Oct 8 09:58:04 jb-home user.info : [sfe] : shortcut forwarding engine successfully started
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sat Oct 08, 2022 17:51 Post subject:
mwchang wrote:
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.
Some services depend on others and while some such services support reloading config files without restart, not all do so they will umpteen times do it.
NTP depends on WAN, cron depends on NTP synced time, anything that depends on cron needs to restart, its not so simple in practice except to type stuff we may think.
The router needs to be up and read ASAP, anything else should happen in background transparently. Not so easy when you have umpteen devices to support.
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Sun Oct 09, 2022 4:08 Post subject:
[quote="jacdc"]
mwchang wrote:
Ok - I think as @egc mentioned earlier, I have a bigger issue with the firewall service. NONE of the rules here - /tmp/.ipt are being loaded/used after reboot. I have disabled CTF/FA and am just using SFE at this point and no matter what, my iptables -L is just 'empty'. The only rules that appear to show up are for Wireguard (nat POSTROUTING rule and a INPUT rule). When I issue a 'restart firewall' command post-boot, the only rules showing with iptables -L are the above WG rules.
Any ideas why 'restart firewall' is not pulling the rules in nvram or in /tmp/.ipt?
Are you using Firewall Script to load your custom rules? What if you delay your script for 60 seconds by calling SLEEP command?
I suspect the User Firewall Script was executed BEFORE the system firewall script finished execution or started or before sysinit finished, and hence all your custom rules were lost. A delay usually works.
Quote:
Is there a way to see if the firewall service is actually running? Here is what I see in /var/log/messages when issuing a 'restart firewall':
I issued 'restart firewall' and got nothing in /var/log/messages nor any messages in the console. However, if I tried:
Code:
# service firewall stop
# service firewall start
cat: can't open '/proc/sys/net/netfilter/nf_conntrack_flush': No such file or directory
cannot open /proc/sys/net/ipv6/neigh/default/gc_thresh1
cannot open /proc/sys/net/ipv6/neigh/default/gc_thresh2
cannot open /proc/sys/net/ipv6/neigh/default/gc_thresh3
cannot open /proc/sys/net/ipv4/conf/br0/loop
[vpn modules] : vpn modules successfully unloaded
[vpn modules] : nf_conntrack_proto_gre successfully loaded
[vpn modules] : nf_nat_proto_gre successfully loaded
[vpn modules] : nf_conntrack_pptp successfully loaded
[vpn modules] : nf_nat_pptp successfully loaded
I suspect that the firewall was very closely tied to DD-WRT's VPN service, because back then, VPN was an attractive feature and most home routers didn't have it.
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Sun Oct 09, 2022 4:15 Post subject:
the-joker wrote:
Some services depend on others and while some such services support reloading config files without restart, not all do so they will umpteen times do it.
NTP depends on WAN, cron depends on NTP synced time, anything that depends on cron needs to restart, its not so simple in practice except to type stuff we may think.
As before I totally understand these. I suspect because DD-WRT was rushed to completion, some bad decisions was made about designing the sysinit process.
Quote:
The router needs to be up and read ASAP, anything else should happen in background transparently. Not so easy when you have umpteen devices to support.
I would say we need more skilled developers with router/DD-WRT and solid C knowledge. Sure let me look in my pocket... oops, none.
If DD-WRT's sysinit was not coded in C but a shell script, it would be a lot easier to handle! _________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Posted: Sun Oct 09, 2022 18:19 Post subject: Issue found in port forward rule
egc wrote:
I have seen that when there is a an error in the firewall rules.
After the error the .ipt does not load any further
Hi @egc - thank you for pointing this out...I ended up copying the contents of /tmp/.ipt to the Firewall Startup script (saves to /tmp/.rc_firewall) to get the default rules for security etc. back working. This actually worked and in the process I found out why the original rules were not being picked up on reboot - a forwarding rule for port 21 (FTP) had a network mask of '0.0.0.0.0' instead of the correct format - '0.0.0.0/0'. Apparently, the DDWRT UI allows this as I could enter a dummy rule and no UI warning displayed (probably another bug to file).
In any case, after fixing this in the Firewall Startup admin. and confirming the same in the /tmp/.ipt, then issuing a 'restart firewall' command, all of the default rules displayed with 'iptables -vnL'.
I also confirmed that the previous port forwarding (INPUT,FORWARD,etc) were present after the firewall restart so this confirmed the UI-based port forwarding still works in this release.
As for the original update and getting port forwards to work, I still needed to add a NAT POSTROUTING rule to get remote playback working with my Plex server. Adding the following rule:
Is what allowed playback to work despite Plex Media Server (Remote Access) showing as 'Connected'. This may be an issue with Plex, but was needed even though there is a MASQUERADE rule in this NAT chain (unchecking the Filter WAN NAT Redirection under Security-->Firewall) as:
MASQUERADE all -- * br0 192.168.xxx.0/24 192.168.xxx.0/24
I still can't cast to my Sonos system remotely (even though it comes right up in my apps. as a player and the app. connects to it) so I think this is more an issue with Plex (TLS negotiation) than a network issue.
All in all, got a very thorough "education" in iptables with this experience and am still happy with the multiple improvements to both the UI (faster loading) and stability in this build.
BTW - am still using CTF/FA to get the highest speed I can with this R7000 hardware and am still working through port forwarding for FTP (Passive with Explicit TLS encryption). Connections from remote clients to FTP get hung up AFTER initial login/handshake - directory listing always hangs (internal vs. external IP address being passed to the FTP client causes the connection to hangup).
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Mon Oct 10, 2022 7:00 Post subject: Re: Issue found in port forward rule
jacdc wrote:
... Connections from remote clients to FTP get hung up AFTER initial login/handshake - directory listing always hangs (internal vs. external IP address being passed to the FTP client causes the connection to hangup).
Did you forward both port 20 and 21 to the real FTP server? Both TCP and UDP protocols? Standard FTP needs 2 ports.
There is passive mode FTP that allows you to use other ports, and you still needed 2 ports. I seldom played with passive FTP mode.
BTW, some ISPs block FTP and HTTP servers at default ports.
_________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Mon Oct 10, 2022 7:03 Post subject: Re: Issue found in port forward rule
[quote="mwchang"]
jacdc wrote:
... Connections from remote clients to FTP get hung up AFTER initial login/handshake - directory listing always hangs (internal vs. external IP address being passed to the FTP client causes the connection to hangup).
Did you forward both port 21 and 20 to the real FTP server? Both TCP and UDP protocols? Standard FTP needs 2 ports. I barely remember that port 21 is for commands and port 20 for data.
There is passive mode FTP that allows you to use random ports above port number 1024, and you still needed 2 ports(p, p-1). I seldom used it and am not familiar with it.
I don't know whether the default FTP server of DD-WRT supports passive FTP. But you have the choice to use ProFTPD in Entware, which has a lot of features in addition to passive FTP support.
BTW, some ISPs block FTP and HTTP servers at default ports.
Posted: Tue Oct 11, 2022 17:53 Post subject: Re: Issue found in port forward rule
[quote="mwchang"]
mwchang wrote:
jacdc wrote:
... Connections from remote clients to FTP get hung up AFTER initial login/handshake - directory listing always hangs (internal vs. external IP address being passed to the FTP client causes the connection to hangup).
Did you forward both port 21 and 20 to the real FTP server? Both TCP and UDP protocols? Standard FTP needs 2 ports. I barely remember that port 21 is for commands and port 20 for data.
There is passive mode FTP that allows you to use random ports above port number 1024, and you still needed 2 ports(p, p-1). I seldom used it and am not familiar with it.
I don't know whether the default FTP server of DD-WRT supports passive FTP. But you have the choice to use ProFTPD in Entware, which has a lot of features in addition to passive FTP support.
BTW, some ISPs block FTP and HTTP servers at default ports.
Hi @mwchang - thank you for this information. I ended up upgrading my FileZilla FTP server software - took several years before they finally put an updated release out. It seems to work better and they deprecated implicit TLS encryption. I have considered proFTPd in the past but for simple occasional sharing, I didn't want to deal with all the SSHd PKI etc. stuff (just TLS to secure transport was enough). Everything is working now and I was able to remove a couple forwarding rules in the process (just needed port 21 and my passive port range to be forwarded in the Port Forward rules).
Thanks - I was specifically referring to the 4 year gap from 0.9.6 to 1.0 for FileZilla Server - that is how infrequent I use it and didn't see a need to update until most recently and even in the last year - wasn't much change until the current release where they seem to have "tightened" up the security/feature set - still simple/easy to use though
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Wed Oct 12, 2022 5:26 Post subject: Re: Issue found in port forward rule
jacdc wrote:
Hi @mwchang - thank you for this information. I ended up upgrading my FileZilla FTP server software - took several years before they finally put an updated release out. It seems to work better and they deprecated implicit TLS encryption. ... Everything is working now and I was able to remove a couple forwarding rules in the process (just needed port 21 and my passive port range to be forwarded in the Port Forward rules).
I thank you for your iptables sniffing that led to solving the port-forwarding problem after enabling CTF and/or FA.
Should a button be added in the WEBUI for restarting the firewall? If there was such a button, the port-forwarding mystery with CTF (and SFE?) might have been solved years ago. Other firewall-related problems might have been solved as well. Well.... just a speculation! _________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
Posted: Thu Oct 13, 2022 5:53 Post subject: Re: Issue found in port forward rule
mwchang wrote:
jacdc wrote:
Hi @mwchang - thank you for this information. I ended up upgrading my FileZilla FTP server software - took several years before they finally put an updated release out. It seems to work better and they deprecated implicit TLS encryption. ... Everything is working now and I was able to remove a couple forwarding rules in the process (just needed port 21 and my passive port range to be forwarded in the Port Forward rules).
I thank you for your iptables sniffing that led to solving the port-forwarding problem after enabling CTF and/or FA.
Should a button be added in the WEBUI for restarting the firewall? If there was such a button, the port-forwarding mystery with CTF (and SFE?) might have been solved years ago. Other firewall-related problems might have been solved as well. Well.... just a speculation!
Glad this helped both of us and maybe others that find this thread. I wonder how many others out there have broken firewalls due to that UI change introduced in the last year for netmask. Sure, you should know what you are doing but for most average users creating a firewall rule via the UI... they are not worrying as much about syntax much less how to check if it loaded properly. This firewall restart step probably frustrated quite a few people too trying to get things like Plex with its hairpin NAT (MASQUERADE) requirement to work and not realizing it just took a simple post-startup restart of the firewall service to get working! Seems like a lot of work just to get remote music play to work but that is the price we pay for 'free'.
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Thu Oct 13, 2022 14:40 Post subject: Re: Issue found in port forward rule
jacdc wrote:
This firewall restart step probably frustrated quite a few people too trying to get things like Plex with its hairpin NAT (MASQUERADE) requirement to work and not realizing it just took a simple post-startup restart of the firewall service to get working! Seems like a lot of work just to get remote music play to work but that is the price we pay for 'free'.
We all had our own shares of ignorance and mistakes. It has nothing to do with "free" in my opinion.
Back then ipchains and iptables (NetFilters) were not wrapped as a service. It's an idea pushed by Linux distributions... _________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
