Вот такая схема:internet------[pix]-----[vpn server]-----intranet
У PIX'a интерфейсы:
1. глядящий в интернет: 1.1.1.1
2. глядящий на vpn-сервер: 10.2.0.1
между интерфейсами поднят NATУ VPN-клиента(винХР) адрес: 2.2.2.2
Входящие VPN-сессии от клиента затыкаются на PIX'е.
В логе PIX'a вот такие строки:
TCP request discarded from 2.2.2.2/1539 to outside:1.1.1.1/pptp
TCP request discarded from 2.2.2.2/1539 to outside:1.1.1.1/pptpВопрос №1: как научить PIX таки пропускать PPTP через себя?
Вопрос №2: не помешает ли PIX'овый NAT хождению PPTP через себя?
Типа нужен режим NAT'а прозрачный для PPTP. Такое PIX может?PS: Если я выпускаю VPN-сервер(FreeBDS5.3+mpd) напрямую в инет, то никаких проблем. Все отлично VPN'ится.
Но PIX, зараза, всю малину обо...
>Вот такая схема:
>
>internet------[pix]-----[vpn server]-----intranet
>
>У PIX'a интерфейсы:
>1. глядящий в интернет: 1.1.1.1
>2. глядящий на vpn-сервер: 10.2.0.1
>между интерфейсами поднят NAT
>
>У VPN-клиента(винХР) адрес: 2.2.2.2
>
>Входящие VPN-сессии от клиента затыкаются на PIX'е.
>В логе PIX'a вот такие строки:
>TCP request discarded from 2.2.2.2/1539 to outside:1.1.1.1/pptp
>TCP request discarded from 2.2.2.2/1539 to outside:1.1.1.1/pptpЭто control session, это пока еще не PPTP.
>Вопрос №1: как научить PIX таки пропускать PPTP через себя?
>Вопрос №2: не помешает ли PIX'овый NAT хождению PPTP через себя?
>Типа нужен режим NAT'а прозрачный для PPTP. Такое PIX может?Permitting PPTP Connections Through the PIX:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/produc...
Ищется мгновенно, к слову сказать. Это намёк.
Не успел я отбой дать. :)
Буквально через 10 минут после крика о помощи сам нашел именно этот документ. Правда вот тут:
http://www.cisco.com/warp/public/110/pix_pptp.html
Вдогонку, если вдруг кому интересно. При реализации описанного тут
http://www.cisco.com/warp/public/110/pix_pptp.html
процесса столкнулся с проблемой при прописывании static'a на доп.IP-адрес вешаемый на outside интерфейс, потому как доп.адрес попадал под маску основного IP-адреса outside интерфейса. Вываливались варнинги, но статик прописывался, а в результате он становился главным статиком на аутсайде и "забивал" собой действие предыдущих статиков. Сейчас поясню. Вот что было:
----------------------------------------------------------------
static (proxy,outside) tcp interface smtp 10.2.0.2 smtp netmask 255.255.255.255 0 0
static (proxy,outside) tcp interface www 10.2.0.2 www netmask 255.255.255.255 0 0
static (proxy,outside) tcp interface https 10.2.0.2 https netmask 255.255.255.255 0 0
static (proxy,outside) tcp interface imap4 10.2.0.2 imap4 netmask 255.255.255.255 0 0
static (proxy,outside) tcp interface pop3 10.2.0.2 pop3 netmask 255.255.255.255 0 0
static (proxy,outside) tcp interface ftp 10.2.0.2 ftp netmask 255.255.255.255 0 0
static (proxy,outside) 1.1.1.5 10.2.0.2 netmask 255.255.255.255 0 0
----------------------------------------------------------------
в этом случае последний статик перебивал все 6 предыдущих.
пришлось его грохать и чистить clear xlate global 1.1.1.5
Вариант обхода проблемы в данном случае прост. Последний статик видоизменяется:
----------------------------------------------------------------
static (proxy,outside) tcp interface pptp 10.2.0.2 pptp netmask 255.255.255.255 0 0
----------------------------------------------------------------
Но для обеспечения работоспособности этого решения ОБЯЗАТЕЛЬНО необходимо добавить в конфиг строчку: fixup protocol pptp 1723
Без этого не работало.