iptables -t mangle -A OUTPUT -m owner --uid-owner plex -j MARK --set-mark 22
and by Policy Routing those packets would go through the normal Ethernet interface, so that it won’t be affected by a OpenVPN client.
However, once I do that, I can’t access the web interface in the same subnet. Without the above mark (i.e., routed through the OpenVPN), it has no problem. In this case, what could be the cause?
Aug 31, 2018 22:12:30.439 [0x7f9659fff700] WARN - PubSubManager: Connection to 184.105.148.102 failed: Connection timed out.
Aug 31, 2018 22:12:30.439 [0x7f9659fff700] WARN - PubSubManager: Connection to 50.116.44.223 failed: Connection timed out.
Aug 31, 2018 22:12:30.439 [0x7f9659fff700] WARN - PubSubManager: Connection to 45.79.10.123 failed: Connection timedout.
Aug 31, 2018 22:12:30.439 [0x7f9659fff700] WARN - PubSubManager: Connection to 172.104.213.223 failed: Connection timed out.
Aug 31, 2018 22:12:30.440 [0x7f9659fff700] WARN - PubSubManager: Connection to 172.104.225.166 failed: Connection timed out.
Aug 31, 2018 22:12:30.440 [0x7f9659fff700] WARN - PubSubManager: Connection to 139.162.115.125 failed: Connection timed out.
Aug 31, 2018 22:12:30.440 [0x7f9659fff700] WARN - PubSubManager: Connection to 109.237.24.233 failed: Connection timed out.
Aug 31, 2018 22:12:30.440 [0x7f9659fff700] WARN - PubSubManager: Connection to 103.3.62.6 failed: Connection timed out.
Aug 31, 2018 22:12:30.440 [0x7f9659fff700] WARN - PubSubManager: Connection to 82.94.168.60 failed: Connection timed out.
Out of curiosity, I pinged each and every of those IP addresses, and it turns out that none of them are actually accessible. Seriously, what’s going on here?
I just sorted it out as I wanted it to be. Here’s the solution:
The goal was to route the traffic generated by PLEX through the normal Ethernet interface (i.e., enp3s0 in my case). For me, there’s no merit in tunneling PLEX through an OpenVPN client, and it would be a lot slower than directly routing it through enp3s0.
My approach was problematic because
it redirects lo traffic to enp3s0 (but it’s not the reason why PLEX hangs), and
I didn’t fix the source address of these packets once they were redirected to enp3s0.
First of all, what needs re-routing is the one headed for the TUN interface (i.e., tun22 in my case). We just need to add one more option (i.e., -o tun22) for this purpose:
iptables -t mangle -A OUTPUT -o tun22 -m owner --uid-owner plex -j MARK --set-mark 22
That way, no packets headed for lo or enp3s0 shall be affected. Now, those packets aforementioned will be routed back to enp3s0 by Policy Routing. However, as I said earlier, their source addresses will not be automatically changed to the address of enp3s0. Since they were originally headed for tun22, their source addresses shall be something like 10.64.10.0/24. That being said, any reply to these packets will be lost along the way because 10.64.10.0/24 makes sense only in my computer (i.e., even the router will not understand it). In order to properly mark the return address (i.e., 192.168.22.18 in my case), we need to SNAT these packets before put on wire:
iptables -t nat -A POSTROUTING -m mark --mark 22 -m owner --uid-owner plex -j SNAT --to-source 192.168.22.18