As I told in the comment linked from OP, starting with Linux kernel 4.17, using iptables (or anything netfilter related) is not needed anymore to solve this problem. The newer feature available to handle this with a recent kernel is described in kernelnewbies.org:

Extends fib rule match support to include sport, dport and ip proto match (to complete the 5-tuple match support). Common use-cases of Policy based routing in the data center require 5-tuple match commit, commit, commit, commit, commit

So rather than searching what detail didn't work the same way as in my previous answer, I'll implement the newer method in this answer.

I'll assume only one VPN is running: the one described by OP. I lack informations about the other VPN to know if there are interactions with it.

Please scratch any ip rule rules or iptables rules previously added to try and solve this problem.

Keep the table 80 as in OP:

ip route add table 80 192.168.50.0/24 dev bond0 src 192.168.50.34 ip route add table 80 default via 192.168.50.1 

Add with ip rule the rules selecting the alternate routes when using specific destination ports. Without knowing the use case or remaining topology (other VPN, server also receiving incoming traffic from the VPN...), to stay on the safe side I limit this to the server itself, not anything it might be routing. That's the goal of iif lo below. It's a special way to mean from local, ie locally initiated outgoing (non-routed) traffic:

ip rule add iif lo ipproto tcp dport 80 lookup 80 ip rule add iif lo ipproto tcp dport 443 lookup 80 ip rule add iif lo ipproto tcp dport 1195 lookup 80 ip rule add iif lo ipproto tcp dport 32400 lookup 80 

Then the remaining part is to relax Strict Reverse Path Forwarding to Loose RPF (which isn't much different from not activating it at all) in case it's active by default in the given Linux distribution, to prevent return traffic from being dropped:

sysctl -w net.ipv4.conf.bond0.rp_filter=2 

And that's it:

# ip route get 192.0.2.10 192.0.2.10 dev tun1 src 10.44.10.6 uid 0 cache # ip route get 192.0.2.10 ipproto tcp dport 80 192.0.2.10 via 192.168.50.1 dev bond0 table 80 src 192.168.50.34 uid 0 cache 

As I told in the comment linked from OP, starting with Linux kernel 4.17, using iptables (or anything netfilter related) is not needed anymore to solve this problem. The newer feature available to handle this with a recent kernel is described in kernelnewbies.org:

Extends fib rule match support to include sport, dport and ip proto match (to complete the 5-tuple match support). Common use-cases of Policy based routing in the data center require 5-tuple match commit, commit, commit, commit, commit

So rather than searching what detail didn't work the same way as in my previous answer, I'll implement the newer method in this answer.

I'll assume only one VPN is running: the one described by OP. I lack informations about the other VPN to know if there are interactions with it.

Please scratch any ip rule rules or iptables rules previously added to try and solve this problem.

Keep the table 80 as in OP:

ip route add table 80 192.168.50.0/24 dev bond0 src 192.168.50.34 ip route add table 80 default via 192.168.50.1 

Add with ip rule the rules selecting the alternate routes when using specific destination ports. Without knowing the use case or remaining topology (other VPN, server also receiving incoming traffic from the VPN...), to stay on the safe side I limit this to the server itself, not anything it might be routing. That's the goal of iif lo below. It's a special way to mean from local, ie locally initiated outgoing (non-routed) traffic:

ip rule add iif lo ipproto tcp dport 80 lookup 80 ip rule add iif lo ipproto tcp dport 443 lookup 80 ip rule add iif lo ipproto tcp dport 1195 lookup 80 ip rule add iif lo ipproto tcp dport 32400 lookup 80 

Then the remaining part is to relax Strict Reverse Path Forwarding to Loose RPF (which isn't much different from not activating it at all) in case it's active by default in the given Linux distribution, to prevent return traffic from being dropped:

sysctl -w net.ipv4.conf.bond0.rp_filter=2 

And that's it:

# ip route get 192.0.2.10 192.0.2.10 dev tun1 src 10.44.10.6 uid 0 cache # ip route get 192.0.2.10 ipproto tcp dport 80 192.0.2.10 via 192.168.50.1 dev bond0 table 80 src 192.168.50.34 uid 0 cache 

As I told in the comment linked from OP, starting with Linux kernel 4.17, using iptables (or anything netfilter related) is not needed anymore to solve this problem. The newer feature available to handle this with a recent kernel is described in kernelnewbies.org:

Extends fib rule match support to include sport, dport and ip proto match (to complete the 5-tuple match support). Common use-cases of Policy based routing in the data center require 5-tuple match commit, commit, commit, commit, commit

So rather than searching what detail didn't work the same way as in my previous answer, I'll implement the newer method in this answer.

I'll assume only one VPN is running: the one described by OP. I lack informations about the other VPN to know if there are interactions with it.

Please scratch any ip rule rules or iptables rules previously added to try and solve this problem.

Keep the table 80 as in OP:

ip route add table 80 192.168.50.0/24 dev bond0 src 192.168.50.34 ip route add table 80 default via 192.168.50.1 

Add with ip rule the rules selecting the alternate routes when using specific destination ports. Without knowing the use case or remaining topology (other VPN, server also receiving incoming traffic from the VPN...), to stay on the safe side I limit this to the server itself, not anything it might be routing. That's the goal of iif lo below. It's a special way to mean from local, ie locally initiated outgoing (non-routed) traffic:

ip rule add iif lo ipproto tcp dport 80 lookup 80 ip rule add iif lo ipproto tcp dport 443 lookup 80 ip rule add iif lo ipproto tcp dport 1195 lookup 80 ip rule add iif lo ipproto tcp dport 32400 lookup 80 

Then the remaining part is to relax Strict Reverse Path Forwarding to Loose RPF (which isn't much different from not activating it at all) in case it's active by default in the given Linux distribution, to prevent return traffic from being dropped:

sysctl -w net.ipv4.conf.bond0.rp_filter=2 

And that's it:

# ip route get 192.0.2.2 192.0.2.10 dev tun1 src 10.44.10.6 uid 0 cache # ip route get 192.0.2.2 ipproto tcp dport 80 192.0.2.10 via 192.168.50.1 dev bond0 table 80 src 192.168.50.34 uid 0 cache 

As I told in the comment linked from OP, starting with Linux kernel 4.17, using iptables (or anything netfilter related) is not needed anymore to solve this problem. The newer feature available to handle this with a recent kernel is described in kernelnewbies.org:

Extends fib rule match support to include sport, dport and ip proto match (to complete the 5-tuple match support). Common use-cases of Policy based routing in the data center require 5-tuple match commit, commit, commit, commit, commit

So rather than searching what detail didn't work the same way as in my previous answer, I'll implement the newer method in this answer.

I'll assume only one VPN is running: the one described by OP. I lack informations about the other VPN to know if there are interactions with it.

Please scratch any ip rule rules or iptables rules previously added to try and solve this problem.

Keep the table 80 as in OP:

ip route add table 80 192.168.50.0/24 dev bond0 src 192.168.50.34 ip route add table 80 default via 192.168.50.1 

Add with ip rule the rules selecting the alternate routes when using specific destination ports. Without knowing the use case or remaining topology (other VPN, server also receiving incoming traffic from the VPN...), to stay on the safe side I limit this to the server itself, not anything it might be routing. That's the goal of iif lo below. It's a special way to mean from local, ie locally initiated outgoing (non-routed) traffic:

ip rule add iif lo ipproto tcp dport 80 lookup 80 ip rule add iif lo ipproto tcp dport 443 lookup 80 ip rule add iif lo ipproto tcp dport 1195 lookup 80 ip rule add iif lo ipproto tcp dport 32400 lookup 80 

Then the remaining part is to relax Strict Reverse Path Forwarding to Loose RPF (which isn't much different from not activating it at all) in case it's active by default in the given Linux distribution, to prevent return traffic from being dropped:

sysctl -w net.ipv4.conf.bond0.rp_filter=2 

And that's it:

# ip route get 192.0.2.10 192.0.2.10 dev tun1 src 10.44.10.6 uid 0 cache # ip route get 192.0.2.10 ipproto tcp dport 80 192.0.2.10 via 192.168.50.1 dev bond0 table 80 src 192.168.50.34 uid 0 cache