Well, this is going to take 15-30 minutes to check...   Port blocking was "off" in my management console... but I am wondering if it was not really off, so I have toggled the setting... will wait 15 minutes adn test and then if that fails, toggle and test agin 15 minute later.   @david64Many thanks for the assistance anyway... if it is this as a problem, then I'm not a happy camper as I am sure that I'd disabled the port blocking previusly and somehow it got re-enabled.   Ady ... View more

Hi @david64    OK... I've just set up a no-ip DDNS resolver and set up on the router... The No-IP Site cannot reach port 80 nor 443, and it is suggesting the ports are blocked at the ISP.   Grumbles...   ... View more

Hi @david64    Thanks for the response... here's the details I think you'll need to help resolve the problem.   DMZ I use a DMZ because I want to isolate the communication from outside to a single "host". This is the only option I have for restricted access using the TPG Firmware. The TPG router does not allow for the DMZ to be on a separate private network (grumbles) so it's not really a true DMZ configuration, in my limited opinion (IMLO).   WAN I am using DDNS (duckdns/dynu/etc), to provide an A record for the router. I am running a script that updates the DDNS every few minutes.   LAN Turned off DMZ temporarily, tested... Re-enabled and tested... no changes. Virtual Server ports mapped (WAN --> LAN): 80 --> IP Address 80/TCP 80 --> IP Address 80/UDP 443 --> IP Address 443/TCP 443 --> IP Address 443/UDP Screenshot: I know the UDP isn't needed on port 80, it is for HTTP/3 on port 443. Will be removing the 80/UDP / Have disabled it.   Internal Reverse Proxy NOTE: I creasted a throw-away DuckDNS entry for testing (dyno-test.duckdns.org) which I'll kill once this is working. Running on the targetted host (localhost/192.168.1.139) HTTP response working External HTTP request (Phone, no WiFi), Fails This leads me even more to wondering if the problem lies at the Firewall/Modem.   Interesting... Ady   ... View more

@david64    I posted a reply last night, but it's gone missing... I'll respond again in a while... need to collect all the information again (ARG!).   Ady ... View more

Hi @david64    OK, here we go, more details on the forwarding issues... But I'd still like to know about updated firmware :-D   LAN - Host has fixed LAN IP address (w.x.y.z for arguments sake) - Host resolves the external IP (dig magic-roundabout.duckdns.org) - Host updates DuckDNS address automatically - Running Caddy for a reverse-proxy - Caddy will be issuing LetsEncrypt (ACME) certificates for SSL/TLS access on port 443.   Router - Disabled the DMZ - Port Forwarding configured   - External 443/TCP --> w.x.y.z:443   - External 80/TCP --> w.x.y.z:80   - External 443/UDP --> w.x.y.z:443   DuckDNS - magic-roundabout.duckdns.org - Host running an automatic update script for the external IP - nslookup.io on phone, disconnected from LAN, resolves the A record   DMZ: - I was trying to ensure a bit more "restriction" on the traffic from outside to these ports going to the Host only. - The router does not have a proper DMZ feature that allows for a new network (eg 10.0.0.0/24)   I have had varying success with the access to magic-roundbout.duckdns.org using: - http://magic-roundbout.duckdns.org - has worked - https://magic-roundbout.duckdns.org - never worked   The problem arises in that the request for an SSL to be issued from ACME times out as it appears that the call to the resolved external IP fails to be let through correctly. Error given: caddy | { "level":"error", "ts":1704468372.6744535, "logger":"tls.obtain", "msg":"could not get certificate from issuer", "identifier":"magic-roundabout.duckdns.org", "issuer":"acme-staging-v02.api.letsencrypt.org-directory", "error":"HTTP 400 urn:ietf:params:acme:error:connection - 106.69.186.120: Timeout during connect (likely firewall problem)" } Hope that gives you enough details. Ady     ... View more