OK, so here's the obligatory ASCII art diagram of my setup. Well, the relevant parts anyway
By default, the VPN doesn't set up any overriding routes to force any packets out via tun0.

My initial requirements were the following:

• Any outgoing packet from Plex, not for local network, should be routed through tun0
• Any outgoing packet from the Roku, not for local network, should be routed through tun0

This resulted in the following commands:
This all appears to be working exactly how I wanted. But feel free to critique.

What I now need to do, is add some additional rules, and this is where I'm stumped. The additional requirement is now for the Plex application to receive incoming requests, via eth0. The responses to those requests must, obviously, be routed back via eth0.

So, I'm looking for input on how I can achieve this extra step.

Cheers.

I believe you can do something similar to what you've already done. Set up another table, add a default route for eth0 on it and add a rule when it's from eth0s ip.

ip route add default via <next hop of eth0> table <eth0 table name>
ip rule add from <eth0 ip> table <eth0 table name>

Not sure why you think that would work.

That's already in place as the final routing table to make sure all packets not previously routed get sent out via eth0.
If I place that rule ahead of my rule 401, then all packets will go out via eth0 regardless of their origin. If I place it after rule 401, then all the packets from Plex/Roku will still take my rule and go via tun0.

Cheers.

The ip route command was just to create a default route for the new table. It doesn't change what your global default route is. In your case it happens that eth0 is also your default interface.

Okay so the issue is the OUTPUT mangle is catching too much. How about getting rid of that and adding another rule.

ip rule add from <tun0 ip> table 401

That should cause anything coming in from tun0 to go out tun0.

Leave the mangle for the roku in place since you want those to still traverse tun0 for non-local

Maybe I'm missing something fundamental here from your replies.

From the first reply:
Are you trying to say that the outbound packet, if it's the reply to one arriving at eth0 will be picked up by this rule. I would have expected the "from IP" to be the IP of the system that generates the packet, which would be the IP of the router/firewall where Plex is running: 192.168.0.nnn. Is this where I'm making a wrong assumption.

From your last post:
Again, I would expect an outgoing packet to have a "from IP" of where that outgoing packet came from. The router/firewall IP or the Roku IP which would be NATed to the eth0 IP before being sent.
All the traffic coming in via tun0 are replies to outbound requests. There will never be any inbound connections originating from that interface.

Cheers.

Hmm, that is a bit more complicated then I was originally thinking.

With regards to the rules I mentioned. I was thinking the plex server was listening on all interfaces (0.0.0.0) which would set up inbound relationships for every connection coming into it. This allows you to use the from <interface ip> rules to route traffic back out the interface they came in originally.

Are there any other differentiating characteristics of the traffic coming in from eth0 versus plex traffic you want to go out tun0?

Can the plex server be set up to listen on multiple interfaces and select which one it uses as it's primary? If so, you could set the primary to tun0 and then the rules would route every thing without the OUTPUT mangle.

What causes the plex server to initiate an outgoing connection that would/should travel out tun0? Is it just requests from the roku (and you'd like to add requests from eth0)? Or does it talk with an external entity for other stuff, like licensing and such?

Ain't that the truth.
OK, some background which may help understanding.

Roku is a streaming media box connected to the TV. Plex is a media server. Now let's take two examples and hopefully between them it will explain what I'm trying to do. Firstly, lets just talk about media that is hosted locally on my server. From the local network, the Roku will chat to Plex and ask to be served up a film. Plex will then stream the data to the Roku. It's the "! -d 192.168.0.0/24" part of the iptable rules that keeps all this traffic local. Now, Plex can also serve the same locally held media to other clients coming in from outside my network, via eth0. So, in the same way as the Roku, a remote application or browser, can connect though my firewall to Plex and ask for a film to be streamed back to them. Note that Plex, for this scenario, never initiates any connection. It's always listening and sending replies. It's this additional piece of supporting non-local connections I'm trying to achieve.

Now let's consider streaming media held remotely from my network. The request for this streaming media can be made either by Plex, or it can come from the Roku, but whichever, the request must leave my server via the VPN tunnel. It's these requests I'm "marking" and then routing out via the rule to the tunnel. Obviously the incoming stream, in reply, is still directed to the correct requester.
Yes via 0.0.0.0, it has to be in order to support the first scenario of listening internally and externally.
Nope.

Hopefully that gives a little more insight in what I'm trying to achieve.

Thanks again for trying to help. It's much appreciated.

Cheers.

Yes, that description will help, I'm going to setup a small mock server at home that mimics that and test out some things.

Okay, I have something that works for me, so it might work for you as well. I have a bunch of different things going on in my test setup but I think it is just a simple one rule add to make it work. If it doesn't I can go back through my steps and see if something else is needed in conjuction with that rule.

Before your OUTPUT mangle rule and a new conntrack rule
iptables -t mangle -A OUTPUT -m conntrack --ctorigdst <eth0 ip> -j ACCEPT

This will keep things coming into eth0 that aren't originated from the local box from getting marked. In otherwords only connections the plex server initiates will get marked. At first I tried just using a state NEW limitation on your original OUTPUT mangle but that left the plex connections half connected.


My setup was 3 boxes, simulated plex server with eth0 and a eth0.200 vlan simulating your tun0, a "remote" server, had a real external ip mapped on to lo and used the .200 vlan for tun0 routing, client box making a connection to the simulated plex server via eth0, no vlan on the client. I didn't simulate the roku since I figured your other rules covered that situation and it would work fine.

1 members found this post helpful.

Many thanks indeed for the time you spent in setting this up and trying things. It is much appreciated.

It'll take me a couple of days to check this out and run a few packet sniffs to validate it.

Thanks again.

Cheers.

I haven't been able to do extensive testing yet, but my initial tests show that everything is working exactly how I wanted it.

Again, thank you very much for the time and effort you put into this. It is very much appreciated.

Cheers.