Bueno...
Después de miles de horas depurando, probando diferentes configuraciones y 72 horas de pruebas intensas en producción, pude encontrar la solución/configuración correcta, el problema estaba en las reglas de iptables (sección de manipulación) aparentemente los paquetes se marcaron justo cuando llegaron pero cuando salieron no había ningún paquete dañado, de todos modos aquí está mi solución final de trabajo a mi problema:
/etc/sysconfig/iptables :
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Basic Rules
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT
# SSH
-A INPUT -i eth0 -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -i eth2 -m tcp -p tcp --dport 22 -j ACCEPT
# OpenVPN
-A INPUT -i eth0 -m udp -p udp --dport 1194 -j ACCEPT
-A INPUT -i eth2 -m udp -p udp --dport 1194 -j ACCEPT
# Allow everything from LAN
-A INPUT -i eth1 -j ACCEPT
# Allow everything from the VPN
-A INPUT -i tun0 -j ACCEPT
# Default Drop on everything else
-A INPUT -j DROP
# Allow forwarding from LAN and VPN
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
# Allow all outbound traffic
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth1 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# DNAT to Developer Box (SSH Server)
-A PREROUTING -i eth0 -p tcp -m tcp --dport 2222 -j DNAT --to-destination 10.0.0.200:2222
-A PREROUTING -i eth2 -p tcp -m tcp --dport 2222 -j DNAT --to-destination 10.0.0.200:2222
# SNAT
-A POSTROUTING -o eth0 -j SNAT --to-source 10.0.1.1
-A POSTROUTING -o eth2 -j SNAT --to-source 10.0.2.1
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# CONNMARK Source Based Routing
-A PREROUTING -i eth0 -m state --state NEW,RELATED,ESTABLISHED -d 10.0.1.1 -j CONNMARK --set-mark 0x2
-A PREROUTING -i eth2 -m state --state NEW,RELATED,ESTABLISHED -d 10.0.2.1 -j CONNMARK --set-mark 0x3
-A PREROUTING -i eth1 -m connmark --mark 0x2 -j CONNMARK --restore-mark
-A PREROUTING -i eth1 -m connmark --mark 0x3 -j CONNMARK --restore-mark
-A OUTPUT -m state --state ESTABLISHED,RELATED -j CONNMARK --restore-mark
COMMIT
Obviamente, además de toda la configuración anterior relacionada con iproute y gwping (para balanceo de carga de enlaces y conmutación por error), las soluciones fueron posibles gracias a las fuentes [1] y [2], que me señalaron una parte diferente (Luca Gibelli para la parte PREROUTING y Karl Bowden para la parte OUTPUT) de la solución, también estoy viviendo aquí algunas fuentes más para otros sitios web que me indicaron la dirección correcta para buscar. Espero que esto ayude a otro administrador de sistemas en el futuro.
Saludos cordiales
Fuentes:
[1]www.nervous.it/2010/09/dnat-and-ip-source-routing-woes/
[2]blog.khax.net/2009/12/01/multi-gateway-balancing-with-iptables/
[3]home.regit.org/netfilter-en/links-load-balancing/
[4]mailman.ds9a.nl/pipermail/lartc/2006q2/018964.html
[5]web.archive.org/web/20120320115329/http://versa.net.au/index.php?option=com_content&task=view&id=21&Itemid=34
Actualización 10/10/2013
OpenVPN requiere una directiva de configuración adicional para trabajar con una configuración de WAN múltiple (como la anterior), así que simplemente agregue la opción multihome en su server.conf (OpenVPN>=2.1, para versiones inferiores, simplemente cambie la directiva local para escuchar solo en un ip en particular) y listo.