New Member
•
3 Messages
Unable to forward port 443 on Pace 5268AC
I'm trying to setup a web server at home for fun and games. A normal HTTP server on port 80 works fine. However, I setup a redirect to HTTPS on port 443, but the gateway does not allow me to forward that port. It tells me:
The port 443 in the service conflicts with the device managed port 443.
When I enable "DMZ plus" or "IP passthrough" to the server, port 80 still works fine. In fact, it returns a redirect to port 443, but when the browser connects to port 443, it gets a broken TLS cert and an empty http body.
Port 443 is not one of ATT's "special ports" that they block, so there should be no reason this is failing.
I read online that factory-resetting the gateway can fix this, so I tried that. I reset the gateway, reconfigured my wireless network, re-enabled the "DMZ plus" thing to point to my server, and the HTTP/HTTPS redirect worked correctly!!! ...for about a day. When I checked the next day to work on the server, the same "redirect, broken cert, empty body" problem was happening. I know it's not my server, because when I change the DNS record to point directly to the local IP address instead of my public one, everything works great consistently.
I checked everywhere I could, and there seem to be no clear solutions. It is clearly a recurring problem though:
- https://forums.att.com/conversations/att-internet-equipment/opening-ports-80-and-443/5defef81bad5f2f60603854c
- https://forums.att.com/conversations/att-fiber-equipment/port-443/5df01162bad5f2f60648d0aa
- https://forums.att.com/conversations/att-fiber-equipment/port-443-port-forward/5ef8a584c17a0641f8e1d81e
- https://forums.att.com/conversations/wireless-account/the-port-443-in-the-service-conflicts-with-the-device-managed-port-443/5fa37c4472a09d24e1c2d28f
We have both fiber internet service and Uverse tv service, including a few wireless tv boxes. Here is the gateway information:
| Manufacturer | Pace Plc |
| Model | 5268AC |
| Hardware Version | 260-2173300 |
| Software Version | 11.8.1.533225-att |
Accepted Solution
Official Solution
JefferMC
ACE - Expert
•
32.3K Messages
2 years ago
UverseRealtime requires that you have one of the original 2WIRE Gateways (3600, 3800, 3801) and doesn't work with the currently supported equipment (589,599,5268,210,320). It also has to be run in Administrator mode for full functionality. And, well, even if you had the right gateway, some of the stuff won't work without metadata that SomeJoe7777 quit updating years ago.
It could tell you stuff like what channels were currently tuned, it would read the frequency bands that the Gateway was using to talk to the AT&T network, how much data you'd pushed and pulled through the Gateway. It was pretty cool.
What I remember is that if you had a Wireless Receiver, then the Gateway would reserve 443 for external management of the WAP and while you could temporarily port forward it somewhere else, your settings would mysteriously disappear within 24 hours. I've never heard that they quit doing this. So your options are:
(1) Use some other external port,
(2) Get a public static block of 5 IPs (for a monthly fee of I think $15),
(3) Get rid of the wireless set tops and WAP, or
(4) Switch to some other Internet provider.
(edited)
0
0
my thoughts
Former Employee
•
20.5K Messages
2 years ago
To my knowledge the UVERSE WAP (model 401, 501 or 2500) uses port 443 to communicate with the wireless receivers.
See some of SomeJoe7777 replies from several years ago...
https://forums.att.com/conversations/att-internet-features/forwarding-port-443-for-whs-conflict-with-connecttociscoap/5deff245bad5f2f606350aa2
SomeJoe7777 is no longer on the forums... but when he was active had some great information including writing a software program to see gateway data in a nice format... UV Realtime....
http://www.uvrealtime.com/about.aspx
0
0
bobfred
New Member
•
3 Messages
2 years ago
Interesting, thanks for pointing me there, @my thoughts. I had seen that title but didn't think the information from 2012 would still be relevant, considering how many gateway hardware lifecycles there have been. After skimming that old thread, it seems like that "wireless set-top box management" protocol on port 443 is the issue.
Is it really still the case that ATT uses port 443, literally one of the most common ports on the internet, for their obscure wireless IPTV receiver management system? Would the port still be "reserved" if I moved all our STBs to ethernet/cat5?
I'll look into that uvrealtime program. It looks interesting, but I'll have to spin up a VM since it doesn't accept the newest winpcap drivers that Wireshark uses. What exactly would I expect to see there that would help?
0
0
my thoughts
Former Employee
•
20.5K Messages
2 years ago
UVRealtime was designed for the 2WIRE gateways, from memory I believe it also worked for the first ATT Bonded gateway the 3812 iNID.... seem to recall seeing some graphs but could be wrong.
2WIRE was purchased by PACE.... thus the 5268 is the bonded pair successor to the 3812.
The other manufacturer of ATT gateways was MOTOROLA (510). Motorola was purchased by ARRIS which includes the 589, 599, 210, 320. While the 210, 320 are BGW instead of ARRIS and seem more like DirecTV wireless router 210-100 Genie Router (the ATT 210-700 came out 2 years after ATT bought DirecTv, and the 210-700 uses a DTV power supply rebranded) the manufacturer is ARRIS.
(edited)
0
0
bobfred
New Member
•
3 Messages
2 years ago
That's very interesting. I ran the UVRealtime and it actually connected to my PACE 5268AC when I specified the IP address manually. It seems like a few features no longer work, but it still had some neat diagnostic information.
Unfortunately, that doesn't help with the predicament on port 443.
@JefferMC (comment), it seems like my end-game will be getting all the STBs either on wired ethernet or just drop the Uverse TV altogether. For now, I've setup a proxy for port 4443, which breaks some of the redirecting when people's browsers point directly to "https://mydomain.com" but I guess I have to live with it.
Can anyone confirm that getting all the STBs on wired network will solve this?
0
0
JefferMC
ACE - Expert
•
32.3K Messages
2 years ago
I'm not sure what actually triggers the Gateway's behavior with respect to port 443, whether it's a setting on your account or the fact that there's a WAP squawking in your network. You could try unplugging the WAP, rebooting the Gateway and setting it back up and see if it holds. Obviously that would mean that none of your wireless Receivers would work for the 24-48 hours it would take to conclusively test.
0
0