# msisa vpn, NAT, split DNS and limit 2 connect

## sa10

Возможно кто натыкался на подобную проблему.

Имею небольшую сетку для виндовс машин за шлюзом на генте - NAT,dhcp, split DNS на bind9 для внешней и внутренней зоны.

Все интерфейсы - vlan.

Виндовс машины через мой шлюз подключаеются через инет к другой сети там отвечает майкрософтовский сервер VPN на  MSISA.

Все хорошо если имеется не более 2-х активных подключений. Третья машина не получает связь.

Если один из двух сктивных соединений отключить, примерно через час иногда можно подключится с другой машины.

Судя по логам анализатора пакетов диалог клиента и vpn сервера идет, но останавливается на проверке имени и пароля, затем 

сообщение - " ошибка 721 - нет ответа сервера"

Админы MSISA твердят, что ограничений на количество коннектов у них нет.

Я почему про split DNS упомянул?

Есть такой документик - http://www.isadocs.ru/articles/work-around-VPN-clients-split-DNS.html

Пытался читать, но так и не понял какое это может иметь ко мне отношение кроме собственно наличия split DNS.

Может у кого мысль возникнет куда рыть...

PS.

Однако, вопросы про VPN посыпались у всех...  

 :Sad: 

----------

## fank

гм.... не факт, что это у тебя

во-первых, давай сюда логи клиента и желательно анализатора пакетов

про 2 активных соединения в указанной статье ничего не увидел, но с подобной проблемой знаком очень косвенно

теперь попробуй очистить кэш днс клиента и посмотреть, исчезнет ли задержка в час

далее выставь минимальные параметры ключа (56 бит) на клиенте, если используется MPPE и вообще поиграй здесь

смотри мой пост, я там специально коммент не вырезал про ISA

проверь как в статье указано порядок днс и нет ли этих ошибок при разрешении

ах да, самое главное - попробуй настроить "родного" pptpclient'а   :Very Happy: 

ну и поврубай там всё, что можно для дебаг-вывода

```
debug

logfd 2

dump
```

----------

## sa10

Клиент у меня стандартный виндозный

Сейчас настрою и начну пробовать MPPE, будет более внятная картина

Логи анализатора, (судя по их содержанию стороны общаются, но договориться не могут)

Успешная сессия :

```
tethereal -i vlan555 host 194.44.44.44
```

```

 0.000000 193.33.33.33 -> 194.44.44.44 TCP 1644 > 1723 [SYN] Seq=0 Len=0 MSS=1456

  0.001321 194.44.44.44 -> 193.33.33.33 TCP 1723 > 1644 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460

  0.001786 193.33.33.33 -> 194.44.44.44 PPTP Start-Control-Connection-Request

  0.003226 194.44.44.44 -> 193.33.33.33 PPTP Start-Control-Connection-Reply

  0.003763 193.33.33.33 -> 194.44.44.44 PPTP Outgoing-Call-Request

  0.009354 194.44.44.44 -> 193.33.33.33 PPTP Outgoing-Call-Reply

  0.017519 193.33.33.33 -> 194.44.44.44 PPTP Set-Link-Info

  0.023267 193.33.33.33 -> 194.44.44.44 PPP LCP Configuration Request

  0.030189 194.44.44.44 -> 193.33.33.33 PPP LCP Configuration Request

  0.031168 193.33.33.33 -> 194.44.44.44 PPP LCP Configuration Reject

  0.038194 194.44.44.44 -> 193.33.33.33 PPP LCP Configuration Nak

  0.038332 194.44.44.44 -> 193.33.33.33 PPP LCP Configuration Request

  0.039047 193.33.33.33 -> 194.44.44.44 PPP LCP Configuration Request

  0.039308 193.33.33.33 -> 194.44.44.44 PPP LCP Configuration Ack

  0.046954 194.44.44.44 -> 193.33.33.33 PPP LCP Configuration Nak

  0.047842 193.33.33.33 -> 194.44.44.44 PPP LCP Configuration Request

  0.052075 194.44.44.44 -> 193.33.33.33 PPTP Set-Link-Info

  0.055593 194.44.44.44 -> 193.33.33.33 PPP LCP Configuration Ack

  0.055990 194.44.44.44 -> 193.33.33.33 PPP CHAP Challenge

  0.057472 193.33.33.33 -> 194.44.44.44 PPTP Set-Link-Info

  0.057802 193.33.33.33 -> 194.44.44.44 PPP LCP Identification

  0.058039 193.33.33.33 -> 194.44.44.44 PPP LCP Identification

  0.059198 193.33.33.33 -> 194.44.44.44 PPP CHAP Response

  0.090650 194.44.44.44 -> 193.33.33.33 PPP CHAP Success (MESSAGE='S=3255E9FA9030598CB90960C323E9FB882F0FDB99')

  0.123323 194.44.44.44 -> 193.33.33.33 PPP CBCP Callback Request

  0.123986 193.33.33.33 -> 194.44.44.44 PPP CBCP Callback Response

  0.147640 194.44.44.44 -> 193.33.33.33 GRE Encapsulated PPP

  0.147878 194.44.44.44 -> 193.33.33.33 PPP CBCP Callback Ack

  0.148046 194.44.44.44 -> 193.33.33.33 PPP CCP Configuration Request

  0.148208 194.44.44.44 -> 193.33.33.33 PPP IPCP Configuration Request

  0.152988 193.33.33.33 -> 194.44.44.44 PPP CCP Configuration Request

  0.153329 193.33.33.33 -> 194.44.44.44 PPP IPCP Configuration Request

  0.153552 193.33.33.33 -> 194.44.44.44 PPP CCP Configuration Nak

  0.153885 193.33.33.33 -> 194.44.44.44 PPP IPCP Configuration Ack

  0.163275 194.44.44.44 -> 193.33.33.33 PPP CCP Configuration Nak

  0.163755 194.44.44.44 -> 193.33.33.33 PPP IPCP Configuration Reject

  0.163919 193.33.33.33 -> 194.44.44.44 PPP CCP Configuration Request

  0.163926 194.44.44.44 -> 193.33.33.33 PPP CCP Configuration Request

  0.164681 193.33.33.33 -> 194.44.44.44 PPP IPCP Configuration Request

  0.164915 193.33.33.33 -> 194.44.44.44 PPP CCP Configuration Ack

  0.181692 194.44.44.44 -> 193.33.33.33 PPP CCP Configuration Ack

  0.181934 194.44.44.44 -> 193.33.33.33 PPP IPCP Configuration Nak

  0.182848 193.33.33.33 -> 194.44.44.44 PPP IPCP Configuration Request

  0.186421 194.44.44.44 -> 193.33.33.33 PPP IPCP Configuration Ack

  0.245014 193.33.33.33 -> 194.44.44.44 GRE Encapsulated PPP

  0.267121 194.44.44.44 -> 193.33.33.33 TCP 1723 > 1644 [ACK] Seq=213 Ack=373 Win=65163 Len=0

  0.504453 193.33.33.33 -> 194.44.44.44 PPP Comp Compressed data

  0.519338 194.44.44.44 -> 193.33.33.33 PPP Comp Compressed data

  0.523014 193.33.33.33 -> 194.44.44.44 PPP Comp Compressed data

  0.523037 193.33.33.33 -> 194.44.44.44 PPP Comp Compressed data

  0.613481 194.44.44.44 -> 193.33.33.33 GRE Encapsulated PPP

  0.621361 193.33.33.33 -> 194.44.44.44 PPP Comp Compressed data

  0.796734 194.44.44.44 -> 193.33.33.33 GRE Encapsulated PPP

  1.180880 193.33.33.33 -> 194.44.44.44 PPP Comp Compressed data

  1.290734 194.44.44.44 -> 193.33.33.33 GRE Encapsulated PPP

```

Неуспешная сессия:

```

  0.000000 193.33.33.33 -> 194.44.44.44 TCP 1093 > 1723 [SYN] Seq=0 Len=0 MSS=1456

  0.001367 194.44.44.44 -> 193.33.33.33 TCP 1723 > 1093 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460

  0.001817 193.33.33.33 -> 194.44.44.44 PPTP Start-Control-Connection-Request

  0.003272 194.44.44.44 -> 193.33.33.33 PPTP Start-Control-Connection-Reply

  0.003812 193.33.33.33 -> 194.44.44.44 PPTP Outgoing-Call-Request

  0.010262 194.44.44.44 -> 193.33.33.33 PPTP Outgoing-Call-Reply

  0.021376 193.33.33.33 -> 194.44.44.44 PPTP Set-Link-Info

  0.203918 194.44.44.44 -> 193.33.33.33 TCP 1723 > 1093 [ACK] Seq=189 Ack=349 Win=65187 Len=0

  9.244644 193.33.33.33 -> 194.44.44.44 PPTP Set-Link-Info

  9.391767 194.44.44.44 -> 193.33.33.33 TCP 1723 > 1093 [ACK] Seq=189 Ack=373 Win=65163 Len=0

```

Сомневаюсь, что это поможет. Анализировать правильнее поведение сервера, а там некому  :Sad: Last edited by sa10 on Tue Jun 20, 2006 2:39 pm; edited 1 time in total

----------

## fank

это всё, конечно, хорошо

но всё же лучше было бы получить лог с pptpclient'а

я с ним как-то дружнее   :Wink: 

теперь мысли навскидку - проверь, доступен ли протокол ICMP от сервера к клиенту, в частности dest.unreachable

далее, сделай задержку между установлением tcp-соединения и началом посылок LCP

проверь это:

 *Quote:*   

> No GRE transmitted by PPTP Server
> 
> Symptom: GRE packets are emitted by the client, but none are returned by the server, but a tunnel from another machine on the same LAN works fine. The client is behind a NAT gateway with respect to the server.
> 
> Diagnosis: PPTP servers will not allow a connection to start from the same IP address that they perceive an active connection on already.
> ...

 

последнее скорее всего

да, и скажи какой у тебя тип НАТа

http://www.voip-info.org/wiki-STUN

это (пусть туманно и косвенно) объясняет (скорее наводит на размышления), почему 2 коннекта

----------

## sa10

Да, на саом деле я имею не 2 возможных соединения, а одно.

У них два сервера. Оказывается я к разным vpn серверам подключался  :Smile: 

>> лучше было бы получить лог с pptpclient'а

На самом деле там ничего особенно внятного

Он в случае занятости крутит по кругу это:

```
using channel 763

Using interface ppp0

Connect: ppp0 <--> /dev/pts/4

sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0x6381b854> <pcomp> <accomp>]

Script pptp 194.44.44.44 --nolaunchpppd finished (pid 3936), status = 0x0

Modem hangup

Connection terminated.
```

>>> сделай задержку между установлением tcp-соединения и началом посылок LCP

Это как?

>> проверь это:

 *Quote:*   

> No GRE transmitted by PPTP Server
> 
> Symptom: GRE packets are emitted by the client, but none are returned by the server, but a tunnel from another machine on the same LAN works fine. The client is behind a NAT gateway with respect to the server.
> 
> Diagnosis: PPTP servers will not allow a connection to start from the same IP address that they perceive an active connection on already.
> ...

 

>> последнее скорее всего

Это похоже оно и есть

alternate PPTP server  это опция такая на исе или что?

Или имеется ввиду альтернативный IP сервера?

Это проблему не решает, я не могу требовать добавлять реальные интеренет адреса на сервере.

ISA вываливает такие сообщения:

```
A connection between the VPN server and the VPN client 193.33.33.33 has been established, but the VPN connection cannot be completed. The most common cause for this is that a firewall or router between the VPN server and the VPN client is not configured to allow Generic Routing Encapsulation (GRE) packets (protocol 47). Verify that the firewalls and routers between your VPN server and the Internet allow GRE packets. Make sure the firewalls and routers on the user's network are also configured to allow GRE packets. If the problem persists, have the user contact the Internet service provider (ISP) to determine whether the ISP might be blocking GRE packets.
```

Но если бы я блокировал GRE, то ни одного соединения не получалось бы. 

>> да, и скажи какой у тебя тип НАТа

Может я чего не знаю, но iptables позволяет получить три типа трансляции адресов SNAT, DNAT и маскарад как одну из форм SNAT. 

Я пользую SNAT (Это видимо symmetric NAT по их классификации http://www.voip-info.org/wiki-STUN):

```
$IPTABLES -t nat -A POSTROUTING -s $IP_INT404_NET -o $DEV_EXT -j SNAT --to-source $IP_EXT

$IPTABLES -A FORWARD -s $IP_INT404_NET -o $DEV_EXT -m state --state NEW,ESTABLISHED -j ACCEPT
```

http://lists.debian.org/debian-security/2006/01/msg00071.html

----------

## ba

 *sa10 wrote:*   

> Да, на саом деле я имею не 2 возможных соединения, а одно.
> 
> У них два сервера. Оказывается я к разным vpn серверам подключался :)

 

а conntrack_pptp включен в ядре? если нет, то попробуй включить

----------

## fank

нет, SNAT, DNAT - это sources, destination NAT соотв

по ссылочке, что я тебе дал, описываются 4 вида ната

 *Quote:*   

> Various types of NAT (still according to the RFC) 
> 
> Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address. 
> 
> Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X. 
> ...

 

вкратце - при ответном пакете клиенту за НАТом учитывается разные поля в НАТ-записи роутера, то есть различные сочетания порт-ип на внешнем интерфейсе после трансляции адреса, потому и четыре типа

в твоём случае, ИСА не понимает, что это НАТ и при ответе думает, что туннель устанавливает один и тот же хост

тупое корявое предположение, но что-то в нём есть, тем более, что именно об этом и пишут на pptpclient.sf.net (FAQ)

workaround: попробуй 2 клиентов не НАТить, а форвардить, получится - значит пиши админам ИСА, чтоб разобрались

STUN нужен, чтобы определить тип НАТа

P.S. удали, пожалуйста, простыню выше, тем более, что она не весь сеанс показывает и слишком громоздкая   :Very Happy: 

УДАЧИ!

----------

## ba

 *fank wrote:*   

> вкратце - при ответном пакете клиенту за НАТом учитывается разные поля в НАТ-записи роутера, то есть различные сочетания порт-ип на внешнем интерфейсе после трансляции адреса, потому и четыре типа
> 
> в твоём случае, ИСА не понимает, что это НАТ и при ответе думает, что туннель устанавливает один и тот же хост
> 
> тупое корявое предположение, но что-то в нём есть, тем более, что именно об этом и пишут на pptpclient.sf.net (FAQ)
> ...

 

1) в GRE-пакетах нет понятия порта

2) а что значит форвардить? если сервер с той стороны не принимает несколько коннектов с одного ip, то поможет только натить разных клиентов в разные ip

----------

## sa10

Все оказалось просто...

Ну это как всегда  :Smile: )

```
modprobe -l |grep pptp

/lib/modules/2.6.14-hardened-r8/kernel/net/ipv4/netfilter/ip_nat_pptp.ko

/lib/modules/2.6.14-hardened-r8/kernel/net/ipv4/netfilter/ip_conntrack_pptp.ko
```

Вот этих модулей и не хватало.

Смотрю пока сам доковырялся, ba уже выдал правильное решение.

Всем ОГРОМНОЕ спасибоLast edited by sa10 on Tue Jun 20, 2006 2:57 pm; edited 1 time in total

----------

## sa10

 *Quote:*   

> нет, SNAT, DNAT - это sources, destination NAT соотв

 

Ну дык понятно, что  SNAT = sources nat, я имел ввиду что по их классификации SNAT соответствует symmetric nat 

По дороге обнаружил еще Frickin PPTP Proxy. может пригодится кому

http://sourceforge.net/projects/frickin/

----------

## fank

 *Quote:*   

> 1) в GRE-пакетах нет понятия порта 

 

это-то понятно  :Smile: 

я говорил про TCP сессию, но сам не догнал, что говорилось про GRE-сессию, имено этим и занимается ip_conntrack_pptp

 *Quote:*   

> 2) а что значит форвардить? если сервер с той стороны не принимает несколько коннектов с одного ip, то поможет только натить разных клиентов в разные ip

 

я имел в виду не НАТить, но выпустить наружу с использованием TCP протокола, то есть запихнуть в цепочку FORWARD, чтобы ип засветить на сервере - это, я уверен, тоже решение данной проблемы

ip_conntrack_pptp теперь будет сообщать ИСЕ, что это 2 разных компа соединяются, но данные эти будут инкапсулированы в GRE

всё, разобрались   :Very Happy: 

----------

