Compatible ports issue

I have set up a proxied A record for a subdomain of
https:// router. exampledomain .com

I am using OpenDNS’ “DNS-o-matic” to update my ISPs dynamic IP in Cloudflare and it’s working properly and assigning the correct IP to the A record.

Visiting the url of https:// router. exampledomain .com should be loading the login screen for my router. (My router’s default admin user is disabled, I have a very strong password + I have 2FA enabled.)

According to Cloudflare’s doc here I need to be using a port that’s compatible with CF’s proxy so I updated the router to run its web interface off of ports 8080 for http and 8483 for https instead of its defaults.

Despite this change I still get an origin unreachable (523) error when trying to visit https:// router. exampledomain .com

If I visit the external IP directly at: https:// The web interface for my router loads as expected without any issue.

What am I missing here?

(I have read this article.)

  • Cloudflare Ray ID: 7d60055fcff3eb63

8443, not 8483.

1 Like

That was a typo on my part. Confirming I’ve corrected the https port that my router’s web interface runs off of and restarted the service. Problem persists as before however.

If I visit the external IP directly at: https:// The web interface for my router loads as expected without any issue. (Mind you the SSL cert. is flagged by my browser as untrusted.)

You will want to fix that. Using a free automated certificate authority like Let’s Encrypt or a custom certificate from the Cloudflare Origin CA are good methods to employ a certificate that will be trusted by the Cloudflare proxy.

1 Like

My existing cert. is issued by Cloudflare and covers *.exampledomain .com with Cloudflare set to “Flexible” mode.

A self-signed cert is also on the router for exampledomain .com

That means that you have no security whatsoever. You absolutely must have a certificate on your origin server or you are just fooling yourself. It clearly states in your screenshot that it leaves the connection to your origin device unprotected.


Does it work with plain HTTP on port 8080?

The self-signed certificate covers the hostname, not just the root domain, right? Can you use a Cloudflare origin certificate instead?

It should still load though, right?

Not necessarily. What port do you expect Flexible to make its HTTP connection to the origin on when it was accessed on 8443 at the edge?

I am with @sandro when it come to avoiding Flexible at any cost. It should really should have been removed from Cloudflare altogether along time ago, and I would even argue that its introduction was a colossal mistake. It has done far more damage to the overall security of the internet than whatever slight perceived benefit it supporters imagine that it has contributed.


Oh, good point. I’d expected it to use 8443, but with Flexible, why would it?

Yes, I think an Origin Certificate and strict mode are needed here.


It redirects to https as per a setting defined on my router. “Automatically redirect http connections to https.”

As a test I changed that setting, disabled HSTS, and tried again in an incognito window. I’m still redirected to https however so there must be something with that redirect being cached somehow somewhere.

I set a Cloudflare “Configuration Rule” for the SSL:
“if ‘hostname’ contains ‘router’ then SSL/TLS encryption mode: ‘Strict’” and tried again but there was no change. I also tested via to make sure it wasn’t just me.

I THOUGHT it did but after running a scan with just now on both https:// & I can see:

  • hostname/cloudflare cert = Valid for the root domain + any subdomains
  • IP/self-signed cert = Valid for the root domain only. < facepalm > (Doh!)

I guess it’s clear I need to generate a new self-signed cert for my router than includes a wildcard. I will try that and report back. I suspect that will solve everything.

I’m curious to learn more about this because it seems you know what you’re talking about but it’s contrary to what I believed previously. My understanding was that the only unsecured bit would be the connection between Cloudflare’s proxy servers and the origin server (Which didn’t seem terrible.).

I’ll read the article you linked to.

1 Like

Created a new self-signed certificate that includes * in addition to the root domain.

I put Cloudflare’s SSL configuration rule into “Full” mode for the router subdomain as opposed to “Strict” mode since that’s required for self-signed certs.

No change. (Sigh)

These are my router’s SSL cert generation options:

And this is what happens if I try to create one using LetsEncrypt as opposed to self-signed. (Which I tried next.)

My current DDNS settings:

Guess I’ll have to come back to this problem tomorrow as it’s getting late.

That’s the precise issue, a self-signed certificate can never secure your site, as long as you do not control the trust store. As already pointed out, you first need to fix your security issue and configure a proper certificate.


Option 2 in your first screenshot allows you to create a CSR for use with an external CA. You can use that to obtain a Cloudflare Origin CA certificate. It will allow Cloudflare to connect securely when set to Full (Strict), but is not recognized by web browsers. You will need to ensure that you route your local connections through Cloudflare to avoid an unknown issuer warning.

1 Like

Curiously if I visit my router’s admin interface loads ok over https. Just need to get rid of that port number.

Anyways… back on track.

I created an origin cert in Cloudflare at SSL/TLS > Origin Server that covers *, and then imported it on my router.

I then changed my CF configuration rule so that the subdomain uses the mode “Full (Strict)”.

No change to my issue though unfortunately.

I just double checked my port forwarding settings and found that my port forwarding settings weren’t what I believed they were. I fixed them and now everything is working.

Thanks for your help guys!


This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.