Проблемы управления в стороне, я думаю, что подавляющее большинство нетехнических пользователей является просто просто стойким к изменению. Я попытался развернуть Thunderbird и Firefox в одной компании, но хорошая пропорция штата просто не могла получить их голову вокруг различий между Thunderbird и Outlook (никакой включенный Exchange, просто сервер IMAP).
компания не имела возможности выполнять обучение на Thunderbird (кроме выполнения его самостоятельно не было действительно никого для получения, чтобы сделать это), таким образом, проект реализовал часть, с банкой - действительно укомплектовывают использование одного Терминального сервера Fx и Thunderbird и остальными использующими другой TS с Outlook и IE.
Нет ничего в 407 подписях, связанных с FTP. Обычно, когда у Вас есть проблемы FTP как это, которые запускаются и затем останавливаются, это обычно связывается с активным по сравнению с пассивным ftp. Какой клиент ftp Вы используете? Попытайтесь изменить его от активного до пассивного на Вашем клиенте FTP и посмотрите, помогает ли это.
В активном FTP место, к которому Вы являетесь FTPing, инициирует передачу данных на другом порте затем входящий запрос..., который является, почему это обычно блокируется Вашим брандмауэром.
В пассивном FTP ВЫ инициируете передачу данных к другому порту, и это работает, потому что большая часть брандмауэра позволяет всему исходящему происходить.
Отредактированный для добавления: подписи кумулятивны. В то время как эти 407 обновлений не показывают, что что-либо связанное с FTP, любым обновлением от 95 дней назад до настоящего времени, могло иметь что-то. Я не собираюсь исследовать каждое обновление для обнаружения для Вас хотя ;)
Я также должен спросить из-за Ваших других вопросов об этом... Вы использующий проверки по умолчанию на этом 5510 в дополнение к занимательному трафику к модулю IPS? Если Вы, Вы действительно не должны.
То, что это начинает передачу вообще, указывает, что не имеет никакой проблемы при установлении части данных сеанса FTP, который исключает ACL, блокирующий соединение в или. Сама сессия VPN, отбрасывающая во время большой передачи файлов, действительно кажется, указывает на IPS, принимающий меры на соединении (хотя Вы думали бы, что это только завершит сеанс FTP, но действия являются настраиваемыми поэтому, кто знает?), Если Вы думаете, что это - Ваш IPS, отбрасывающий сессию VPN, у Вас должны быть журналы для просмотра и предупреждения IPS, если это - IPS, отбрасывающий его. Ваш IPS работает в неразборчивом режиме (в основном режим IDS) или встроенный режим? Насколько я знаю, это не может отбросить трафик, если это находится в неразборчивом режиме, так как это только получает копию трафика. Так как это работало без изменений над Вашим концом к настоящему времени (кроме обновления подписи), я спросил бы клиента, если бы они изменили что-нибудь на своем конце, запрещающем большие передачи файлов свыше определенного размера; тем более, что Вы сказали Вас FTP другим сайтам без проблемы. Если это только с этим клиентом, можно держать пари, что проблема находится на их конце.
Попытайтесь записать MTU на передающей стороне (на самом деле, обеим сторонам, вероятно, будет нужен он). Мог ли быть существует устройство, это или не генерирует или передает Путь пакеты исследования MTU правильно. Если понижение mtu к, скажем, 1350 на обоих концах фиксирует его, затем займитесь расследованиями, есть ли у Вас ACLs блокирующийся ICMP.
Я сказал бы, забывают использовать Пассивный или Активный FTP. Я ненавижу двухпортовую природу FTPS и FTP. Вместо этого загрузите сервер WinSSHD и выполните сервер SFTP на единственном порте: порт 22. Тем путем Вы только имеете дело с единственным крошечным отверстием.
Подключите к нему использование клиент Tunnelier.
Если передача ftp является PASV, необходимо включить проверку пакетов, и соответствующий ACL в брандмауэре.
Возьмите резервное копирование Вас выполняющий конфигурацию сначала!
Это - процедура, я взял наш 5505 ASA Cisco для проверки пакетов
Просто имел другую идею:
Существует 2 вида Cisco VPN: IPSec по UDP и IPSec по TCP. Скорее всего, Вы используете версию TCP, которая может вызвать потерю пакетов в сценарии NAT. Версия UDP VPN более стабильна, потому что заголовки TCP перенесены по-другому. Используя версию TCP у Вас могут быть проблемы с трансляцией NAT. Его очень твердое для объяснения, но я попытался бы редактировать клиентский протокол, тип VPN... изменяет его на IPSec по UDP.
В основном другие ответы на этом потоке предлагают изменить настройки MTU для попытки к взлому/обходному решению IPSec по проблемам TCP, которые могут возникнуть в NAT. Это не путь. Путь состоит в том, чтобы использовать IPSec по UDP, и затем MTU не имеет значения.
любой список доступа может иметь многократные въезды, Ваши клиенты VPN будут выделены подсеть
строка один из acl для IPS должен отклонить контроль трафика к/от строке подсети клиента VPN, которую два из acl должны включить IPS для другого трафика, это может стоить, исключая другой трафик, например, isakmp, gre, особенно, ах и т.д. от того, чтобы быть осмотренным иначе должен был бы видеть больше Вашей конфигурации