Plex uses wrong interface / messing up ip

I’m running on Ubuntu server, with OpenVPN (yes, the only way to get open ports for me).

So my issues is;

  1. tun0 isn’t available in the settings, only enp0s3 (yes, virtual box)
    so why isn’t tun0 available?

  2. according to Plex remote access page, it’s routed:
    192.168.0.199 217.256.256.256

But! 217.256.256.256 is my external ip (tun0), so why is Plex trying to go that way? my external ip to my local ip?

there must be some way to force it to use tun0? or fool to think it’s accessing 192.168.0.199:32400 but are really using 217.256.256.256:32400 instead?

Please do the following:

Verify DEBUG logging is enabled, VERBOSE logging disabled.
Restart Plex
wait 3 minutes
Download the logs ZIP file
Attach it please so I can see what it’s doing.

I am confused though – PMS in a VirtualBox VM on LInux?
VirtualBox is costing you all kinds of performance because of the type hypervisor it is.

Had to link to the file, the upload didn’t work here…

system & server log

Well, the host is actually windows 10, running virtual box with Ubuntu server yes, haven’t had any issues previously, but it’s only used for the family, so it works fine. now I’ve reinstalled it on my server VM, and that’s running with VPN (so I can have open ports), and that doesn’t seem to be working with Plex

Normal here except for seeing a public (WAN) IP as the primary interface
when

Jan 02, 2022 18:43:05.355 [0x7f7502633b38] DEBUG - HTTP requesting GET http://plex.tv/pms/:/ip
Jan 02, 2022 18:43:05.356 [0x7f7506b50b58] DEBUG - Detected primary interface: 217.xxx.xxx.xxx
Jan 02, 2022 18:43:05.356 [0x7f7506b50b58] DEBUG - Network interfaces:
Jan 02, 2022 18:43:05.356 [0x7f7506b50b58] DEBUG -  * 1 lo (127.0.0.1) (loopback: 1)
Jan 02, 2022 18:43:05.356 [0x7f7506b50b58] DEBUG -  * 2 enp0s3 (192.168.0.199) (loopback: 0)
Jan 02, 2022 18:43:05.356 [0x7f7506b50b58] DEBUG - Creating NetworkServices singleton.
Jan 02, 2022 18:43:05.356 [0x7f7506b50b58] DEBUG - NetworkServices: Initializing...

Did you alter the “Detected primary interface” line?

Not here

Jan 02, 2022 18:43:15.197 [0x7f75018afb38] DEBUG - HTTP/1.1 (2.5s) 200 response from POST http://127.0.0.1:32600/devices/discover
Jan 02, 2022 18:43:15.358 [0x7f7501a7fb38] WARN - NetworkServiceBrowser: Error sending out discover packet from 192.168.0.199 to 239.255.255.250: Operation not permitted
Jan 02, 2022 18:43:15.360 [0x7f7501c59b38] WARN - NetworkServiceBrowser: Error sending out discover packet from 192.168.0.199 to 192.168.255.255: Operation not permitted
Jan 02, 2022 18:43:15.360 [0x7f7502582b38] WARN - NetworkServiceBrowser: Error sending out discover packet from 192.168.0.199 to 192.168.255.255: Operation not permitted
Jan 02, 2022 18:43:15.627 [0x7f7501869b38] DEBUG - Grabber: Cleaning up orphaned grabs.

Is this configured as a peer / bridge to the host?

It you use VirtuaBox, your best networking behavior is obtained when the VM appears on your LAN as if another computer.

If it’s NAT, you get a whole world of hurt applied.

Hi!
thx for helping.

yes, primary interface are really showing my tun0 ip address, the open ip

The VM is using bridged network, so it has it’s own ip in the router (enp0s3 192.168.0.199), but my firewall on Linux is set to block enp0s3, because everything should go via OpenVPN (tun0), and everything else on the server is working flawless (irc, apache2, samba, ssh,ziproxy)

If you really want Plex to go through the VPN (tun),

you must manually write static routes to direct it first.

After those static routes exist then restart plex.

Plex doesn’t know about firewalls.

I almost suspected that since tun0 isn’t in Plex settings (only enp0s3), but I assumed that Plex, like all other apps, takes the “normal” route, and if I’m not mistaken, when OpenVPN is active, it should be the “normal” route?

I have NO idea how to write static routes, I guess iptables (no, I’m not using netplan, it’s not made for humans) do you know how?

Not iptables — that’s your firewall.

route - is how you add routes
netstat -rn is how you look at what your routes are

If you look at the typical host installation,

  1. It finds the first adapter
  2. DHCP usually gives it an ip address AND a default gateway (forwarding) IP.
  3. from this info, the default route is created (netstat -rn will confirm this)

Think about what’s happening here.

You want to replace the default route interface with the tun0 interface.

You’ll need to do a couple things.

  1. First add a route to give your default ethernet adapter a route to your subnet for administration

  2. Next you’ll want to delete the default route (which removes external connectivity)

  3. lastly, you’ll want to add the local side IP of your tun0 adapter (gained from netstat -rn with the tunnel up) as the default.

while this is mine, it’s similar concept.

My default adapter is bridged which allows multiple LXCs to run.

[chuck@lizum ~.2000]$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 br0
172.16.216.0    0.0.0.0         255.255.255.0   U         0 0          0 vmnet8
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 br0
192.168.0.1     0.0.0.0         255.255.255.255 UH        0 0          0 br0
192.168.64.0    0.0.0.0         255.255.255.0   U         0 0          0 vmnet1
[chuck@lizum ~.2001]$ 

I use br0 and not enp12s0 (which is the physical adapter)
I have kept my LAN gateway device as forwarding IP.

EDIT: Use code formatting </> button :wink:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0            217.xxx.xxx.x    128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s3
128.0.0.0       217.64.xxx.x    128.0.0.0       UG        0 0          0 tun0
192.168.0.0     0.0.0.0         255.255.0.0     U         0 0          0 enp0s3
217.xxx.xxx.xx   192.168.0.1     255.255.255.255 UGH       0 0          0 enp0s3
217.xxx.xxx.0    0.0.0.0         255.255.255.0   U         0 0          0 tun0

(not as nice formatted as yours), but the first one seems to be going to the ovpn router

you have two gateways (“G”)

that’s why Plex is finding its way out 192.168.0.1.

also set metrics (costs). Make it “cheaper” to use the tunnel adapter

you still have them all with zero cost.

ok, though it would go thru the first…
now I’m completely rookie at this, how to set metrics?
I assumed OpenVPN would have set this automatically

I “can’t” just remove the 192.168…1 gateway since OpenVPN needs it (I guess),

tunnel adapter? make it cheaper how @ChuckPa ?

Your routing table shows the VPN routes are split into two 128.0.0.0 networks:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         217.xxx.xxx.x   128.0.0.0       UG        0 0          0 tun0
128.0.0.0       217.64.xxx.x    128.0.0.0       UG        0 0          0 tun0

Those are more specific than the normal 0.0.0.0/0.0.0.0 default route, so they should be preferred:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s3

So the outbound routing table looks right to me.

Regarding your first question, you can’t choose tun0 in Plex. Plex filters it out, either by name or because it’s a point-to-point interface. That’s OK! You don’t want to choose it - Preferred network interface is only used for local network communication.

From the logs, Plex appears to detect the 217.x.x.x address as the primary interface, and appears to register it with the Plex Cloud.

So if I can ask … you haven’t mentioned … what’s not working? :slight_smile: :slight_smile: :slight_smile:

Is there any firewall in place?
Can you connect to 217.x.x.x:32400 from the server?
Can you connect to it remotely?

The issue is that I can’t connect to it, and in settings for remote access I’m getting a green light for a second, that then turns red.
the firewall has port 32400 open in, on tun0 and all outgoing open on tun0 and… wait a moment…

Sh*t, @Volts @ChuckPa , This is an ID 10 T error, I’m to ashamed to admit what I’ve done wrong!

                 To                             Action          From

[ 9] Anywhere on tun0 ALLOW IN 32400
[10] 32400 on tun0 ALLOW IN Anywhere

let’s say that one of them are faulty (9), and I have no idea what it actually do…
with 10 everything seems to be working…
sorry guys…

1 Like

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