Мы приобрели небольшую компанию, которая использует межсетевой экран Sonicwall PRO 1260, и я настроил туннель Site-to-Site VPN от Sonciwall до нашего межсетевого экрана Cisco ASA. За межсетевым экраном Cisco ASA у меня 8 разных подсетей. Я настроил VPN-подключение на Sonicwall для использования группы адресных объектов, которая содержит все необходимые подсети.
VPN-туннель от Sonicwall до Cisco ASA устанавливается нормально, и у меня есть полное подключение от удаленного сайта до «подсети 1». Из «подсети 2» (и всех остальных) единственный трафик, который проходит в удаленную сеть, — это ICMP (ping), http и https.
Я знаю, что это кричит «правила доступа», но я потратил часы на изучение Sonicwall и не могу найти правила доступа, которые бы блокировали весь трафик, кроме упомянутых выше служб. Sonicwall автоматически создает правила доступа из LAN > VPN и VPN > LAN, которые говорят «разрешить любой хост, любую службу, все время» — эти правила нельзя изменить, удалить или деактивировать (только удалив VPN).
У меня точно такая же конфигурация для 5 других удаленных сайтов, использующих VPN типа «сеть-сеть», подключенных к тому же Cisco ASA, и все работает нормально, однако эти сайты используют межсетевые экраны Fortigate, поэтому я уверен, что это связано с Sonicwall.
Вопрос 1: Сталкивался ли кто-нибудь с такой же проблемой и как вы ее решили?
Вопрос 2: Какую команду мне нужно запустить через CLI на Sonicwall, чтобы получить полный текстовый вывод текущей конфигурации?
Спасибо заранее за любую помощь.
решение1
Определены ли у вас все рассматриваемые подсети как VPN-подсети в конфигурации сетевого объекта Sonicwall? Если вы классифицируете их как LAN или WAN, то ваши правила "LAN to VPN" не будут применяться к ним, даже если вы определили их в VPN-туннеле. Я не уверен, применимо ли это к вашей модели (наши — TZ17/8/90 и 3060, но если она работает под управлением SonicOS, то, думаю, применимо).
решение2
Спасибо за комментарии, Кевин, я думал об этом, но на самом деле протестировал использование объекта Address для подсети, который работал, классифицируя объект по очереди как объект LAN, WAN или VPN, но это не имело значения, это работало во всех случаях. Похоже, что автоматически добавленные правила VPN для VPN site-to-site игнорируют то, как вы вручную классифицируете объект.
Короче говоря, это тестирование заставило меня все больше и больше сомневаться, действительно ли Sonicwall был проблемой - в конце концов, это не так. После долгих раздумий Cisco ASA на другом конце управляется хостинговой службой и, следовательно, находится вне моего контроля. После просмотра конфигурации ASA мы обнаружили, что гений, который добавил правила для другого конца VPN-подключения, поместил правило доступа после правила «запретить все». Перемещение правила доступа перед правилом «запретить все» немедленно решило проблему.