Solved 386.1_2: openvpn-event causes “Linux route add command failed”

[Spud]

Thanks for the link. Now I see why I was confused. I didn't realize table 254 was the main table. Usually when referencing tables, at least those well-known, you use the name, if only for reasons of clarity.

ip rule add fwmark 0x7000/0x7000 table main prio 9990

Anyway, I have a problem w/ something the author of that script has failed to make crystal clear, and it's subtle enough that many users could easily miss it.

Clearly that script is a user defined implementation of PBR (policy based routing). However, as constructed, it *assumes*, in fact *requires*, that Routing Policy be enabled in the OpenVPN client. And that's because when Routing Policy is NOT enabled, the main routing table has its default gateway changed to the VPN by the OpenVPN server (at least for commercial OpenVPN providers). And under such circumstances, pointing your own PBR script back to the main routing table is pointless. But once you enable Routing Policy in the OpenVPN client, that keeps the main routing table pointing to the WAN as its default gateway, and so the script should now work (it may have other issues, but at least as far as this particular issue is concerned).

It would be far better to create your own separate routing table (e.g., 200) and configure it w/ the WAN as its default gateway. That way you're not dependent on how Routing Policy is or isn't configured in the OpenVPN client.

Obviously I don't know if this particular issue accounts for your present problems, but as currently written, the script leaves something to be desired.

Unfortunately the script still won’t work, despite throwing no errors on launch. I’m at the very beginning of getting to know tables and scripts, so that sounds like a project.

 

[eibgrad]

Unfortunately the script still won’t work, despite throwing no errors on launch. I’m at the very beginning of getting to know tables and scripts, so that sounds like a project.

I see other potential problems w/ that script. Sometimes such a script requires that reverse-path filtering be disabled as well. But before even going there …

I already mentioned that when the OpenVPN client is NOT active, presumably it all works. I also assume when the OpenVPN client is active, and Routing Policy is configured to route *everything* for the device hosting the plex server over the WAN (if only implicitly), it works as well. Usually these types of PBR scripts are meant to deal w/ a device that is bound to the VPN for all other purposes *except* the one traffic specified in the script.

As you probably already know, using the OpenVPN client's Routing Policy, you're limited in your ability to control what uses the WAN vs. VPN. For any given source IP, either all its traffic goes over the WAN, or all its traffic goes over the VPN. And that's when you see these other user-defined PBR scripts attempting to circumvent this limitation, in this case based on ports.

So while it is possible sometimes to make something like this work, it assumes you've accurately identified all the relevant traffic coming/going from/to that device. But I have no idea if forcing all udp port 32400 traffic over the WAN is sufficient. I don't use Plex. I don't know its requirements. I'm taking it on faith that you and the author know for a fact that's what's required to get the results you seek. But if there's some other piece missing from the recipe that's not being accounted for, then obviously the script as written will fall short.

All that said, I can rather quickly put together a better script that addresses some of my concerns w/ the author's version. But I just wanted to stress that I have no way of knowing if that alone is sufficient.

 

[Spud]

I see other potential problems w/ that script. Sometimes such a script requires that reverse-path filtering be disabled as well. But before even going there …

I already mentioned that when the OpenVPN client is NOT active, presumably it all works. I also assume when the OpenVPN client is active, and Routing Policy is configured to route *everything* for the device hosting the plex server over the WAN (if only implicitly), it works as well. Usually these types of PBR scripts are meant to deal w/ a device that is bound to the VPN for all other purposes *except* the one traffic specified in the script.

As you probably already know, using the OpenVPN client's Routing Policy, you're limited in your ability to control what uses the WAN vs. VPN. For any given source IP, either all its traffic goes over the WAN, or all its traffic goes over the VPN. And that's when you see these other user-defined PBR scripts attempting to circumvent this limitation, in this case based on ports.

So while it is possible sometimes to make something like this work, it assumes you've accurately identified all the relevant traffic coming/going from/to that device. But I have no idea if forcing all udp port 32400 traffic over the WAN is sufficient. I don't use Plex. I don't know its requirements. I'm taking it on faith that you and the author know for a fact that's what's required to get the results you seek. But if there's some other piece missing from the recipe that's not being accounted for, then obviously the script as written will fall short.

All that said, I can rather quickly put together a better script that addresses some of my concerns w/ the author's version. But I just wanted to stress that I have no way of knowing if that alone is sufficient.

If you could help me find a reliable way to route traffic from a specified port to a VPN client, that would be very good, thanks.

At the moment, I’m trying to expose Plex to the WAN by bypassing the VPN. How about reversing this, so the machine faces the WAN by default (incl. Plex), but other standard ports (e.g. browser) are routed to the VPN? That would eliminate the problem, I think.

 

[eibgrad]

If you could help me find a reliable way to route traffic from a specified port to a VPN client, that would be very good, thanks.

At the moment, I’m trying to expose Plex to the WAN by bypassing the VPN. How about reversing this, so the machine faces the WAN by default (incl. Plex), but other standard ports (e.g. browser) are routed to the VPN? That would eliminate the problem, I think.

Yes, that was the point I was trying to make (among others). If the device hosting Plex is bound completely to the WAN, then presumably it will work normally. As I said, the reason you see the author's kind of script being employed is because the user *insists* on that same device otherwise being bound to the VPN. But if you can live w/ that device being fully bound to the WAN, that should eliminate the need for that script. It just becomes irrelevant.

 

[Spud]

Yes, that was the point I was trying to make (among others). If the device hosting Plex is bound completely to the WAN, then presumably it will work normally. As I said, the reason you see the author's kind of script being employed is because the user *insists* on that same device otherwise being bound to the VPN. But if you can live w/ that device being fully bound to the WAN, that should eliminate the need for that script. It just becomes irrelevant.

I can live with that but I would want have the ability to route other ports to the VPN. How easy would that be?

 

[Jack Yaz]

Have you considered x3mRouting? https://github.com/Xentrk/x3mRouting

I'm unsure if it supports ports, but it is very powerful

 

[eibgrad]

I can live with that but I would want have the ability to route other ports to the VPN. How easy would that be?

Well I suppose you could let the device hosting the Plex server default to the WAN, then use that script to force other NON Plex traffic over the VPN. But that script would have to be substantially reconfigured for those purposes. And even so, you can run into problems if the Plex server needs to route (for example) ports 80/443 over the WAN. As I suggested earlier, I don't know if udp port 32400 is the *only* requirement of the Plex server. In your attempt to route port 80/443 traffic over the VPN for other purposes, you could inadvertently end up routing the Plex server's 80/443 traffic over the VPN as well, and now you're right back where you started; it doesn't run correctly.

I'm not trying to be overly pessimistic here, but just trying to make it clear that this can get tricky, esp. when you don't know w/ 100% certainty what the Plex server requires. It may very well be only udp port 32400, and perhaps w/ a few changes to the script (as I said, the lack of reverse-path filtering is a concern), it may work as intended.

 

[eibgrad]

Have you considered x3mRouting? https://github.com/Xentrk/x3mRouting

I'm unsure if it supports ports, but it is very powerful

It might very well be a better solution, esp. since the script currently being used is not all that well designed. But the issue that concerns me, regardless of the script chosen, is what specifically does the Plex server require be routed over the WAN? Apparently it's minimally port 34200, but is that sufficient? Is there more going on here than meets the eye? I just don't know. And why I'm still being a bit cautious about what will be the right course of action. In terms of simplicity, if the rules in the author's script are correct and sufficient, I'd prefer it. It would likely be a lighter solution.

That's why if you can eliminate this need/desire for port-based routing policy, things just get so much simpler.

 

[Spud]

It might very well be a better solution, esp. since the script currently being used is not all that well designed. But the issue that concerns me, regardless of the script chosen, is what specifically does the Plex server require be routed over the WAN? Apparently it's minimally port 34200, but is that sufficient? Is there more going on here than meets the eye? I just don't know. And why I'm still being a bit cautious about what will be the right course of action. In terms of simplicity, if the rules in the author's script are correct and sufficient, I'd prefer it. It would likely be a lighter solution.

That's why if you can eliminate this need/desire for port-based routing policy, things just get so much simpler.

The only external port Plex uses is 32400 (this is the only port to configure for remote access in the server), and several more are used internally:

What network ports do I need to allow through my firewall?

Note: This article is discussing ports in the local firewall of the computer running Plex Media Server. This is not...

support.plex.tv

I'll take a good look at x3mRouting, I've only scratched the surface till now.

 

[eibgrad]

FWIW, I made some modifications to the author's script and posted it on PasteBin.

merlin-ovpn-plex-pbr.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

It's now a firewall-start script. It can be copy/pasted into an ssh window and it will automatically be created and configured. Just make sure you have JFFS and JFFS scripts enabled in System->Adminstration. NOTE: It will NOT overwrite any existing firewall-start script. For that, you would either have to remove the existing firewall-start script, or merge the two (e.g., have one call the other).

At the very least, it corrects some obvious shortcomings, including disabling of reverse-path filtering, and all VPN dependencies. If it doesn't work, then I suspect there's more at play here than meets the eye.

 

[Spud]

FWIW, I made some modifications to the author's script and posted it on PasteBin.

merlin-ovpn-plex-pbr.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

It's now a firewall-start script. It can be copy/pasted into an ssh window and it will automatically be created and configured. Just make sure you have JFFS and JFFS scripts enabled in System->Adminstration. NOTE: It will NOT overwrite any existing firewall-start script. For that, you would either have to remove the existing firewall-start script, or merge the two (e.g., have one call the other).

At the very least, it corrects some obvious shortcomings, including disabling of reverse-path filtering, and all VPN dependencies. If it doesn't work, then I suspect there's more at play here than meets the eye.

Fantastic, thank you! I'll try this when I get home later.

 

[Spud]

FWIW, I made some modifications to the author's script and posted it on PasteBin.

merlin-ovpn-plex-pbr.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

It's now a firewall-start script. It can be copy/pasted into an ssh window and it will automatically be created and configured. Just make sure you have JFFS and JFFS scripts enabled in System->Adminstration. NOTE: It will NOT overwrite any existing firewall-start script. For that, you would either have to remove the existing firewall-start script, or merge the two (e.g., have one call the other).

At the very least, it corrects some obvious shortcomings, including disabling of reverse-path filtering, and all VPN dependencies. If it doesn't work, then I suspect there's more at play here than meets the eye.

Well, this works like a charm! I’m so pleased. Everything goes through the VPN except Plex, just as it should. If the VPN disconnects, the kill switch stops all traffic except Plex. Perfect.

Many thanks to you, I can also learn from your notes on the script. Is there a way I can send you a large coffee, or is a site donation preferable?

 

[eibgrad]

Well, this works like a charm! I’m so pleased. Everything goes through the VPN except Plex, just as it should. If the VPN disconnects, the kill switch stops all traffic except Plex. Perfect.

Many thanks to you, I can also learn from your notes on the script. Is there a way I can send you a large coffee, or is a site donation preferable?

Good to hear.

You could do be one better than a coffee. If you could please delete or comment out the line that disables reverse path filtering, reboot, and try again, and let me know whether it continues to work. I'm curious if that made the difference. It's always better to NOT disable reverse path filtering if you can avoid it, but sometimes you have no choice.

 

[Spud]

Good to hear.

You could do be one better than a coffee. If you could please delete or comment out the line that disables reverse path filtering, reboot, and try again, and let me know whether it continues to work. I'm curious if that made the difference. It's always better to NOT disable reverse path filtering if you can avoid it, but sometimes you have no choice.

No problem, I'll get to it tomorrow. I'll assume I only need to drag/drop the script again with those parts commented out, then reboot.

I'll send that coffee to the Merlin site, it's been invaluable.

 

[eibgrad]

I'll assume I only need to drag/drop the script again with those parts commented out, then reboot.

Correct, although the script will NOT overwrite itself, so you'll need to delete it first.

rm /jffs/scripts/firewall-start

 

[Spud]

Good to hear.

You could do be one better than a coffee. If you could please delete or comment out the line that disables reverse path filtering, reboot, and try again, and let me know whether it continues to work. I'm curious if that made the difference. It's always better to NOT disable reverse path filtering if you can avoid it, but sometimes you have no choice.

I tested it this morning, and it's now working properly with the line commented out. I had a bit of trouble getting it running again, and eventually realised that I had to reapply the VPN client settings, even though it was a fresh boot.

With any luck it'll be fine now, and I know which quirks to look out for.

Many thanks again for your help.

 

[Deleted member 62525]

I have been running Plex for years and I first used it with VPN. Over the years I found this to be a bad idea as remote access sometimes would be unavailable or if VPN client had any issues remote access to my Plex server was gone. Also the speed is much less. Anyway I opted to not use VPN and Plex. It’s more reliable, faster and I don’t have any issues since.

 

[Deleted member 62525]

Also I should mention that Plex has issues with double NAT. If you use that config and VPN with Plex this will be not easy and reliable.
Bridge ISP modem and Plex works really well.