OpenVPN affecting separate routing table

[kurayami 0]

I've been having an issue with my setup where I have two NICs, eth0 and eth1. I have it configured such that eth1 is on a separate routing table I call "services" so that any requests sent to eth1 are returned on eth1. My main routing table is on eth0 and this is where all my outbound traffic goes. The purpose of this is so that I can stay connected with a VPN for all outbound traffic, but traffic requested to my public IP for services I am running such as HTTPS return back out my public IP (router port forwards to my eth1 interface). Everything works (all outbound traffic goes out eth0 as expected and traffic to eth1 goes out eth1) except for when I turn on my VPN and suddenly eth1 is no longer returning requests to external hosts. I can see that routes are only adjusted on my main routing table by the VPN and my services routing table is unaffected when I run the "ip route" commands for each table, and yet eth1 is not responding to requests from external IPs. Is there another setting I could be missing or a client configuration option in OpenVPN that would limit VPN connections to the main routing table only?

[OpenSourcerer 1442]

Such info can be read in the manual usually. Try the --local <ip> directive on the eth0 interface IP address.

[NaDre 157]

9 hours ago, kurayami said:

... I call "services" so that any requests sent to eth1 are returned on eth1. My main routing table is on eth0 and this is where all my outbound traffic goes. The purpose of this is so that I can stay connected with a VPN for all outbound traffic, but traffic requested to my public IP for services I am running such as HTTPS return back out my public IP (router port forwards to my eth1 interface). ...

This is Linux? It is possible to allow incoming traffic on the real interface to be responded to on the real interface, while having the VPN be the default gateway using this technique:

https://github.com/tool-maker/VPN_just_for_torrents/wiki/Maintaining-SSH-Access-Using-a-VPN-on-a-Remote-Linux-Server

No need  for a second real network interface. Perhaps your approach can be made to work. But for sure the method described there works.