Port 443 port forward

Port 443 is not on the latest AT&T list of blocked ports  so there must be something else going on there.  Given the nature of your setup I wouldn't know where to start troubleshooting.

The most obvious thing, you've already covered... the management port for the U-verse TV WAP.  Is the device already there and listening on port 443?

I have similar issue and I believe ATT and something setup in the residential gateway that use port 443.  So basically any 443 traffic from outside will not reach to my home router.   I check what router's external IP,  check port 443 from outside ( using my phone without wifi ) on my internet IP and found a webserver was running .  this little webserver has an invalid certificate.  

First I would never use the ATT router for anything other than a bridge. The ATT router does not care. Remember, it is just TCP Traffic.

You must pay for a public IP range from ATT. Build the subnetted traffic block. Assign the IP to your cascade router thru DHCP. At that point you will disable the firewall for the cascade router.

When you check your facebook, log into web mail for example, any outbound HTTPS is using 443. A tunnel is setup back to your PC Browser on a random port from 20000 to 65000. Remember, the device on the inside leaves on 443 but the return port will be randomly  negotiated back.

If you have a device on the inside trying to leave over 443 it is no different than checking your web mail and the router does not care about the man on the inside, unless, you start building NAT rules. Same thing with any other protocols. HTTP port 80. Same thing. Return port is random.

 Better put, imagine an office with 100 employees. They all rush to check their facebook account. It is an HTTPS port 443 request leaving times 100. The return ports will be random. If you were to build a NAT rule for 443 outbound you would de-rail all 443 traffic.

If you have a server behind the cascade router which you are setting to be accessed via HTTPS, then a NAT rule in the cascade would have a any 443 rule pointed to the server for inbound requests only. If the server is trying to request a cert outbound to a HTTPS location for initial setup and there are issues, you have configured rules incorrectly or have an issue at Layer 7 not Layer 3.

If you had a business class cascade router you would be able to see and understand TCP / UDP traffic. You would see, you do not setup NAT rules for that. Setting up NAT will corrupt that traffic if you do not know what you are doing.

Lastly, if you are operating traffic at Layer 2, you need only input into a browser the ip followed by :443 or begin with HTTPS://. However, within an application server you do have the ability to change SSL to be any port. So you could actually setup SSL on port 26000. This actually increases security.

Another consideration is, inbound 443 requests will first be examined by the first gateway. So if you have a cascade router and you have not changed the SSL port to something random like 6443, then it will examine and route 443 traffic to the gateway interface for authentication and NAT rules will be considered a conflict.

Purchasing public IP's and assigning to a cascade router is the option.

Purchasing public IP's and assigning to a cascade router is the an option.

FTFY.  The rest of your post won't be understood by those who are not already technically competent in the area.

My point exactly. If you did not understand it then stay out of it. Hire a professional.

  I do not know how to fly a plane even though I have a PS4 with an airplane game and I would never attempt it...LOL. That is why there are professional pilots and they get paid for their knowledge.

  I am a CCNA and a network engineer. I get paid for that.

I don't want to get started on a p!$$!ng contest here, Litecomman.  Several points within the above post make me severely question your understanding of networking (including what layers are responsible for what) while several others are well taken. I'll leave that there.

Your first post in the forums is about as close to a SPAM post as can be tolerated here, to paraphrase "you need professional help, here's my website, pay me to get it."

Beyond that you seem to constantly try to make things seem more complicated or expensive than they have to be and recommending expensive enterprise gear that requires expensive contractors to configure for them.

I have a NVG599 and a BGW210. Both are in IP passthrough to a downstream router. I'd go through the following:

1) configure SSL using a self generated cert and get the site up and running. Let's encrypt is fine, but no need for testing.

2) verify you can connect to it locally using the LAN ip address. You will have cert errors because either it is self signed (not trusted) or access via IP which will not match the common name on the LE cert.

3) assuming above works (Nginx is listening), now work on port forwarding.

4) possible that the RG is doing some kind of packet filtering, so either turn it off or add a filter to specifically allow incoming on 443.

Full disclosure, I'm only running a SSL webserver behind the NVG, but I may try one behind the BGW210 for fun. Also, IP passthrough is different from your situation.

And I'm not sure litecomman knows what he's talking about. Absolutely no need to buy an address block.

For fun, IPv6 could be used easily (mine is available on both 4 & 6).

@Litecomman your solution sounds very... not home server oriented like the original poster was talking about. like we are ALL talking about. im trying to host a small little webserver for personal use only... i dont need a static public ip address to do that. just a little domain redirect from from my domain registrar to my current public ip and im good. my public ip though not static, hasnt changed in like 5 years. so static ip isnt needed. and if does change, i know its dynamic, so thats on my top 10 things to check.

and WHY ARE YOU TALKING ABOUT 443 OUTBOUND???? 
the rest of us are talking about 443 INBOUND. (again the little home server)

looks like in your rant you FINALLLY get to 443 inbound but your talking about NAT... im at a loss man, why are we talking about NAT? it has literally nothing to do with the topic. forwarding INBOUND port 443 to a home server. or a cascaded router, which is forwarding port 443 to the said server, with ippassthrough to the cascaded router so the router looks like it has the public ip address to make many things easy.

both ways this is setup, port 443 inbound does not route the traffic to the home server. THIS is the real problem. not nat. not anything else. THIS. all other known not blocked ports are free and open and work. some things... like cloudron, dont like changing ssl ports. so 443 is the only way to go. but how do we solve this widespread issue? some say factory reset works, some say it doesnt. who really knows at this point. im attempting a factory reboot tonight. wish me luck.

factory reset of the gateway worked. i am now finishing the setup of my cloudron server. (for anyone interested in what worked for me)