Openvpn – RTNETLINK answers: File exists — OpenVPN errors

Try these rules on your gateway:

-A PREROUTING -i $VPN_INTERFACE -p tcp -m tcp --dport 80 -j DNAT --to-destination $INTERNAL_IP_DESTINATION:80
-A POSTROUTING -o $VPN_INTERFACE -j SNAT --to-source $VPN_IP_OF_SERVER
-A POSTROUTING -o $LAN_INTERFACE -j SNAT --to-source $LAN_IP_OF_SERVER

1st. one makes the port forwarding.
2nd. makes the source nat so every packet comming out of the VPN uses the server IP
3rd. makes the packets forwarded to the internal IP, have the soure nat of the server lan ip

You would need to elaborate somewhat further what it is you are trying to do. A rough sketch with IP addresses of the hosts involved and a listing of your routing table(s) would help a lot understanding your problem.

my server doesn't seem to configure the tun0 device properly

It is possible for an ifconfig command to fail - maybe you should check the logs for that and post the relevant excerpts.

I want to set up the dual client box such that a computer whose gateway is set to eth0:0 gets all their traffic routed through one OpenVPN tunnel, and a computer whose gateway is set to eth0:1 gets all their traffic routed through a different OpenVPN tunnel

ip rule add from $IP_ETH00 table us_table

That's probably not the best way to achieve what you really want - which seems to be different routes for different clients. While it is possible to add iptables -t mangle rules to mark packets for different criteria, there would be no set of criteria being able to distinguish between eth0:0 and eth0:1 as the input interface (which is due to the way IP aliasing is implemented).

What you can do however is simply set up something like

ip rule add from <ip-of-your-client-for-the-us-table> table us_table

which would eliminate the need for IP aliases in your configuration entirely since the routing decision would be done based on source and destination IP addresses, no matter which interface the packet came in at.

copy_routing_table "us_table"

You've omitted the source of copy_routing_table - if it does what I suspect it does, you would end up with your entire main routing table in us_table. If your main routing table already contains routes potentially conflicting with what you're defining in the script, you might end up using them instead of your newly-added routes. This is especially a concern since you are adding a new default route in your up-script:

 ip route add default via $4 table us_table

As you already have a default route in your "main" table and add another one "via $4" (which is wrong BTW, as $4 would represent a local IP address of the router's own tun interface - you should use "dev $1" instead) without deleting the old route. You should prepend ip route del default table us_table here - and probably something similar for the other routes you add as well.

And this here:

From 192.168.1.133: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.1)

is a message from 192.168.1.133 which is getting the packet for 98.137.149.56 (yahoo.com) and routing it out through 192.168.1.1. Since 192.168.1.133 knows (by evaluation of the interface netmask) that your host is in the same network as 192.168.1.1, you get notified to use 192.168.1.1 directly in the first place.