Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
OK, I was able to connect to the router just now. So, you’re running these commands directly on the router? Could you try just leaving iptables in a state where the public can connect and running the acme.sh command without the iptables part?
To protect connections on port 443. (Your router doesn't have to accept connections on port 80 at other times, but they can't be blocked by a firewall during renewal.)
You can also now use port 443 instead of port 80 if you get a Let's Encrypt client that supports the new TLS-ALPR-01 validation method (I don't think this is true of acme.sh or Certbot yet, and I'm not sure if it's true yet of any client that can run on your device).
I don’t quite understand this, because earlier you said that the problem with issuing your certificate was that port 80 was blocked, and that you were able to do something to unblock it in order to issue the certificate. What did you have to do? Why can’t you do it again?
Interesting! Does DDWRT have a support forum where you could ask what the effect of that configuration setting is? Maybe it does have a command-line equivalent that the DDWRT community could point out for you.
Well, I would ask the DDWRT community what the exact effect of that setting is so that you can either make it permanent (without having negative effects that you don’t like) or script it from the command line (so that you can do it temporarily for certificate renewals).
...which would include opening port 80 on your DDWRT router, which we don't have any experience with. So in the end, you'll probably need to search for or ask the DDWRT community on how to do that. And include that script in the renewal script.