Vpn l2tp/ipsec+shorewall не работает. Очень нужна помощь!

Всем привет!
Есть домашняя сеть (внутри квартиры), шлюз на CDS, настроен посредством shorewall.
Интернет работает и проблем не возникало, пока с одной из машин внутри сети не понадобилось подключится к vpn, для доступа в рабочую сеть. l2tp/ipsec соединение, все подключается, даже пинги ходят, но вот не работает. Если в /etc/shorewall/policy
Вместо
net all DROP
прописать
net all ACCEPT
то все работает.
Что нужно прописать, что бы не открывать все настеж?
Очень нужно! Новая работа, удаленный доступ, беда просто! спасайте!

Туннель описан в /etc/shorewall/tunnels?

Спасибо.
Ночью разобрался. Действительно туннель прописать нужно было и зону с транспорт.
/etc/shorewall/zones

zone3 ipsec mode=transport

Я почему то был уверен, что туннель нужно прописывать, только если шлюз является vpn сервером.

А вот и нифига не работает оказывается, внутренние ресурсы ради которых vpn и задуман, работают, а внешние нет, ползают в час по чайной ложке или вообще отваливаются.
Может что еще можете посоветовать?

ну, несмотря на сумбурное и неполное описание конфигурации и симптомов, рискну предположить проблемы с MTU. В общем-то обычно при создании IPSEC туннелей используется принудительная фрагментация, и поэтому внутренние ресурсы работают. А вот что там за пределами туннеля происходит - это отдельный и хороший вопрос. В shorewall включено CLAMPMSS? Что вообще за вариант IPSEC используется? На чем поднят, strongswan или что-то еще? Хотите помощи - давайте исходные данные.
Телепаты все слегли с ковидом :slight_smile:

Жаль телепатов :frowning:
Что за vpn пока узнать проблематично.
Про mtu, и clampmss вопрос изучу, за подсказку спасибо.
Есть мнение, что win что то косячит с маршрутизации, поскольку как выяснилось после перезагрузки в calculate и настройки vpn, там все работает отлично. тьфу, тьфу, тьфу, как говорится. :slight_smile:
Большое спасибо за подсказки.

В смысле - проблематично? Клиента вы на какой протокол настраиваете?

Ага. Тормозит и глючит под виндой. Картина заиграла новыми красками :slight_smile:
так, если это IKEv2, то подскажу еще одну штуку, недавно как раз налетел, в реализации StrongSwan, но может и у других подобное есть. Короче, там тема интересная. Есть такая вещь - rekeying, то есть пересогласование ключей протокола IPSEC. Так вот, с некоторых пор обнаружилось, что суровая правда жизни немного расходится с документацией. Раньше был общеизвестен эффект, что винда очень не любит, когда удаленный сервер предлагает пересогласовывать ключи - туннель вис или сбрасывался. Поэтому в мануале рекомендовалось для виндовых клиентов отключать принудительный rekeying по таймауту и расслабленно ждать, когда винда соизволит сама предложить. Если соизволит. А я тут недавно обнаружил, что в некоторых вариантах (да, я снова про StrongSwan свежей версии) ситуция ровно обратная - если рекей отключать, то начинается частое пересогласование ключей, да такое занятное, что в процессе теряются несколько пакетов из туннеля. Соответственно, если при этом сквозь туннель провешено шифрованное соединение (RDP, например, или SSH), то оно рвется или виснет.
Это первый нюанс “на посмотреть”.
И еще один, насчет маршрутизации. Если туннель является маршрутом по умолчанию, то маршруты при его поднятии прирастают сами и как по волшебству. А вот если через тоннель хочется прокинуть только какую-то подсеть, а весь остальной трафик гнать по-прежнему через свой шлюз по укмолчанию, вот тогда начинается трэш, угар и содомия.
Дело в том, что под линухом с маршрутами все гораздо удобнее управляется. А вот под виндами пичаль-бида. Надо или делать отдельный DHCP-сервер, который будет выдавать виндовым клиентам анонсы маршрутов, либо по виндами шуровать в PowerShell и шаманить примерно таким вот образом: “Add-VpnConnectionRoute -ConnectionName “VPN Connection Name” -DestinationPrefix 10.0.0.0/16”

Кстати сказать, работает оно кривовато, но уж что есть. Так что по поводу маршрутов стоить иметь в виду…