OpenVPN недоступна внутренняя сеть

GlooM14

Приветствую!

Настроил OpenVPN сервер, завел тестового пользователя, успешно подключился к серверу. При создании соединения через мастер принял исправления в конфигу фаервола.

IPv4 Tunnel Network = 10.0.8.0/24
IPv4 Local network(s) = 192.168.1.0/24

При подключении клиент успешно получает адрес 10.0.8.2. Пинги до 10.0.8.1 проходят, по этому же адресу клиент в браузере открывает админку pfsense. То есть, на сам pfsense извне я попадаю. Но проблема - никакой адрес из сегмента 192.168.1.0/24 не доступен. Ничего из интерфейса vpn в lan сегмент не ходит. При выполнении команды tracert видно, что пакет пытается идти через 10.0.8.1, что правильно, но на пинги ответа нет.

На всех разделах фаервола (LAN, WAN, OpenVPN) сделаны правила "allow any to any".

Подскажите где ковырять решение?!

pigbrother

@gloom14 said in OpenVPN недоступна внутренняя сеть:

Подскажите где ковырять решение?!

Для начала.

pfSense - default gateway для 192.168.1.0/24?
На ресурсах 92.168.1.0/24 отключен\настроен брандмауэр?
Запустите клиента OpenVPN с правами админа (в послндних версиях это не обязательно, но все же).

@gloom14 said in OpenVPN недоступна внутренняя сеть:

На всех разделах фаервола (LAN, WAN, OpenVPN) сделаны правила "allow any to any".

Достачно правила для OpenVPN. Для WAN такое правило опасно.

igroykt

Видимо 10.0.8.1 нормально проходит до устройств в сети 192.168.1.0/24 но устройства из этой сети не могут достучаться до 10.0.8.1 поскольку нет маршрута. надо либо в маршрутизатор сети 192.168.1.0/24 добавить маршрут (тогда раздаст по dhcp) или прописать отдельно на каждом хосте сети. Вообще бы порекомендовал перейти на peer to peer подключение посколько оно больше заточено под объединение сетей. Remote access больше подходит для подключение одиночных устройств (например ноутбук сотрудника должен получить доступ к сети 10.0.8.0/24 откуда то с гаваев).

GlooM14

Всем спасибо!

Ошибку допустил глупую, т.к. настраивал среди ночи. Косяк был в том, что этот шлюз настраивался как новый в той же подсети, которую обслуживает сейчас старый. Соответственно он имел параллельный отдельный LAN адрес и WAN, но у клиентов гейтом пробит старый, поэтому ответные пакеты шли в него. Как только одному клиенту гейт изменил на адрес нового шлюза - все сразу заработало.