I finished the Certbot process successfully (and foolishly selected to reroute HTTP traffic to HTTPS), but my site now does not load, although it can still be accessed by navigating to the naked IP address (167.172.248.24), which seems indicate that nginx is running at least somewhat successfully.
It also sounds like similar issues are often caused by the firewall, but I’ve made a ufw exception for both port 443 and nginx HTTPS traffic. Here’s the result of ufw status:
Excellent, that’s good to know. It seems more likely that it’s a routing problem to me, any idea whether this would be an issue with the nginx sites-available config file?
It looks like my Digital Ocean cloud firewall is not turned on. When you’re wondering about those rules being duplicative, are you concerned that having both standard and (v6) rules could be an issue? Or that having both nginx HTTPS and port 443 rules could be an issue?
Yeah, you can even navigate to the site successfully using that naked IP address in an address bar.
The following:
# Generated by iptables-save v1.6.1 on Fri Jan 3 19:48:32 2020
*nat
:PREROUTING ACCEPT [1153:59466]
:INPUT ACCEPT [148:8078]
:OUTPUT ACCEPT [61:3946]
:POSTROUTING ACCEPT [61:3946]
-A PREROUTING -d 167.172.248.24/32 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 9192
COMMIT
# Completed on Fri Jan 3 19:48:32 2020
# Generated by iptables-save v1.6.1 on Fri Jan 3 19:48:32 2020
*filter
:INPUT DROP [627:32287]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -m comment --comment "\'dapp_OpenSSH\'" -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 3000 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 3001 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 8080 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 80 -m comment --comment "\'dapp_Nginx%20HTTP\'" -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 443 -m comment --comment "\'dapp_Nginx%20HTTPS\'" -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 443 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 443 -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
# Completed on Fri Jan 3 19:48:32 2020
Thanks for the clarification. Unfortunately removing either of these doesn't resolve the issue; removing the 443 rule does seemingly nothing, and removing the nginx rules (I tried removing both HTTP and HTTPS) no longer serves the site on HTTP.
@JuergenAuer Any idea what the firewall or blocking instance could be? UFW seems to be configured to allow HTTPS traffic and port 443 traffic, but I tried disabling it entirely and accessing the site via HTTPS still doesn’t work.
There's a rule in the nat table redirecting port 443 to port 9192. So the traffic is getting blocked because there isn't another rule allowing port 9192. Additionally, since Nginx probably isn't listening on port 9192, that probably wouldn't work anyway.
Your site will likely start working if you delete the NAT rule.
Do you remember what it was created for? If it was being used for something, you might need to do something to fix whatever that was.
Excellent catch @mnordhoff, I didn’t see that rule related to 443 redirecting at all! The Digital Ocean droplet I’m using is very new and hasn’t been customized hardly at all, so I have no idea where that NAT rule could have come from. I’m trying to remove it now, but I’m having a hard time seeing how I identify which NAT rule contains the redirect, is it part of the POSTROUTING rule on the previous line? Thanks!
Just before receiving your message I just removed the rule with:
sudo iptables -t nat -D PREROUTING 1
And that solved the issue! I’m extremely grateful for your help. I’m also curious whether there’s something that will re-emplement the rule on reboot, like you wondered. I’m going to try to reboot now and see what happens.
Edit: Even after rebooting, the site is still correctly served using HTTPS. Success!