+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Cisco VPN 3002 и Mikrotik

Cisco VPN 3002 и Mikrotik, RouterOS

wildbill442

Guest

25.03.2006 05:41:00

Окей, у меня сеть на роутерах и беспроводных устройствах Mikrotik. Один из моих пользователей испытывает трудности с его Cisco VPN3002 concentrator. Соединение устанавливается, IPSEC VPN работает. Пользователь может пинговать устройства в своей внутренней сети, и tracert показывает, что все пакеты туннелируются в его сеть и выходят через его интернет-шлюз. Вот в чем загвоздка: пользователь не может аутентифицироваться в своей Windows 2003 домен-сети, не может подключиться через RDP (удаленный рабочий стол) к своим серверам, и не работают ни одно из сетевых приложений. У меня Mikrotik в качестве граничного роутера, все устройства в моей сети – Mikrotik (беспроводные мосты). Граничный роутер также выполняет базовое брандмауэрное обеспечение. WAN-порт имеет Point to Point ссылку с моим провайдером (/30 subnet). Сейчас я блокирую только входящие 25 (tcp), 135-139 (tcp/udp) и 445 (tcp). Сейчас, прежде чем кто-нибудь выпалит и скажет "ну вот почему он не может аутентифицироваться, вы блокируете NetBIOS и Microsoft Directory Services", он подключается к своей сети через VPN-туннель. Кроме того, что Mikrotik разбирает VPN-туннель и отбрасывает эти пакеты внутри туннеля (чего я до сих пор не видел, чтобы брандмауэр делал), я не могу объяснить это. И чтобы быть уверенным, я добавил правило Accept для его IP-адреса, чтобы все пакеты, предназначенные для его статического IP-адреса, принимались. Хочется передать это клиенту и сказать, что проблема в его внутренней сети, но когда он подключает то же устройство к другому провайдеру, всё работает безупречно. Вот схема сети: Cisco VPN3002 клиента → Tranzeo/Mikrotik/Zcomax CPE (я пробовал все три, результат один) → Mikrotik AP (2.4) → коммутатор → Mikrotik WDS-Station (5.8) → Mikrotik AP (5.8) → Layer3 коммутатор → Allot Netenforcer → Mikrotik Edge Router → оптоволоконная сеть MPLS провайдера. Я бьюсь головой о стену из-за этого, какие есть предложения? Я даже попросил его привезти свой Cisco 3002 с места работы в следующий узел, чтобы исключить 2.4-связь, подключил и получил те же результаты. Всё работало две недели подряд, мы сделали несколько сетевых обновлений. Мы заменили неиспользуемую 5.8 PtP-связь на 5.8 PtMP, удалили наш Cisco 2600 серии граничный роутер и заменили его на Mikrotik… И теперь у него проблемы… Мой мозг кипит, проверю завтра. - Билл

P.S. Я использую 2.9.17 на всех устройствах Mikrotik… и, полагаю, стоит упомянуть, что на моей сети NAT не применяется, все узлы получают публичные маршрутизируемые IP-адреса.

wildbill442

Guest

25.03.2006 19:12:00

Гигабитные порты — это “SysKonnect SK-98xx/SK-95xx Gigabit Ethernet”, по крайней мере, так указано в драйвере в RouterOS. Они встроены в материнскую плату ASUS, я уже не помню модель, но если это корень проблемы, я обязательно узнаю все детали, чтобы это можно было исправить или хотя бы избежать в будущем! — Билл

mag

Guest

25.03.2006 07:54:00

Это слишком сложно для простого ответа. Я бы проверил сквозную связность с помощью сканера портов и анализатора пакетов, если это возможно. Для сложного сочетания протоколов и приложений, возможно, установка прямого EoIP-туннеля через IPSec будет самым простым решением.

wildbill442 Guest	#4 0 25.03.2006 10:06:00 Ну да, анализатор пакетов был моим следующим шагом. Просто подумал, спрошу на форуме, сталкивался ли кто-нибудь с похожей проблемой.

andrewluck

Guest

25.03.2006 10:16:00

Кажется, это проблема с MTU. Ping работает, потому что пакеты маленькие. Как только начинаешь передавать что-то более сложное, всё рушится. У меня были проблемы с VPN-туннелями в более ранних версиях 2.9. Я не знаю о 2.9.17, потому что эту версию пропустил. Несколько советов: убедись, что MTU интерфейсов MT установлено в 1500. Iptables требует включённого отслеживания соединений для сборки фрагментов. MT, вероятно, то же самое. Уменьши MTU на клиенте. Убедись, что ты не блокируешь весь ICMP на шлюзе. Это вызовет проблемы с обнаружением пути. С уважением, Andrew.

wildbill442

Guest

25.03.2006 10:52:00

MTU установлены на 1500, ICMP разрешен по всей сети, и мы пытались уменьшить MTU, но я снова предложу это. Мне кажется, мы пробовали значения MTU 1300, 1400, 1480 на Cisco 3002. Я перепроверю и уточню. Connection Tracking был включен, я отключил его сегодня, так как думал, что он может способствовать проблеме. Оказалось, что это не так, поэтому я снова включил. Я пробовал пинговать с нагрузкой, вот результаты… /ping 66.xx.xxx.1 size=1500
66.xx.xxx.1 1500 byte ping: ttl=64 time=70 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=12 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=10 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=12 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=11 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=25 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=34 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=14 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=12 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=12 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=12 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=48 ms
66.xx.xxx.1 1500 byte ping: ttl=64 time=13 ms Это пинг с 2.4 AP до шлюза с пакетом размером 1500 байт. И вот еще забавный факт: когда используется программный VPN-клиент Cisco, все работает отлично.

andrewluck

Guest

25.03.2006 14:37:00

Предполагал, что клиентское устройство использует Cisco VPN client, а сервер — 3002. Не заметил этого из твоего первоначального сообщения. Клиентский софт выполняет инкапсуляцию? Это ESP/AH? Твой пинг на 1500 байт будет фрагментироваться. Какой максимальный размер пакета можно пропустить с установленным битом DF? Что пишет лог на VPN-сервере? Показывает ли, что пакеты отбрасываются? Столько вопросов, честное слово! Ненавижу IPSEC! Обожаю, что он делает, когда работает, но на этом всё. С уважением, Andrew.

wildbill442

Guest

25.03.2006 16:01:00

Да, это аппаратный VPN Access Gateway 3002, который подключается к их VPN Access Concentrator 3005. Вот пинг на 1500 байт от точки доступа к шлюзу с установленным битом "не фрагментировать". (Это не проходит через 2.4 канала, я не на месте, поэтому не могу выполнить пинг с самого клиентского сайта.) Думаю, Cisco 3002 успешно устанавливает фазу 1 и фазу 2, но попробую посмотреть логи.. /ping 66.60.188.1 size=1500 do-not-fragment
66.60.188.1 пинг на 1500 байт: ttl=64 time=55 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=32 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=12 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=55 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=45 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=14 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=26 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=10 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=12 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=13 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=15 мс
66.60.188.1 пинг на 1500 байт: ttl=64 time=81 мс
Отправлено 12 пакетов, получено 12 пакетов, потеря пакетов 0%
round-trip min/avg/max = 10/30.8/81 мс

andrewluck

Guest

25.03.2006 16:48:00

Еще кое-что пришло в голову: повторить это с сайта клиента через VPN, чтобы посмотреть, какой размер пакета на самом деле пройдет по туннелю. А потом уже соответствующим образом уменьшить MTU на их клиентских устройствах. С уважением, Andrew.

wildbill442

Guest

#10

25.03.2006 17:16:00

Думаешь, проблема в MTU discovery? Посмотрю, что можно сделать. Клиент сегодня будет на другом участке сети, который мы недавно подключили, и он там всё проверит. Посмотрим, что получится. Попрошу его поиграться с размерами MTU.

wildbill442

Guest

#11

25.03.2006 19:09:00

Ну что, похоже на проблему с MTU... но я никак не могу понять, где. Максимальный размер пакета, который он может пинговать до своего VPN-концентратора через VPN-клиент 3002 Hardware, – 1418 байт. Я могу пинговать его IP-адрес с моего роутера с пакетом в 1500 байт во внутренней сети. Я попросил его снизить MTU до 1400, но изменения нет. Похоже, проблема в портах WAN/LAN нашего роутера. Когда я открываю свойства этих портов и проверяю статус, автосогласование показывает “неполное”, скорость – “неизвестна”, а индикатор полнодуплексного соединения серый. Это порты материнской платы, которые поддерживают 10/100/1000. Сейчас иду к серверу, чтобы переключить их на два порта RB44 10/100, чтобы посмотреть, решит ли это проблему. В общем, я уже почти уверен, что так и будет.

wildbill442

Guest

#12

26.03.2006 01:08:00

Ладно, переключение интерфейсов ничего не дало. Поменял Mikrotik edge router на старый Cisco router, всё равно не могу запустить клиента. Единственное изменение, которое я пока не откатил, — это апдейд до 2.9.17… Хотелось бы попробовать откатиться, но кнопка "downgrade" в winbox, похоже, не стоит того, чтобы её даже тратить на неё код. Заметил, что не могу пинговать свои Mikrotik роутеры из интернета с пакетом размером 1500 байт. По крайней мере, те, что работают на 2.9.17. У нескольких моих старых RB230, которые уже вышли из периода обновления, всё ещё стоит 2.8.xx, и их можно пинговать с пакетом размером 1500 байт. Есть какие-нибудь идеи, почему так? Может, в 2.9.17 что-то есть, что не позволяет роутеру принимать пинг размером 1500 байт?

andrewluck

Guest

#13

26.03.2006 10:52:00

Слышал, что в некоторых версиях 2.9 была проблема со сборкой фрагментов. Я могу пинговать свой 2.9.18 роутер из внутренней сети с пакетами размером 1500 и 1600 байт. 1600-байтные пакеты должны фрагментироваться, так что, видимо, у этой версии этой проблемы нет. С уважением, Andrew.

wildbill442

Guest

#14

27.03.2006 16:52:00

Да, я могу воспроизвести это тоже. Из внутренней сети. Это происходит, когда пакеты приходят через WAN-интерфейс через edge router – тогда происходит таймаут. Я могу пропинговать роутер пакетом в 1500 байт из WAN. Свитч, мои серверы и любое другое устройство, отличное от Mikrotik, из WAN. Я также могу пропинговать любое устройство Mikrotik версии до 2.9.xx, но 2.9.17 роутеры я не могу пропинговать пакетом в 1500 байт из WAN. Я обновил одно из устройств до 2.9.18, но оно всё равно не принимает пинг в 1500 байт... Я перешлю эту тему в поддержку.

wildbill442

Guest

#15

31.03.2006 19:38:00

В итоге оказалось, что проблема была на стороне клиента. Установили Cisco VPN-клиент на все хост-машины, и проблема ушла… Мой единственный вывод в том, что установка VPN-клиента как-то исправила проблему с TCP/IP стеком или MTU на локальной машине. Просто установили клиент, не использовали его для подключения к VPN, а потом железный клиент начал нормально пропускать трафик. Так что, как тут не удивишься. Думаю, это можно записать в раздел "WTF".

andrewluck Guest	#16 0 01.04.2006 13:56:00 Ты прав, вот это да. Рад, что у тебя удалось исправить. У меня тоже с TCP инкапсуляцией разобрался. Оказалось, неправильная конфигурация маршрута на Cisco 2600. С уважением, Andrew.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры