Когда мы идём с самого сервера 192.168.11.3 в 192.168.1.* и 192.168.2.*, то в качестве исходящего адреса выставляется IP местного конца туннеля, в данном случае 10.8.2.3, поэтому всё и работает. Это легко проверить с помощью команды типа:
ip route get 192.168.1.77
Когда же подобный трафик приходит с телефона, у него IP-адрес 10.1.3.2. С таким адресом трафик попадает на astrave-mainsrv и в дальнейшем роутится в openvpn либо не пропускается на astrave-mainsrv (смотря как там настроено). Аналогичная фигня происходит с трафиком из сетей 192.168.11.* и 192.168.12.* - он не будет уходить в туннель с адресом источника 10.8.2.3.
Решение: на astrave-mainsrv весь трафик, уходящий в openvpn, NATить в 10.8.2.3.
Вот так (тут tun666 - интерфейс openvpn):
iptables -t nat -A POSTROUTING -s 10.1.3.0/24 -o tun666 -j SNAT --to 10.8.2.3
Или даже так (тогда можно не задумываться о том, какой IP на нашей стороне туннеля, особенно если он динамический):
iptables -t nat -A POSTROUTING -s 10.1.3.0/24 -o tun666 -j MASQUERADE
Или даже можно не особо разбираться с конкретным адресом (тогда заодно с любых IP типа 192.168.11.* заработает, если трафик от них как-то попадёт на astrave-mainsrv):
iptables -t nat -A POSTROUTING -o tun666 -j MASQUERADE
Общий смысл: если компания хочет видеть у себя весь трафик подключающегося по VPN сотрудника c адреса 10.8.2.3, то мы весь трафик должны посылать именно с этого адреса, подменяя адрес источника.
