Мы приобрели небольшую компанию, которая использует межсетевой экран 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: Какую команду мне нужно запустить через интерфейс командной строки на Sonicwall, чтобы получить полнотекстовый вывод текущей конфигурации?
Спасибо заранее за любую помощь.
Определена ли каждая из рассматриваемых подсетей как подсети VPN в конфигурации сетевого объекта Sonicwall? Если они классифицируются как LAN или WAN, то ваши правила «LAN to VPN» не будут применяться к ним, даже если они определены в туннеле VPN. Я не уверен, относится ли это к вашей модели (у нас TZ17 / 8/90 и 3060s, но если она работает под SonicOS, я думаю, что да)
Спасибо за комментарии, Кевин, я подумал об этом, но на самом деле протестировал с использованием объекта адреса для подсети, которая работала, классифицируя объект, в свою очередь, как объект LAN, WAN или VPN, но это не имело значения, он работал во всех случаях. Казалось бы, автоматически добавляемые правила VPN для VPN между сайтами игнорируют то, как вы вручную классифицируете объект.
Короче говоря, это тестирование заставляло меня все больше и больше сомневаться, была ли проблема в Sonicwall на самом деле - в конце концов, это не так. После долгого времени Cisco ASA на другом конце управляется службой хостинга и, следовательно, находится вне моего контроля. Посмотрев на конфигурацию ASA, мы обнаружили, что гений, добавивший правила для другого конца VPN-соединения, поместил правило доступа после правила «запретить все». Перемещение правила доступа перед правилом запретить все сразу решило проблему.