The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Проблема с удаленным Remote Access VPN-соединением"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение [Проследить за развитием треда]

"Проблема с удаленным Remote Access VPN-соединением"  
Сообщение от Kir_rus email(ok) on 14-Ноя-06, 16:22 
Добрый день!
Вот столкнулся со следующей проблемой. В общем, есть PIX 525 (7.0.2 ОС), настроенный на оба типа VPN: LAN-to-LAN и Remote Access. L2L работает нормально. Удаленные клиенты с использованием Cisco VPN Client и настроенного на Пиксе RA VPN туннеля успешно подключаются и аутентифицируются, однако не могут пропинговать машины в сети inside за PIX.
Вот конфиг:

: Saved
:
PIX Version 7.0(2)
names
!
interface Ethernet0
  nameif outside
  security-level 0
  ip address 217.72.145.187 255.255.255.192
!
interface Ethernet1
  nameif inside
  security-level 100
  ip address 192.168.1.1 255.255.255.0
!
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd qZMF4yz9mcSUGIpE encrypted
hostname MyPix
domain-name ocv.ru
ftp mode passive
object-group service DNS tcp-udp
  description DNS Group
  port-object eq domain
object-group service WEB tcp
  description WEB Group
  port-object eq www
object-group icmp-type Ping
  description PING Group
  icmp-object echo
  icmp-object echo-reply
object-group network RemoteOffice
  network-object 172.30.0.0 255.255.240.0
  network-object 172.30.128.0 255.255.240.0
object-group network MainOffice
  network-object 192.168.1.0 255.255.255.0
object-group network VPNPool
  network-object 192.168.3.0 255.255.255.0
access-list L2LVPN extended permit ip object-group MainOffice object-group Remot
eOffice
access-list NoNAT extended permit ip object-group MainOffice object-group Remote
Office
access-list NoNAT extended permit ip object-group MainOffice object-group VPNPoo
l
access-list vpn_split extended permit ip object-group VPNPool object-group MainO
ffice
access-list vpn_split extended deny ip object-group VPNPool any
pager lines 24
logging enable
mtu outside 1500
mtu inside 1500
ip local pool ForMobile 192.168.3.2-192.168.3.254
no failover
monitor-interface outside
monitor-interface inside
asdm image flash:/asdm
asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list NoNAT
route outside 0.0.0.0 0.0.0.0 217.72.145.129 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
group-policy VPNUsers internal
group-policy VPNUsers attributes
  split-tunnel-policy tunnelspecified
  split-tunnel-network-list value vpn_split
username admin password Bd5qFFFIkcr503pw encrypted privilege 15
username secoff password ms4U5bsPtxPNnRoF encrypted
username VPNUser password IqY6lTColo8VIF24 encrypted
aaa authentication enable console LOCAL
http server enable
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp
crypto ipsec transform-set OCV esp-3des esp-sha-hmac
crypto dynamic-map RemoteMain 70 set transform-set OCV
crypto dynamic-map RemoteMain 70 set reverse-route
crypto map OfficeMain 60 match address L2LVPN
crypto map OfficeMain 60 set peer 217.72.145.186
crypto map OfficeMain 60 set transform-set OCV
crypto map OfficeMain 70 ipsec-isakmp dynamic RemoteMain
crypto map OfficeMain interface outside
isakmp enable outside
isakmp policy 15 authentication pre-share
isakmp policy 15 encryption 3des
isakmp policy 15 hash sha
isakmp policy 15 group 1
isakmp policy 15 lifetime 86400
isakmp policy 65535 authentication pre-share
isakmp policy 65535 encryption 3des
isakmp policy 65535 hash sha
isakmp policy 65535 group 2
isakmp policy 65535 lifetime 86400
telnet timeout 5
ssh 212.45.3.160 255.255.255.248 outside
ssh 85.93.156.116 255.255.255.252 outside
ssh 212.72.145.128 255.255.255.192 outside
ssh 192.168.1.0 255.255.255.0 inside
ssh timeout 5
console timeout 0
tunnel-group 217.72.145.186 type ipsec-l2l
tunnel-group 217.72.145.186 ipsec-attributes
  pre-shared-key *
tunnel-group VPNUsers type ipsec-ra
tunnel-group VPNUsers general-attributes
  address-pool ForMobile
  default-group-policy VPNUsers
tunnel-group VPNUsers ipsec-attributes
  pre-shared-key *
!
class-map inspection_default
  match default-inspection-traffic
!
!
policy-map global_policy
  class inspection_default
    inspect dns maximum-length 512
    inspect ftp
    inspect h323 h225
    inspect h323 ras
    inspect netbios
    inspect rsh
    inspect rtsp
    inspect skinny
    inspect esmtp
    inspect sqlnet
    inspect sunrpc
    inspect tftp
    inspect sip
    inspect xdmcp
!
service-policy global_policy global
ntp server 194.149.67.130
ntp server 62.117.76.139
ntp server 80.246.19.29
ntp server 195.230.70.112
privilege cmd level 1 mode exec command logout
privilege cmd level 1 mode exec command disable
privilege cmd level 1 mode webvpn command logout-message
Cryptochecksum:2da68479115d866800d3e0cac175c141
: end

Настроено расщепление туннеля, чтобы у клиента после подключения RA VPN не пропадало свое соединение с его локальной сетью. Теперь, значит, клиент получает адрес из пула, к примеру 192.168.3.2, маску /24, потом пытается пинговать ноут, который находится в inside и имеет адрес 192.168.1.2 - никакого результата. Тогда меняю адреса в пуле так, чтобы клиентам выдавались из сети inside, т.е. 192.168.1.0/24 - то же самое. Получается, что ноут 192.168.1.2 и выделенный клиенту 192.168.1.10 не пингуют друг друга. Смотрел примеры конфига на cisco.com - используют вообще разные сети при адресации inside и пула для удаленных клиентов, все как бы ОК. Тут же не работает ни при разных сетях, ни при одной.
Советовали кое-что поменять, в результате модифицированная часть конфига, касающаяся ACL и расщепления туннеля выглядела и так:

access-list L2LVPN extended permit ip object-group MainOffice object-group RemoteOffice
access-list NoNAT extended permit ip object-group MainOffice object-group RemoteOffice
access-list 5 standard permit 192.168.2.0 255.255.255.0

group-policy VPNUsers internal
group-policy VPNUsers attributes
split-tunnel-policy tunnelspecified
split-tunnel-network-list value 5

Тем не менее результата по-прежнему нет.
Может быть, я что-то упустил?
Всем спасибо за любую помощь.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Проблема с удаленным Remote Access VPN-соединением"  
Сообщение от hamb email on 21-Ноя-06, 19:42 
>Добрый день!
>Вот столкнулся со следующей проблемой. В общем, есть PIX 525 (7.0.2 ОС),
>настроенный на оба типа VPN: LAN-to-LAN и Remote Access. L2L работает
>нормально. Удаленные клиенты с использованием Cisco VPN Client и настроенного на
>Пиксе RA VPN туннеля успешно подключаются и аутентифицируются, однако не могут
>пропинговать машины в сети inside за PIX.

удаленные клиенты лезут с одного места?

похоже, что гдето блочится UDP трафик
возможно , что 500 порт открыт и это позволяет авторизоваться и получить IP
а вот более высшие порты прикрыты, например - 4500, 10000

попробуйте подключиться сами откуда-нибудь извне и проверьте
посмотрите логи клиента, debug на циске...

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Проблема с удаленным Remote Access VPN-соединением"  
Сообщение от Kir_rus email(ok) on 21-Ноя-06, 23:48 
Спасибо - я уже разобрался! Действительно дебаг с сислогом самое действенное средство поиска косяков.


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Проблема с удаленным Remote Access VPN-соединением"  
Сообщение от hamb email on 22-Ноя-06, 10:36 
>Спасибо - я уже разобрался! Действительно дебаг с сислогом самое действенное средство
>поиска косяков.

так где был косяк то?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Проблема с удаленным Remote Access VPN-соединением"  
Сообщение от Kir_rus email(ok) on 22-Ноя-06, 22:45 
Конкретно в том случае с неудававшимися пингами, причина крылась в откровенной ерунде... Дело в том, что у меня дома, откуда я и подключался удаленно к рабочему тестовому Пиксу, кроме основного компа, который воткнут в городскую сеть, есть и еще один, который подключен ко второй сетевухе основного компа, соответственно на этом втором компе для доступа в Инет был прописан статический маршрут вида 0.0.0.0 0.0.0.0 <шлюз - адрес второй сетевухи основного компа>. Еще когда-то давно написал... В этом и оказалась вся загвоздка. После несколькоих неудачных попыток махинаций с конфигом вдруг как-то пришла в голову мысль сделать tracert адреса компа, который в inside за Пиксом при включенном уже Remote Access VPN. И обнаружилось, что трафик гонится не в туннель, как должен, а через этот статический маршрут в нашу городскую сеть. Вот и такое бывает... После этого переставил Windows на основном компе, который напрямую к Инету подключен, поставил Cisco VPN Client туда, и сразу все заработало. Потом еще и аутентификацию удаленного пользователя на RADIUS прикручивал к нему, тут уже без логов и дебагов, как и без советов, не справиться было бы, наверное. В общем, подробно все мучения, но закончившиеся все-таки успешно, описаны тут:
http://www.certification.ru/cgi-bin/forum.cgi?action=thread&id=22204


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру