res2001

Ответ в комментариях: Почему клиент не подключается к серверу OpenVPN?

В винде по умолчанию при установке openvpn добавляется только 1 виртуальный tun/tap адаптер, чтоб запустить несколько экземпляров openvpn нужно для каждого экземпляра использовать свой виртуальный адаптер.
В комплекте установки есть утилита tapctl, позволяющая добавлять адаптеры, а так же в меню пуск есть ярлыки для запуска этой утилиты с правильными параметрами.

На самом деле в актуальной версии openvpn по умолчанию устанавливается 3 виртуальных адаптера, но каждый из них разного типа: tun, tap, dco. Похоже можно использовать разные типы адаптеров, изменив опцию dev.
На сколько помню, раньше был только 1 тип адаптера: tun. Его я и использовал всегда. На сколько хорошо работают остальные типы адаптеров под виндой - не в курсе.

Кроме того OpenVPN устанавливает свои службы, которые удобно использовать на серверах, когда нужно, чтоб openvpn стартовал автоматически при старте винды, без вмешательства пользователя.

Что за адрес у вас указан в опции server? Тут обычно указывают какую-то серую подсеть для того, что бы ее адреса использовались внутри ВПН. Адреса из под сети 169.254.х.х обычно используются при проблемах с назначением адреса (ошибка получения по DHCP и т.п.). Думаю не стоит использовать эту подсеть в принципе.

Зачем вам ВПН внутри локальной сети (192.168.1.158)?

Клиент пытается подключиться к серверу 192.168.1.158:1194.
Скорее всего, ошибка связана с тем, что сервер не доступен по указанному адресу.

Подключение ВПН на клиенте и сервере создает дополнительный виртуальный сетевой адаптер со своим IP адресом. Программное обеспечение ВПН отвечает только за трафик, который попадает внутрь ВПН. Все остальное конфигурируется стандартными средствами: таблицы маршрутизации, фаерволы, NAT. В openvpn некоторые настройки таблиц маршрутизации можно (нужно) указывать в конфиге ВПН, а не напрямую править таблицы в ОС. Все это относится к любой ОС - принципы работы openvpn одинаковы в линукс и винде.

Обычно конфиг клиента делают максимально "легким". Там указывают только необходимые опции для подключения к серверу (протокол, адрес и порт сервера, параметры шифрования и логирования). Все что касается маршрутизации между сетями (route, push route) убирается в конфиг сервера.
Опция push "route ..." - добавляет маршрут на удаленной стороне. Т.е. если опция указана в конфиге сервера, то маршрут добавляется на стороне клиента.
Для добавления маршрута на стороне сервера в конфиге сервера используется опция: route

CCD файлы:
У вас не правильный синтаксис для опции ifconfig-push.
Правильный такой: ifconfig-push client_ip mask
Т.е. IP сервера не требуется указывать.
В опции iroute указываем сети за этим конкретным клиентом. Эти маршруты добавятся в таблицу маршрутизации сервера при подключении клиента. Не нужно дублировать эти маршруты опциями route в основном конфиге сервера.
Так же можно в CCD файле указать опцию push route для добавления маршрута клиенту для сети за сервером. Обычно push route указывают в основном конфиге сервера и она работает для всех клиентов.

Но! Что бы сети за клиентом и сервером могли друг друга видеть они должны знать по каким маршрутам передавать трафик друг для друга. Если ВПН сервер и ВПН клиент являются для своих сетей шлюзами по умолчанию - то проблемы нет, компы внутри сетей и так будут слать весь трафик через них. Но если ВПН сервер и/или ВПН клиент не являются шлюзами по умолчанию для своих сетей, то требуется добавить дополнительные маршурты для соседних сетей через ВПН сервер/клиент. Централизованно маршруты можно добавить через опции DHCP, возможно политиками AD.

Фаерволы на любом узле могут блокировать трафик. Для отладки взаимодействия сетей через ВПН рекомендую сначала отключить фаерволы на всех тестовых устройствах. После того как настроите маршрутизацию фаерволы включайте по одному, сразу проверяйте работу и вносите изменения в правила фаервола, если необходимо.

После того как вы добились соединения ВПН клиента с сервером все остальное - это правильная настройка маршрутизации и фаерволов.

Встречные вопросы:
1. На сколько понял ВПН поднимается и, например, пинги идут с ВПН IP сервера на ВПН IP клиента и наоборот?
2. Значит проблема в доступе из сети клиента в сеть сервера и наоборот?
3. Т.к. ВПН сервер и клиент подняты на роутерах, то предполагаю, что эти же роутеры являются шлюзами по умолчанию для компов в своих сетях?

Если на все вопросы ответ - Да.
То проблема в блокировке трафика фаерволами. Блокировка может происходить как на роутерах так и на конечных узлах локальными фаерами.
Проблемы с маршрутизацией быть не должно, т.к. роутеры - шлюзы по умолчанию в своих сетях.
Выберите по компу в обеих сетях, убедитесь, что на этих тестовых компах роутеры являются шлюзами по умолчанию, отключите на них локальные фаерволы и тестируйте. Предварительно убедитесь, что на роутерах фаервол не блокирует ВПН трафик. Так же было бы полезно во время теста смотреть на роутерах вывод tcpdump по ВПН интерфейсу.

Типичная ошибка. ВПН сервер прописал себя маршрутом по умолчанию для клиента. И теперь все пакеты в интернет идут на ВПН сервер.
В этом виновата опция
push "redirect-gateway def1 bypass-dhcp"
Она делает не то, что вы думаете.
Просто закоментируйте эту опцию и перезагрузите сервер.

добавляя опции

Это странно, мягко говоря. Похоже вы добились прямо противоположного. Опция
push redirect-gateway def1 bypass-dhcp
Делает ВПН сервер шлюзом по умолчанию на клиентах. Так что интернет у клиента будет идти через ВПН.
Вторая опция просто добавляет DNS сервер клиенту.
Что бы клиент использовал свой интернет - удалите обе опции из конфига сервера.

Все это легко проверяется - соединитесь с ВПН и посмотрите таблицу маршрутизации на клиенте стандартными средствами. Если маршрут по умолчанию будет через ВПН сервер - значит клиент будет получать интернет через ВПН.

Включение NAT на ВПН интерфейсе то же не обязательно. Использовать его или нет - зависит от текущих настроек сети за клиентом и сервером и от того для чего вы используете ВПН.