Background:
Proxmox node hosting an Ubuntu VM. VM hosting Docker.
Docker has several Containers inc nginx, traefik, cloudflare, portainer.
Traefik Dashboard is free of errors. Local settings / results:
PiHole used on LAN for recursive DNS.
Local DNS entry for domain ‘test.’ in PiHole pointing to VM’s IP.
Nginx web directory has a simple ‘Hello’ style
entry.
Browse from PC on LAN to test. works perfectly.
External settings / results:
Static IP from ISP.
Domain registered with Cloudflare (CF). ‘A’ record in CF to static IP.
Traefik gets certificate from Let’s Encrypt with API from CF.
Mikrotik RB4011 has dst-nat entries for port 80 and 443 from WAN pointing to VM’s IP.
Also have a F/W Forward Filter rule to accept ‘Connection NAT state’=dstnat where IN Interface = ether1 (WAN)
Browse from phone on mobile network (to simulate external call) using test. results in Error 522, meaning everything worked as expected until the target server (nginx in my case) timed-out (or failed to respond).
Checking the Bytes field on the Tik shows nil received in the dst-nat entries - which is where I would have expected to see activity inbound from CF.
Checked with ISP support this morning - they swear blind that no ports are blocked.
Grateful for any tips on next place to look / test.
For context, I’m following along the YT videos from @Jims-Garage myconfig.rsc (15.9 KB)
Shame is on you default MT config includes such a rule, so it was your doing to remove it (I’m guessing all default config).
If everything is empty, then FW will pass NAT-ed traffic. But when one starts to restrict traffic from internet to LANs, one has to consider also NATed traffic, it’s not admitted just because there’s a NAT rule. And sometimes that’s good: NAT rule restrictions are not really fine-tunable (one can create multiple NAT rules though), so ability to fine tune access to NATed ports using firewall rules comes handy if such need arises.
Guilty as charged I guess
Been a few years since I started with the Tik and I didn’t have Port Forwarding on the radar initially, so I probably removed that filter.
I was surprised that adding the filter didn’t seem to have an immediate effect - but it was late yesterday when I added it, and I may have made a slight tweak which then opened the way.
It’s typical that changes in firewall filters might not have immediate effect as they only affect new connections. But that explains only connections which were already established at time of firewall filter changes. You added a filter which should allow new connections and tried with new ones, so the observation mentioned in previous sentence should not apply. And I’m not aware that firewall would cache blocked connections (which would explain behaviour).
Anyway, the wisdom goes that if some setting doesn’t seem to have effect (firewall filter, L2 settings, etc.), rebooting device often fixes that. It’s not necessary very often, but it does make a change once in a while.
default MT config includes such a rule, so it was your doing to remove it (I’m guessing all default config).