Attempting to setup Letsencrypt on Unraid server

Hello there!
This has been asked before here http://forum.mikrotik.com/t/new-to-mikrotik-trying-to-setup-portforwarding-for-letsencrypt-nginx-on-unraid-server/132233/1 and I tried following the recommended solutions with no luck, so I would greatly appreciate if you could point to where I might be at fault in my configuration.
I am cross-posting this from the Unraid - Letsecrypt subforum in an attempt to cross-reference any solutions provided. Apologies if this is not allowed.

So… I keep getting “Challenge failed for domain..” in the initial setup validation of Letsecrypt and I suspect I’m messing up with the port-forwarding somewhere along my network.
-Following SpaceInvaderOnes’ guide on Letsencrypt I have http pointing to 180 and https to 1443.
-I have an “obligatory” modem provided by my ISP (Technicolor TG789vac v2) which does not allow/provide an option to switch to bridge mode due to some kind of conflict with VoIP. My port settings are visible in image 1.
-I have a Mikrotik hEX PoE Routerboard with port settings visible in image 2, or as follows:

/ip firewall nat
add action=dst-nat chain=dstnat comment=Letsencrypt dst-port=80 dst-address=!192.168.88.1 protocol=tcp dst-address-type=local to-addresses=192.168.88.88 to-ports=180
add action=dst-nat chain=dstnat comment=Letsencrypt dst-port=443 dst-address=!192.168.88.1 protocol=tcp dst-address-type=local to-addresses=192.168.88.88 to-ports=1443

/ip firewall nat
add action=masquerade chain=srcnat comment=Letsencrypt dst-port=180,1443 dst-address=192.168.88.88 protocol=tcp

Where 192.168.88.1 points to the Mikrotik router and 192.168.88.88 points to Unraid.



Any ideas on where I might be messing up?

Please ask if additional info might be required. Appreciate your time and effort.
Image 1.png
Image2.png

According to picture1 Technicolor already performs port change for HTTP and HTTPS and mikrotik gets hit with requests to port 180 and 1433 while current DST-NAT config on mikrotik expects them to arrive at standard ports…

Changed settings as shown in the image, letsencrypt still comes up with:

Challenge failed for domain .myserver.com
Type: Unauthorized

“To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.” Checked.

When trying to access nginx from outside the network (i.e. nextcloud.myserver.com) a page comes up along the lines of “this page is under construction”.

Also, when attempting to port check ports 80, 180, 443, 1443, the connection is refused on 80/443 and timed out on 180/1443.


Thoughts?
Screenshot (14).png

Of course you must first configure your nginx server so it correctly handles the name-based virtual hosting (i.e. you see the correct page when you access your site).

Did you change anything on Technicolor?

The screenshot you posted shows only part of NAT setting details. Post output of /ip firewall filter export.

Counters show that some connections did hit those rules, which means RB is getting connection attempts.

Does web service (running behind port 180 on internal server) return whatever expected when connected from a PC on same LAN and using LAN IP address in URL bar?

Did you change anything on Technicolor?

No changes here.


The screenshot you posted shows only part of NAT setting details. Post output of /ip firewall filter export.
Counters show that some connections did hit those rules, which means RB is getting connection attempts.


/ip firewall filter
add action=drop chain=input comment="Drop Blacklisted Hosts to Router" in-interface="ether1 - Modem" \
    src-address-list=BlackList
add action=drop chain=forward comment="Drop Blacklisted Hosts through Router" in-interface="ether1 - Modem" \
    src-address-list=BlackList
add action=add-src-to-address-list address-list=BlackList address-list-timeout=1d chain=input comment=\
    "Blacklist Brute Forcers" dst-port=21-23,53,88,135-139,389,445,1433,3306,3389,5900,6667 in-interface=\
    "ether1 - Modem" protocol=tcp
add action=add-src-to-address-list address-list=BlackList address-list-timeout=1d chain=input comment=\
    "Blacklist UDP WAN DNS Lookups to prevent DDoS" dst-port=53 in-interface="ether1 - Modem" protocol=udp
add action=add-src-to-address-list address-list=BlackList address-list-timeout=1d chain=input comment=\
    "Blacklist Port Scanners" in-interface="ether1 - Modem" protocol=tcp psd=21,3s,3,1
add action=add-src-to-address-list address-list=BlackList address-list-timeout=30m chain=input comment=\
    "Blacklist SYN Flood Attacks" connection-limit=30,32 in-interface="ether1 - Modem" protocol=tcp \
    tcp-flags=syn
add action=accept chain=forward comment="Accept established,related" connection-state=established,related
add action=accept chain=input comment="Accept ICMP, prevent flood" icmp-options=8:0 limit=1,5 protocol=icmp
add action=accept chain=input comment="Accept established,related" connection-state=established,related
add action=drop chain=input comment="Drop all from WAN" in-interface="ether1 - Modem"
add action=drop chain=forward comment="Drop invalid" connection-state=invalid
add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=forward connection-state=established,related



Does web service (running behind port 180 on internal server) return whatever expected when connected from a PC on same LAN and using LAN IP address in URL bar?

If I understand correctly, directly entering the LAN IP address of the plex docker service (i.e. http://192.168.88.88:32400) does indeed return the expected web page.

First of all a comment: firewall rules make lots of fuss about preventing some users from accessing any service behind firewall while it allows just anything to all others (remember that implicit ultimate rule in any chain us allow).

Second: I’m lost in what you actually want to achieve … you’re mentioning tcp port 80 on wan, you configured Technicolor to (un-necessarily) perform port translation, your NAT rule on RB tries to translate it again (but it can’t because Technicolor already did it) and when I asked if internal service on destination port works, you mentioned a completely different port (HTTP on port 32400).