У нас есть межсетевой экран Cisco ASA 5510 с установленным модулем IPS.
У нас есть клиент, к которому мы должны подключиться через VPN к его сети, чтобы обмениваться файлами через FTP. Мы используем клиент Cisco VPN (версия 5.0.01.0600) на наших локальных рабочих станциях, которые находятся за брандмауэром и подпадают под действие IPS.
VPN-клиент успешно подключился к удаленному сайту. Однако, когда мы начинаем передачу файлов по FTP, мы можем загрузить от 150 до 200 КБ данных, и тогда все останавливается. Через минуту сеанс VPN прерывается.
Я думаю, что изолировал это от проблемы IPS, временно отключив политику обслуживания на ASA для IPS с помощью следующей команды:
список доступа IPS строка 1 расширенное разрешение ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 неактивно
После того, как эта команда была введена, я установил VPN на удаленный сайт и успешно передал весь файл.
Все еще подключенный к сеансу VPN и FTP, я дал команду для включения IPS:
список доступа IPS строка 1 расширенное разрешение ip 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0
Передача файла была предпринята еще раз, и снова была успешной, поэтому я закрыл FTP-сеанс и снова открыл его, оставив открытым тот же сеанс VPN. Эта передача файла также прошла успешно. Это говорит мне, что никакие программы FTP не фильтруются и не вызывают проблемы. Кроме того, мы ежедневно без проблем используем FTP для обмена файлами со многими сайтами.
Затем я отключил исходный сеанс VPN, который был установлен, когда список доступа был неактивен, и повторно подключил сеанс VPN, теперь с активным списком доступа. После запуска FTP передача файла остановилась после 150К.
Мне кажется, что IPS блокирует или каким-то образом мешает первоначальной настройке VPN на удаленный сайт.
Это началось только на прошлой неделе, после применения последних обновлений сигнатур IPS (sig version 407.0). Наша предыдущая sig-версия была выпущена 95 дней назад, потому что система не обновлялась автоматически.
Любые идеи о том, что может вызвать эту проблему?
Попробуйте установить MTU на отправляющей стороне (на самом деле он, вероятно, понадобится обеим сторонам). Возможно, существует устройство, которое либо не генерирует, либо неправильно передает пакеты обнаружения Path MTU. Если понижение mtu, скажем, до 1350 на обоих концах исправляет это, проверьте, есть ли у вас ACL, блокирующие ICMP.
Тот факт, что он вообще начинает передачу, указывает на то, что у него нет проблем с установкой части данных FTP-сеанса, что исключает ACL, блокирующую вход или выход. Сам сеанс VPN, прерывающийся во время передачи большого файла, похоже, указывает на то, что IPS выполняет действие над соединением (хотя вы могли бы подумать, что он просто завершит сеанс FTP, но действия настраиваются, так что кто знает?) Если вы думаете, что это так. ваша IPS отбрасывает сеанс VPN, у вас должны быть журналы для просмотра и предупреждения IPS, если это ваша IPS отбрасывает его. Ваш IPS работает в беспорядочном режиме (в основном режиме IDS) или в встроенном режиме? Насколько мне известно, он не может сбросить трафик, если он находится в неразборчивом режиме, поскольку он получает только копию трафика. Поскольку до сих пор он работал без изменений на вашей стороне (кроме обновления подписи), я хотел бы спросить клиента, изменили ли они что-либо на своей стороне, запрещая передачу больших файлов более определенного размера; тем более что вы сказали, что FTP на другие сайты без проблем. Если это только один клиент, можете поспорить, что проблема в его стороне.
В подписи 407 нет ничего, связанного с FTP. Обычно, когда у вас возникают подобные проблемы с FTP, которые начинаются, а затем останавливаются, это обычно связано с активным и пассивным ftp. Какой ftp-клиент вы используете? Попробуйте изменить его с активного на пассивный на своем FTP-клиенте и посмотрите, поможет ли это.
В активном FTP место, к которому вы выполняете FTP-соединение, инициирует передачу данных через другой порт, чем входящий запрос ... вот почему он обычно блокируется вашим брандмауэром.
В пассивном FTP вы инициируете передачу данных на другой порт, и это работает, потому что большинство брандмауэров разрешают все исходящие сообщения.
Отредактировано для добавления: Подписи накопительные. Хотя обновление 407 не показывает ничего, связанного с FTP, каждое второе обновление с 95 дней назад до настоящего времени могло что-то содержать. Я не собираюсь исследовать каждое обновление, чтобы узнать это для вас;)
Я также должен спросить из-за ваших других вопросов по этому поводу ... используете ли вы проверки по умолчанию на этом 5510 в дополнение к перенаправлению трафика на модуль IPS? Если да, то это действительно не нужно.
MTU или масштабирование окна могут быть причинами
Если ftp-передача - PASV, вам необходимо включить проверку пакетов и соответствующие ACL на межсетевом экране.
Сначала сделайте резервную копию вашей запущенной конфигурации!
Это процедура, которую я использовал для проверки пакетов на нашем cisco ASA 5505.
любой список доступа может иметь несколько записей, вашим vpn-клиентам будет выделена подсеть
Первая строка acl для IPS должна запрещать проверку трафика в / из подсети клиента vpn. Вторая строка acl должна включать IPS для другого трафика, возможно, стоит исключить другой трафик, например. isakmp, gre, esp, ah и т. д. от проверки, иначе вам нужно было бы увидеть больше вашей конфигурации
Я бы сказал, что забудьте об использовании пассивного или активного FTP. Я ненавижу двойную природу FTPS и FTP. Вместо этого загрузите Сервер WinSSHD и запустите SFTP-сервер на одном порту: порт 22. Таким образом, вы имеете дело только с одним отверстием.
Подключитесь к нему с помощью Tunnelier клиент.
Была еще одна идея:
Существует 2 типа Cisco VPN: IPSec через UDP и IPSec через TCP. Скорее всего, вы используете версию TCP, которая может вызвать потерю пакетов в сценарии NAT. Версия VPN для UDP более стабильна, потому что заголовки TCP имеют другую оболочку. При использовании версии TCP могут возникнуть проблемы с трансляцией NAT. Это очень сложно объяснить, но я бы попытался отредактировать тип VPN протокола на стороне клиента ... измените его на IPSec через UDP.
По сути, другие ответы в этом потоке предлагают изменить настройки MTU, чтобы попытаться взломать / обойти проблемы IPSec через TCP, которые могут возникнуть в NAT. Это не так. Способ состоит в том, чтобы использовать IPSec поверх UDP, и тогда MTU не имеет значения.