Hardcoded IPv4 PubSubServer IPs

Plex Media Server
, , , , , ,
1

Server Version#: 1.41.3.9314
Player Version#: Web
For whatever reason in Preferences.xml PubSubServer is getting configured as a hard-coded IPv4 address. This is breaking the Plex Scraper in pure IPv6 deployments, if it was entered as an A or AAAA record we could NAT64/DNS64 the A record and make this work in pure-IPv6 environment which is becoming more common. So is there a possibility to make this vairable configurable via the webui or push A/AAAA records instead of raw IPs so we can stop hand-editing the Preferences.xml?

Thanks!

2 Likes
2

No replies? This makes Plex Unusable since it keeps attempting to connect to IPv4 hard coded IPs without any IPv4 addresses on the host.

3

Friend of mine, who streams from me, is also on the same ISP as you are.

He has IPv4 and ipv6

I just texted him to get info about his config

Re Plex Remote Access servers, there are two.

Yes, they are IPv4. Plex doesn’t speak IPv6

https://s3-eu-west-1.amazonaws.com/plex-sidekiq-servers-list/sidekiqIPs.txt

4

I’ve moved over to pure IPv6 with NAT64 so none of my hosts have ipv4 native IPs. This even works for services that are pure v4 e.g. Hulu since the DNS64 nameserver returns a “translated” IPv6 address for dns records that are only A not AAAA. If we could just get these IPs as fqdns instead of raw IPs this would be a non-issue, even as A records.

root@plex:~# dig AAAA plex.com

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> AAAA plex.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32492
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;plex.com. IN AAAA

;; ANSWER SECTION:
plex.com. 600 IN AAAA 64:ff9b::9765:4285
plex.com. 600 IN AAAA 64:ff9b::9765:285
plex.com. 600 IN AAAA 64:ff9b::9765:c285
plex.com. 600 IN AAAA 64:ff9b::9765:8285

;; Query time: 349 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Feb 12 20:56:04 MST 2025
;; MSG SIZE rcvd: 149

1 Like
5

Why are you using plex.com ???
– The domain is plex.tv

My friend tells me to make certain:

  1. WAN DNS is set to a reputable DNS . Do not use “Auto” setting
    (Cloudflare is probably most reputable)

  2. Running IPv6-only is premature. IPv6 is not 100% adoption.

  3. Set SLAAC = 64 on WAN side

  4. On LAN side, for internal use DHCPv6, do not use SLAAC

For testing, I use this site: (I am dual stack here)

6

Yah, I think I’m loosing you, let me try to spell this out further. This is a fundamental issue with the decisions that the Plex Dev team has made and I’m hoping that they can correct this sooner than later.

Problem:
Plex Dev decided to include hard coded IP addresses against software best practices.

Preferences.xml:

PubSubServer="45.33.119.35"
PubSubServer="72.14.179.64"

PMS Log:

Plex Media Server.3.log:Jan 29, 2025 08:15:30.704 [124902394833720] ERROR - [EventSourceClient/pubsub/45.79.23.169:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:15:45.729 [124902394833720] ERROR - [EventSourceClient/pubsub/45.33.125.156:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:16:00.747 [124902399028024] ERROR - [EventSourceClient/pubsub/45.79.23.169:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:16:15.777 [124902399028024] ERROR - [EventSourceClient/pubsub/45.33.125.156:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:16:30.795 [124902394833720] ERROR - [EventSourceClient/pubsub/45.79.23.169:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:16:45.813 [124902399028024] ERROR - [EventSourceClient/pubsub/45.33.125.156:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:17:00.839 [124902394833720] ERROR - [EventSourceClient/pubsub/45.79.23.169:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:17:15.858 [124902394833720] ERROR - [EventSourceClient/pubsub/45.33.125.156:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:17:30.883 [124902399028024] ERROR - [EventSourceClient/pubsub/45.79.23.169:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:17:45.897 [124902399028024] ERROR - [EventSourceClient/pubsub/45.33.125.156:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:18:00.917 [124902394833720] ERROR - [EventSourceClient/pubsub/45.79.23.169:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:18:15.936 [124902399028024] ERROR - [EventSourceClient/pubsub/45.33.125.156:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:18:30.955 [124902399028024] ERROR - [EventSourceClient/pubsub/45.79.23.169:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:18:45.982 [124902394833720] ERROR - [EventSourceClient/pubsub/45.33.125.156:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:19:01.001 [124902394833720] ERROR - [EventSourceClient/pubsub/45.79.23.169:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:19:16.026 [124902394833720] ERROR - [EventSourceClient/pubsub/45.33.125.156:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:19:31.045 [124902394833720] ERROR - [EventSourceClient/pubsub/45.79.23.169:443] Retrying in 15 seconds.
Plex Media Server.3.log:Jan 29, 2025 08:19:46.064 [124902394833720] ERROR - [EventSourceClient/pubsub/45.33.125.156:443] Retrying in 15 seconds.

Environment:
My Plex Deployment has static IPv6 ULA & GUA addresses and no ipv4 addresses utilizing NAT64/DNS64 to access pure-ipv4 services from my pure ipv6 environment (NAT64 - Wikipedia).

2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc fq_codel state UP group default qlen 1000
    link/ether bc:24:11:a5:c8:33 brd ff:ff:ff:ff:ff:ff
    altname enp0s18
    inet6 fdd4:d987:94f1:130::8/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 REDACTED:502::8/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::be24:11ff:fea5:c833/64 scope link 
       valid_lft forever preferred_lft forever

My main client is an AppleTV 4k that also is pure IPv6 and works fantastically. The router (Juniper SRX) & DNS servers (BIND) translate the IPv4 DNS “A” records into “AAAA” records following rfc6146, the IPv4 address gets NAT’d into the 64:ff9b::/96 well known prefix and the application is none the wiser to the fact the service doesn’t support IPv6. This is how Hulu which is IPv4 only works in this environment, and how all other IPV4 only services continue to operate as designed. NAT64 is the future after CG-NAT since it is a lot lower cost to run for the carriers, all low-end virtual hosting environments are moving away from IPv4 due to the costs of the addresses now. Just look at what an elastic IP costs per hour in EC2 now a days and you will see why this is getting popular.

The Solution:
The Plex Dev’s need to get these hard coded IPs out of the code base and replace them with forward IPv4 “A” DNS records inside one of their owned domains e.g. plex.tv. This would allow the NAT64/DNS64 transport to translate it into IPv6 addresses and “AAAA” DNS records like all the other services on the internet. Plex’s infrastructure doesn’t need to support IPv6 for this to work, but it does open the door for an easier migration to IPv6. In the future they can just add AAAA records when they are ready and it would bypass the NAT64/DNS64 translation seamlessly.

Conclusion
Those of us that want/need to run IPv6 networks have found a few devices that have hard coded addresses preventing their operation. This fix should take no longer than a couple hours to create the DNS entries and change the code to reference them instead of the raw IPs which shouldn’t have been there in the first place.

Example from Microsoft → Use of Hardcoded IPv4 Addresses - Win32 apps | Microsoft Learn

Cloudflare DNS64 Page
Google DNS64 Page

1 Like
7

“dynamic”. I got a completely different pubsub IP than you. Unless they only got on ip per. world-region

8

Its “hardcoded” in the sense they use raw IPs, there is a pool of them it rotates through. For this issue if it was one or many it doesn’t matter they are still referencing a raw IP address.

9

Any ETA on a fix for this?

10

@Carbinefreak

First,

The Pubsub addresses were created before IPv6 became “a thing”.
YES, it needs changing.
YES it is changing

To address your, mine, and almost everyone else’s wishes —

Engineering is working on IPv6. Specifically, working on how to address the currently broken NAT64

That said,

  1. I have a friend on the same ISP as you.
  2. Yes, he is IPv6-only
  3. Yes, he can stream flawlessly from my server
  4. Yes, I did setup my server computer to be dual-stack
  5. Yes, my server communicates with Plex’s IPv4 Pubsub.
  6. My Preferences.xml
LanguageInCloud="1" PubSubServer="45.33.72.65" PubSubServerRegion="ewr"

Questions:

  1. Do you have dual stack capability ?
    All modern OS’s are capable and ALL default to IPv6 before IPv4

  2. Does your modem/router handle NAT64 transparently?
    Does the modem/router create an IPv4 LAN with an IPv6 WAN ?

  3. What happens when you remove the PubSub references?
    – What should happen is PMS will not try to connect to a predefined server
    (which it does for speed)
    – Instead, it will go out (the long way) and use whatever the host can provide.

3 ^^ This is where PMS relies on the host IPv6 layer

Please help me understand better so I can advocate better

11

Hey @ChuckPa Thanks for the response, Here’s the responses to your questions. Great news that engineering is looking into better IPv6 support, it will be a hidden benefit for all. Hopefully we can get NAT64/DNS64 support first since its the lowest hanging fruit. All my subs stream without issues even the IPv4 ones which I’ll explain lower this is just an issue with scraping/PubSub’s:

Do you have dual stack capability ?

I pulled it since it was silly maintaining dual stacks across my network, I’m currently running ~16 sites with ~200 /64 subnets so migrating to IPv6 was a much cleaner solution to the mess of RFC1918, IPv4 NAT and IPv6. All of my sites support native Public IPv6 so it was a simple migration especially since I run my own name servers via BIND9. The minimal amount of IPv4 traffic is handled via NAT64 and currently dumps out of my data-center instead of the individual connections to get around carrier CGNAT. Check out my advertised FQDN via dig/nslookup to show what I’m talking about, my IPv4 prefix is not in the same AS as my IPv6 one.

Does your modem/router handle NAT64 transparently?

No, its stateful. I’m currently running Juniper SRX series devices which are built for this. If you want some more info I can share some examples of my NAT64 and NAT46 configurations to “get back” to my IPv6 Plex server via outside IPv4 addresses. Here’s an example like what I’m running, its pretty cool:

Does the modem/router create an IPv4 LAN with an IPv6 WAN ?

No, all my “LAN’s” are pure IPv6 again for ease of management. Its really nice to not have to deal with NAT for most of my flows. Any IPv4 traffic actually originates as an IPv6 flow that the router NAT64’s into a IPv4 flow on egress to the WAN. This is because the applications do a DNS lookup for the IPv4 record and my DNS servers return a synthetic AAAA IPv6 address. The application networking is IPv6 aware so it just uses the address from the DNS record. Notice the 64:ff9b:: prefix signifying NAT64/DNS64.

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> aaaa plex.tv
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16668
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;plex.tv.                       IN      AAAA

;; ANSWER SECTION:
plex.tv.                45      IN      AAAA    64:ff9b::36dc:9c43
plex.tv.                45      IN      AAAA    64:ff9b::22fa:7b37

What happens when you remove the PubSub references?

After pulling the variables in Preferences.xml it attempts to directly connect to a list of IPv4 addresses,which is what I was expecting. I wireshark’d the flow and it appears to connect to pubsub.plex.tv for a list of IPs but since its HTTPs I can’t see what the full request is.

2415	9.983835	REDACTED:502::8	64:ff9b::ac68:da65	CS0	TLSv1.2	402	Client Hello (SNI=pubsub.plex.tv)

Mar 30, 2025 18:00:55.742 [136674134731576] WARN - [PubsubServerManager/process] Connection to 151.236.217.85 failed: Network unreachable.
Mar 30, 2025 18:00:55.742 [136674134731576] WARN - [PubsubServerManager/process] Connection to 139.162.134.185 failed: Network unreachable.
Mar 30, 2025 18:00:55.742 [136674134731576] WARN - [PubsubServerManager/process] Connection to 172.105.203.197 failed: Network unreachable.
Mar 30, 2025 18:00:55.742 [136674134731576] WARN - [PubsubServerManager/process] Connection to 172.104.217.190 failed: Network unreachable.
Mar 30, 2025 18:00:55.742 [136674134731576] WARN - [PubsubServerManager/process] Connection to 172.105.13.59 failed: Network unreachable.
Mar 30, 2025 18:00:55.742 [136674134731576] WARN - [PubsubServerManager/process] Connection to 45.118.132.58 failed: Network unreachable.
Mar 30, 2025 18:00:55.742 [136674134731576] WARN - [PubsubServerManager/process] Connection to 45.33.119.35 failed: Network unreachable.
Mar 30, 2025 18:00:55.742 [136674134731576] WARN - [PubsubServerManager/process] Connection to 45.56.91.127 failed: Network unreachable.
Mar 30, 2025 18:00:55.742 [136674134731576] WARN - [PubsubServerManager/process] Connection to 50.116.44.223 failed: Network unreachable.

This matches what another user was having issues with, even if we could MITM feed a new list of servers or just have a variable we can set via Preferences.xml that would be a HUGE improvement.

12

Looks like PubSub’s are connecting via FQDN now, sometime in the last ~24 hours my server started matching items again in my library. Looks like they are leveraging pubsub00.pop.atl.plex.bz as a test based on the packet captures. Its currently only an IPv4 A record as expected and it resolves properly in NAT64/DNS64. Big thanks to the dev team that did the work on this, it will make it that much easier for the future IPv6 additions/migrations!

root@plex:/etc/netplan# tcpdump "port 443" | grep pubsub
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens18, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:38:51.416315 IP6 pubsub00.pop.atl.plex.bz.https > customer.dnvrcox1.pop.starlinkisp.net.44082: Flags [P.], seq 3507475840:3507475874, ack 173980274, win 13, options [nop,nop,TS val 3927017290 ecr 4000877635], length 34
19:38:51.416420 IP6 customer.dnvrcox1.pop.starlinkisp.net.44082 > pubsub00.pop.atl.plex.bz.https: Flags [.], ack 34, win 1361, options [nop,nop,TS val 4000887633 ecr 3927017290], length 0

root@plex:/etc/netplan# dig A pubsub00.pop.atl.plex.bz

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> A pubsub00.pop.atl.plex.bz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;pubsub00.pop.atl.plex.bz.      IN      A

;; ANSWER SECTION:
pubsub00.pop.atl.plex.bz. 242   IN      A       23.239.17.115

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Apr 01 19:42:22 MDT 2025
;; MSG SIZE  rcvd: 69

root@plex:/etc/netplan# dig AAAA pubsub00.pop.atl.plex.bz

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> AAAA pubsub00.pop.atl.plex.bz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3857
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;pubsub00.pop.atl.plex.bz.      IN      AAAA

;; ANSWER SECTION:
pubsub00.pop.atl.plex.bz. 235   IN      AAAA    64:ff9b::17ef:1173

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Apr 01 19:42:29 MDT 2025
;; MSG SIZE  rcvd: 81
13

@Carbinefreak

It’s all starting to work as it should and is stable ?

Good.

There is more coming.

14

So far so good, time will tell if its stable or not but first looks are in the right direction.

15

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