"LINUX" is telling "WORKSTATION" to use "GATEWAY" instead of itself because they appear to be on the same subnet. This can only work if you've set up bridging on "LINUX" (see brctl(8)), and if you did then "WORKSTATION" should use "GATEWAY" in its default route.
Make sure you use a subnet per broadcast domain, broadcast packets are never routed so you need a different subnet on all 3 interfaces of "LINUX" (you could use /30s but I recommend sticking to /24s for growth). or have it bridge them. You should probably also configure a separate subnet for the VPN itself.
Next, add the VPN subnet to the VPN table, e.g.:
ip route add 192.168.150.0/24 dev tun0 scope link table VPN proto static
In order to use this table, add a routing rule like so:
ip rule add fwmark 1 lookup VPN priority 500
And see if you can route packets via both "VPN" and "GATEWAY" before you add any fwmark rules, just in case.
And I don't think disabling the reverse path filter is beneficial.
I've recently hit a similar issue, albeit a slightly different. I wanted to route only TCP port 25 (SMTP) over an OpenVPN tap0 interface, while routing all other traffic (even for the same host) over the default interface.
To do so, I had to mark packets and set up rules for handling it. First, add a rule that make the kernel route packets marked with 2 through table 3 (explained later):
ip rule add fwmark 2 table 3
You could have added a symbolic name to /etc/iproute2/rt_tables, but I did not bother to do so. The number 2 and 3 are randomly chosen. In fact, these can be the same but for clarity I did not do it in this example (although I do it in my own setup).
Add a route for redirecting traffic over a different interface, assuming the gateway being 10.0.0.1:
ip route add default via 10.0.0.1 table 3
Very important! Flush your routing cache, otherwise you will not get a response back and sit with your hands in your hair for some hours:
ip route flush cache
Now, set a firewall rule for marking designated packets:
iptables -t mangle -A OUTPUT -p tcp --dport 465 -j MARK --set-mark 2
The above rule applies only if the packets come from the local machine. See http://inai.de/images/nf-packet-flow.png. Adjust it to your requirements. For instance, if you only want to route outgoing HTTP traffic over the tap0 interface, change 465 to 80.
To prevent the packets sent over tap0 getting your LAN address as source IP, use the following rule to change it to your interface address (assuming 10.0.0.2 as IP address for interface tap0):
iptables -t nat -A POSTROUTING -o tap0 -j SNAT --to-source 10.0.0.2
Finally, relax the reverse path source validation. Some suggest you to set it to 0, but 2 seems a better choice according to https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt. If you skip this, you will receive packets (this can be confirmed using tcpdump -i tap0 -n), but packets do not get accepted. The command to change the setting so packets get accepted:
sysctl -w net.ipv4.conf.tap0.rp_filter=2
Best Answer
No, it's not. IPTables works at layer 3/4, and HTTP request headers are layer 7.
Yes, using mod_proxy, Apache can proxy those requests to another server.
As stated above, mod_proxy will work for you, but any other reverse proxy that can operate at layer 7 will do the trick. Along with Apache's mod_proxy, Nginx and HAproxy are probably the most common ones.