Cisco Nat load balancing + VRF. Как заставить работать ip nat inside destination на VRF?

Вот попробовал в на CSR 1000v XE 16.9.01.
В Cisco Feature Navigator есть NAT - VRF-aware для данной версии, но для ISR4000, а не CSR..
Наверное, попробую и на железе, но надежды мало.

Трафик проходит по VFR интерфейсу, вижу срабатывает NAT, но после Ната трафик попадает на реальный роутер (Global) а не с VFR контекст (Видно по тому, что не работает, пока в Global не добавишь маршрут "ip route 10.1.1.0 255.255.255.0 GigabitEthernet0/0.23 172.1.2.3).
Итак, NAT сработал, пакет с измененным IP назначения выходит с правильного интерфейса GigabitEthernet0/0.23 и приходит на сервер. Все как бы хорошо.
Сервер отвечает, ответный пакет проходит через Inside/Outside VRF1, и выходит с Outside без NAT преобразования!!! (от 10.1.1.1, а не 5.5.5.5).
Близко, чуть чуть не хватает..
Как бы на это повлиять?

Понимаю, что есть более функциональные средства для LB, но Cisco NAT LB прекрасно справляется с поставленной задачей и сохраняет Source IP клиентов, а серверное ПО на это рассчитано. И протокол не HTTP (80,443), а TCP(5432) куда не вставишь "X-forwarder-for"
Спасибо за участие, в любом случае.

Pavel_Krotov, Pavel_Krotov, явно обратный маршрут укажите через интерфейс outside

Целевая железка Cisco 4331 IOS XE Software, Version 16.07.03,
Но пока я тестирую данный функционал в EVE-NG на CSR 1000V IOS XE 16.06.05.
И вижу что трафик проходит по VFR интерфейсу, вижу срабатывает NAT, но после Ната трафик выходит с реального роутера (Global) а не с VFR контекста (Если в Global добавить маршрут "ip route 10.1.1.0 255.255.255.0 GigabitEthernet0/0.23 172.1.2.3). А если на Global контексте нет маршрута к серверам 10.1.1.1 10.1.1.2 (а его там и не надо бы, поскольку интерфейс к серверам в vrf1), то трафик не отправляется.

Так же пробовал на эмуляции vIOS v15.5.3M, там вообще данный нат на VRF не срабатывает.

ну что могу сказать
такого параметра нет и в последнем ios-xe 16.9.4 тоже
а работает ли оно в железе проверять не буду.
И я бы все же эту задачу поручил nginx-у

Вот попробовал в на CSR 1000v 16.9.01.
В Cisco Feature Navigator есть NAT - VRF-aware для данной версии, но для ISR4000, а не CSR..
Наверное, попробую и на железе, но надежды мало.

Трафик проходит по VFR интерфейсу, вижу срабатывает NAT, но после Ната трафик попадает на реальный роутер (Global) а не с VFR контекст (Видно по тому, что не работает, пока в Global не добавишь маршрут "ip route 10.1.1.0 255.255.255.0 GigabitEthernet0/0.23 172.1.2.3).
Итак, NAT сработал, пакет с измененным IP назначения выходит с правильного интерфейса GigabitEthernet0/0.23 и приходит на сервер. Все как бы хорошо.
Сервер отвечает, ответный пакет проходит через Inside/Outside VRF1, и выходит с Outside без NAT преобразования!!! (от 10.1.1.1, а не 5.5.5.5).
Близко, чуть чуть не хватает..
Как бы на это повлиять?

Понимаю, что есть более функциональные средства для LB, но Cisco NAT LB прекрасно справляется с поставленной задачей и сохраняет Source IP клиентов, а серверное ПО на это рассчитано. И протокол не HTTP (80,443), а TCP(5432) куда не вставишь "X-forwarder-for"
Спасибо за участие, в любом случае.

Pavel_Krotov, Допускаю, что этот LB никому не уперся и конкретно этот извращенный вариант NAT-а просто не стали реализовывать.
Балансировать TCP умеет тот-же nginx, ha-proxy или даже iptables