Archangel

Иван: Если устройства не очень мощные и только Cisco есть в инфраструктуре - используйте EIGRP. Хотя как мне кажется, в вашем случаи динамическая маршрутизация - заморочка которая нужна исключительно ради академического интереса.

P.S. Про захват пакетов читать тут: www.cisco.com/c/en/us/support/docs/ios-nx-os-softw...
Так удобно как tcpdump в реальном времени конечно не получится, но в будущем, уверен, еще пригодиться.

Вы совершенно правы. На маршрутизаторах с IOS трафик инициированный самим маршрутизатором не попадает под ACL.

Если есть такая критичная необходимость не пустить трафик наружу, то самый простой вариант - заворачивать целевой трафик на loopback интерфейс с помощью локального route-map-а.

ip local policy route-map

В общем спустя много времени пришлось мне таки вернуться к этому вопросу.
На случай, если кто-нибудь столкнется с подобной проблемой:

policy-based-route test-pbr-new permit node 1
   if-match acl 3003
policy-based-route test-pbr-new permit node 2
   if-match acl 3002
   apply ip-address next-hop 10.10.253.2

Сам PBR составлен верно. Проблема оказалась в ACL-ах.
Во-первых:
Comware в PBR попросту игнорирует permit и deny внутри самого ACL.
Во-вторых:
Экспериментально было выяснено, что ситуация, когда ACL фигурирует в нескольких нодах PBR обрабатывается корректно только в том случаи, если ACL-ы во всех нодах кроме последней имеют и source и destination. В противном случаи обработка не прекращается при срабатывании ACL-а.
В-третьих:
Также экспериментально выявлено, что при указании в ACL-е в качестве единственного source подсети совпадающей с подсетью данного интерфейса при обработке политики все ноды содержащие ACL с destination просто игнорируются.

Т.о.
Для реализации обозначенного выше сценария ACL-и должны быть

Advanced ACL  3002, named -none-, 2 rules,
ACL's step is 5
 rule 10 permit ip source 10.10.254.0 0.0.0.255 destination 10.10.0.0 0.0.255.255 (72 times matched)
 rule 20 permit ip source 10.10.254.0 0.0.0.255 destination 192.168.0.0 0.0.255.255

Advanced ACL  3003, named -none-, 1 rule,
ACL's step is 5
 rule 10 permit ip source 10.10.254.0 0.0.0.127 (6 times matched)

А если нужно завернуть всю подсеть, то во второй ноде PBR просто не нужно указывать ACL вообще.

Поздновато увидел ваш вопрос к сожалению.
Хотел уточнить решили или нет, раз решили, поленюсь разбираться и попрошу готовый ответ.

Вам вполне подойдет минимальный вариант - два коммутатора 2960 Plus (у обычных EoL в конце октября уже), например WS-C2960+48PST-S (это PoE) и WS-C2960+48TC-S с базовой L2 лицензией. Стека у них нет, но есть пара 1GE портов, чтоб между собой связать.

Маршрутизатор CISCO1941-SEC/K9 вас в принципе тоже должен устроить по всем параметрам, даже без модуля аппаратного шифрования (он около 2K$ стоит). Благо с недавних пор на SSL VPN отдельно лицензии покупать не надо.
Ну и SmartNET, как минимум к самому маршрутизатору.
Итого:
CISCO1941-SEC/K9 - около $3K по GPL (с сервисным контрактом).
WS-C2960+48PST-S - около $3K по GPL.
WS-C2960+48TC-S - около $1,3K по GPL.
Итого имеем 7300 баксов по GPL. Ну т.е. по факту, с учетом скидок, в 6 килобаксов влезете без проблем.

Управляемый/неуправляемый коммутаторы. Для управляемых можно уточнить, что они L2 или второго уровня.

Я так понимаю, у вас проблема в том, что в обеих подсетях DHCP и приходит просто два шлюза по-умолчанию, возможно еще и два DNS-а. Иначе проблемы бы не было в принципе и система сама разбиралась куда ходить.
Если так, то самый просто вариант одно из подключений просто руками настроить.

Судя по маске связность между R1 и R2 - L2.
Если сделать между всеми тремя маршрутизаторами единый L2 домен и дать R3 адрес 192.168.90.3 то можно обойтись без PBR. Только для того, чтобы хосты с одним и тем же адресом из обеих сетей (9.0) имели доступ в 75.0, придется городить встречные NAT-ы.

Ну сама по себе Windows 7, на сколько я помню, не может работать в режиме маршрутизатора. Только включать ICS и делать NAT в сеть 172.x.x.x. А на остальных устройствах прописать маршрут вида:
172.x.x.x mask 255.0.0.0 [IP компьютера с VPN-ом]

Если позволяет роутер (в чем я сомневаюсь, но все же), то лучше между ним и компьютером с VPN-ом сделать отдельную среду маршрутизации. Не обязательно физически изолированную, можно просто по второму IP дать каждому интерфейсу. Иначе сделать маршрутизацию между устройствами и сетью 172.x.x.x не меняя настройки самих устройств не получится.

А как настроен НАТ на Server 2. Если вы натите трафик от User 2 средсвами RRAS-а на Server 2, то фактически скрываете сеть 172.17.0.0/16 от сети 172.16.12.0/24 и 172.16.11.0/24. Т.е. если вы с User 1 будете отбращаться на IP из 172.17.0.0 то пакет туда придет 172.16.12.2 <-> 172.17.0.2, т.к. между серверами маршрутизация, и Server 2 свою сеть знает, посему просунет пакет согласно on-link маршруту. А вот обратно, когда User 2 ответит, Server 2, перехватит его пакет и NAT заменит адрес источника на адрес сервера. А теперь смотрите запрос 172.16.12.2 <-> 172.17.0.2, а ответ 172.16.11.11 <-> 172.16.12.2. Конечно ответный запрос не будет обработан, т.к. User 1 не поймет, ответом на что он является.

Итого: Ни RRAS ни VPN тут не при чем. Проблема в принципиальной схеме. Либо надо делать маршрутизацию Сеть<->Сеть, либо настраивать NAT на Server 2 на проброс портов, и просовывать их на IP клиента (User 2), ну и обращаться соответственно на IP Server 2 (который конец OpenVPN тоннеля), но я бы делал первый вариант, он проще, гибче и логичнее. Настройки OpenVPN тут в общем-то и не имею значения, лучше бы привели настройки RRAS-а.