URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 95617
[ Назад ]
Исходное сообщение
"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirxxx , 20-Май-14 17:15 
В двух офисах стоят шлюзы на FreeBSD9.2+pf+squid+mpd5
все работает отлично. На серверы mpd5 подключаются удаленные
клиенты человек 10.
Есть офис в нем лицензионный Usergate 5.4 можно сказать
работает, но иногда без видимых причин начинает
просидать по скорости пока не его перезапустишь или
вылетает с ошибкой Visual C++ и как всегда в самый
неудобный момент. Мне это надоело и я решил поставить
Freebsd9.2 как и в других офисах. Поставил FreeBSD9.2+pf+squid
настроил все по аналогии с другими офисами. Интернет стал работает ровнее и
быстрее. Но тут я столкнулся с такой проблемой пользователи в этом офисе
теперь не могут подключиться к vpn серверам mpd5, которые работают в двух
других офисах с клиентов vpn windows подключение pptp.
Зависает подключение на проверке имени и пароля пользователя
и вываливается в windows XP с ошибкой 619 в windows 7 с ошибкой 629.
Похоже как будто pf блокирует GRE. Но в pf по аналогии с другими офисами
стоит правило

pass quick inet proto gre from any to any keep state

и pfctl -sr показывает

pass quick inet proto gre all keep state

типо все должно работать, gre должен пропускать.
Подключаю обратно UG5 все работает делай подключений vpn сколько нужно.
Причем в удаленном офисе есть cisco pix 506 на нем поднят vpn
к нему через шлюз на FreeBSD подключаюсь без проблем.

Заметил что при подключении к mpd5 через FreeBSD

pfctl -s state | grep gre

показыват

all gre 200.1.1.1 <- 85.1.1.1       NO_TRAFFIC:SINGLE
all gre 85.1.1.1 <- 192.168.0.80       NO_TRAFFIC:SINGLE
all gre 200.1.1.1 (192.168.0.80) -> 85.1.1.1       SINGLE:NO_TRAFFIC

где    200.1.1.1 офис с которого я подключаюсь
    85.1.1.1 офис к которому я подключаюсь где запущен mpd5
    192.168.0.80 комп на котором я запускаю клиента vpn
И подключение вываливается с ошибкой 619
#####################################
а если подключаюсь к cisco pix 506 через FreeBSD
pfctl -s state | grep gre

показывает
all gre 82.2.2.2 <- 192.168.0.80       MULTIPLE:MULTIPLE
all gre 200.1.1.1 (192.168.0.80) -> 82.2.2.2       MULTIPLE:MULTIPLE
    
где    200.1.1.1 офис с которого я подключаюсь
    82.2.2.2 офис к которому я подключаюсь где стоит pix 506
    192.168.0.10 комп на котором я запускаю клиента vpn
подключение проходит без проблем и клиент бысто подключается.
############################
pf.conf
############################

############    MACROS
ext_if = "xl0" # internet
int_if = "re1" # local
lan_net= "{ 192.168.0.0/24 }"

#FOR NON-ROUTABLE ADRESS
NoRouteIPs = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, \
              10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, \
              0.0.0.0/8, 240.0.0.0/4 }"

#SERVICES NEED TO BE DEFINED BEFORE USE
tcp_services = "{ ntp, ssh, smtp, domain, http, https, 821, 1723, nfsd, rpcbind }"
ftp_ports = "{ ftp, ftp-data }"
udp_services = "{ domain, ntp, rpcbind, 821, nfsd }"
vpn_tcp = "{ 3389, 139, 443 }"
vpn_udp = "{ 137, 138 }"

#OPTIONS
set skip on lo0

############    SCRUB
scrub in all

############    NAT
# TRANSPARENT PROXY
rdr pass on $int_if proto tcp from $lan_net to any port 80 -> 127.0.0.1 port 3128

#R_ADMIN
rdr on $ext_if proto tcp from any to any port $raport -> $radmin

#MEDIAGET
rdr on $ext_if proto tcp from any to any port $m_port  -> $m_srv

#ALLOW NAT
nat on $ext_if from $lan_net to any -> ($ext_if)

############    FILTERING
#BLOCK NON-ROUTABLE ADRESS
block drop in quick on $ext_if from $NoRouteIPs to any
block drop out quick on $ext_if from any to $NoRouteIPs

#TO BLOCK INCOMING&OUTING TRAFFIC
block in all
block out all

#ANTISPUFFING
antispoof for $ext_if
antispoof for $int_if

#ALLOW GRE
pass quick inet proto gre from any to any keep state

# FTP
pass quick inet proto { tcp, udp } from any to any port $ftp_ports keep state
pass quick inet proto { tcp, udp } from any to any port > 18000 keep state

# allow TCP and UDP
pass quick inet proto udp from any to any port $udp_services keep state
pass quick inet proto tcp from any to any port $tcp_services keep state

# allow icmp
pass quick inet proto icmp from $lan_net to any keep state
pass quick inet proto icmp from $ext_if to any keep state

# tracert
pass out on $ext_if inet proto udp from any to any port 33433 >< 33626 keep state

################################
на строне сервера mpd5 в логфайле mpd.log при подключении клиента с winodws 7
появляются сообщения
May 20 16:50:34 pbc01 mpd: [L-2] Accepting PPTP connection
May 20 16:50:34 pbc01 mpd: [L-2] Link: OPEN event
May 20 16:50:34 pbc01 mpd: [L-2] LCP: Open event
May 20 16:50:34 pbc01 mpd: [L-2] LCP: state change Initial --> Starting
May 20 16:50:34 pbc01 mpd: [L-2] LCP: LayerStart
May 20 16:50:34 pbc01 mpd: [L-2] PPTP: attaching to peer's outgoing call
May 20 16:50:34 pbc01 mpd: [L-2] Link: UP event
May 20 16:50:34 pbc01 mpd: [L-2] LCP: Up event
May 20 16:50:34 pbc01 mpd: [L-2] LCP: state change Starting --> Req-Sent
May 20 16:50:34 pbc01 mpd: [L-2] LCP: SendConfigReq #1
May 20 16:50:34 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:34 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:34 pbc01 mpd: [L-2]   MRU 1500
May 20 16:50:34 pbc01 mpd: [L-2]   MAGICNUM 05b84e89
May 20 16:50:34 pbc01 mpd: [L-2]   AUTHPROTO CHAP MSOFTv2
May 20 16:50:34 pbc01 mpd: [L-2]   MP MRRU 2048
May 20 16:50:34 pbc01 mpd: [L-2]   MP SHORTSEQ
May 20 16:50:34 pbc01 mpd: [L-2]   ENDPOINTDISC [802.1] 00 1c c0 51 20 b3
May 20 16:50:35 pbc01 mpd: [L-2] LCP: rec'd Configure Request #0 (Req-Sent)
May 20 16:50:35 pbc01 mpd: [L-2]   MRU 1400
May 20 16:50:35 pbc01 mpd: [L-2]   MAGICNUM 7bc03d5e
May 20 16:50:35 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:35 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:35 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:35 pbc01 mpd: [L-2] LCP: SendConfigRej #0
May 20 16:50:35 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:36 pbc01 mpd: [L-2] LCP: SendConfigReq #2
May 20 16:50:36 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:36 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:36 pbc01 mpd: [L-2]   MRU 1500
May 20 16:50:36 pbc01 mpd: [L-2]   MAGICNUM 05b84e89
May 20 16:50:36 pbc01 mpd: [L-2]   AUTHPROTO CHAP MSOFTv2
May 20 16:50:36 pbc01 mpd: [L-2]   MP MRRU 2048
May 20 16:50:36 pbc01 mpd: [L-2]   MP SHORTSEQ
May 20 16:50:36 pbc01 mpd: [L-2]   ENDPOINTDISC [802.1] 00 1c c0 51 20 b3
May 20 16:50:37 pbc01 mpd: [L-2] LCP: rec'd Configure Request #1 (Req-Sent)
May 20 16:50:37 pbc01 mpd: [L-2]   MRU 1400
May 20 16:50:37 pbc01 mpd: [L-2]   MAGICNUM 7bc03d5e
May 20 16:50:37 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:37 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:37 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:37 pbc01 mpd: [L-2] LCP: SendConfigRej #1
May 20 16:50:37 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:38 pbc01 mpd: [L-2] LCP: SendConfigReq #3
May 20 16:50:38 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:38 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:38 pbc01 mpd: [L-2]   MRU 1500
May 20 16:50:38 pbc01 mpd: [L-2]   MAGICNUM 05b84e89
May 20 16:50:38 pbc01 mpd: [L-2]   AUTHPROTO CHAP MSOFTv2
May 20 16:50:38 pbc01 mpd: [L-2]   MP MRRU 2048
May 20 16:50:38 pbc01 mpd: [L-2]   MP SHORTSEQ
May 20 16:50:38 pbc01 mpd: [L-2]   ENDPOINTDISC [802.1] 00 1c c0 51 20 b3
May 20 16:50:40 pbc01 mpd: [L-2] LCP: rec'd Configure Request #2 (Req-Sent)
May 20 16:50:40 pbc01 mpd: [L-2]   MRU 1400
May 20 16:50:40 pbc01 mpd: [L-2]   MAGICNUM 7bc03d5e
May 20 16:50:40 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:40 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:40 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:40 pbc01 mpd: [L-2] LCP: SendConfigRej #2
May 20 16:50:40 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:40 pbc01 mpd: [L-2] LCP: SendConfigReq #4
May 20 16:50:40 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:40 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:40 pbc01 mpd: [L-2]   MRU 1500
May 20 16:50:40 pbc01 mpd: [L-2]   MAGICNUM 05b84e89
May 20 16:50:40 pbc01 mpd: [L-2]   AUTHPROTO CHAP MSOFTv2
May 20 16:50:40 pbc01 mpd: [L-2]   MP MRRU 2048
May 20 16:50:40 pbc01 mpd: [L-2]   MP SHORTSEQ
May 20 16:50:40 pbc01 mpd: [L-2]   ENDPOINTDISC [802.1] 00 1c c0 51 20 b3
May 20 16:50:42 pbc01 mpd: [L-2] LCP: SendConfigReq #5
May 20 16:50:42 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:42 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:42 pbc01 mpd: [L-2]   MRU 1500
May 20 16:50:42 pbc01 mpd: [L-2]   MAGICNUM 05b84e89
May 20 16:50:42 pbc01 mpd: [L-2]   AUTHPROTO CHAP MSOFTv2
May 20 16:50:42 pbc01 mpd: [L-2]   MP MRRU 2048
May 20 16:50:42 pbc01 mpd: [L-2]   MP SHORTSEQ
May 20 16:50:42 pbc01 mpd: [L-2]   ENDPOINTDISC [802.1] 00 1c c0 51 20 b3
May 20 16:50:44 pbc01 mpd: [L-2] LCP: rec'd Configure Request #3 (Req-Sent)
May 20 16:50:44 pbc01 mpd: [L-2]   MRU 1400
May 20 16:50:44 pbc01 mpd: [L-2]   MAGICNUM 7bc03d5e
May 20 16:50:44 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:44 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:44 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:44 pbc01 mpd: [L-2] LCP: SendConfigRej #3
May 20 16:50:44 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:44 pbc01 mpd: [L-2] LCP: SendConfigReq #6
May 20 16:50:44 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:44 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:44 pbc01 mpd: [L-2]   MRU 1500
May 20 16:50:44 pbc01 mpd: [L-2]   MAGICNUM 05b84e89
May 20 16:50:44 pbc01 mpd: [L-2]   AUTHPROTO CHAP MSOFTv2
May 20 16:50:44 pbc01 mpd: [L-2]   MP MRRU 2048
May 20 16:50:44 pbc01 mpd: [L-2]   MP SHORTSEQ
May 20 16:50:44 pbc01 mpd: [L-2]   ENDPOINTDISC [802.1] 00 1c c0 51 20 b3
May 20 16:50:46 pbc01 mpd: [L-2] LCP: SendConfigReq #7
May 20 16:50:46 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:46 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:46 pbc01 mpd: [L-2]   MRU 1500
May 20 16:50:46 pbc01 mpd: [L-2]   MAGICNUM 05b84e89
May 20 16:50:46 pbc01 mpd: [L-2]   AUTHPROTO CHAP MSOFTv2
May 20 16:50:46 pbc01 mpd: [L-2]   MP MRRU 2048
May 20 16:50:46 pbc01 mpd: [L-2]   MP SHORTSEQ
May 20 16:50:46 pbc01 mpd: [L-2]   ENDPOINTDISC [802.1] 00 1c c0 51 20 b3
May 20 16:50:48 pbc01 mpd: [L-2] LCP: rec'd Configure Request #4 (Req-Sent)
May 20 16:50:48 pbc01 mpd: [L-2]   MRU 1400
May 20 16:50:48 pbc01 mpd: [L-2]   MAGICNUM 7bc03d5e
May 20 16:50:48 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:48 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:48 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:48 pbc01 mpd: [L-2] LCP: SendConfigRej #4
May 20 16:50:48 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:48 pbc01 mpd: [L-2] LCP: SendConfigReq #8
May 20 16:50:48 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:48 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:48 pbc01 mpd: [L-2]   MRU 1500
May 20 16:50:48 pbc01 mpd: [L-2]   MAGICNUM 05b84e89
May 20 16:50:48 pbc01 mpd: [L-2]   AUTHPROTO CHAP MSOFTv2
May 20 16:50:48 pbc01 mpd: [L-2]   MP MRRU 2048
May 20 16:50:48 pbc01 mpd: [L-2]   MP SHORTSEQ
May 20 16:50:48 pbc01 mpd: [L-2]   ENDPOINTDISC [802.1] 00 1c c0 51 20 b3
May 20 16:50:50 pbc01 mpd: [L-2] LCP: SendConfigReq #9
May 20 16:50:50 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:50 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:50 pbc01 mpd: [L-2]   MRU 1500
May 20 16:50:50 pbc01 mpd: [L-2]   MAGICNUM 05b84e89
May 20 16:50:50 pbc01 mpd: [L-2]   AUTHPROTO CHAP MSOFTv2
May 20 16:50:50 pbc01 mpd: [L-2]   MP MRRU 2048
May 20 16:50:50 pbc01 mpd: [L-2]   MP SHORTSEQ
May 20 16:50:50 pbc01 mpd: [L-2]   ENDPOINTDISC [802.1] 00 1c c0 51 20 b3
May 20 16:50:52 pbc01 mpd: [L-2] LCP: rec'd Configure Request #5 (Req-Sent)
May 20 16:50:52 pbc01 mpd: [L-2]   MRU 1400
May 20 16:50:52 pbc01 mpd: [L-2]   MAGICNUM 7bc03d5e
May 20 16:50:52 pbc01 mpd: [L-2]   PROTOCOMP
May 20 16:50:52 pbc01 mpd: [L-2]   ACFCOMP
May 20 16:50:52 pbc01 mpd: [L-2]   CALLBACK 6
May 20 16:50:52 pbc01 mpd: [L-2] LCP: not converging
May 20 16:50:52 pbc01 mpd: [L-2] LCP: parameter negotiation failed
May 20 16:50:52 pbc01 mpd: [L-2] LCP: state change Req-Sent --> Stopped
May 20 16:50:52 pbc01 mpd: [L-2] LCP: LayerFinish
May 20 16:50:52 pbc01 mpd: [L-2] PPTP call terminated
May 20 16:50:52 pbc01 mpd: [L-2] Link: DOWN event
May 20 16:50:52 pbc01 mpd: [L-2] LCP: Close event
May 20 16:50:52 pbc01 mpd: [L-2] LCP: state change Stopped --> Closed
May 20 16:50:52 pbc01 mpd: [L-2] LCP: Down event
May 20 16:50:52 pbc01 mpd: [L-2] LCP: state change Closed --> Initial
May 20 16:50:52 pbc01 mpd: [L-2] Link: SHUTDOWN event
May 20 16:50:52 pbc01 mpd: [L-2] Link: Shutdown
May 20 16:54:44 pbc01 mpd: [L-1] LCP: no reply to 1 echo request(s)
May 20 16:55:50 pbc01 mpd: [L-1] PPTP call terminated
May 20 16:55:50 pbc01 mpd: [L-1] Link: DOWN event
May 20 16:55:50 pbc01 mpd: [L-1] LCP: Close event
May 20 16:55:50 pbc01 mpd: [L-1] LCP: state change Opened --> Closing
May 20 16:55:50 pbc01 mpd: [L-1] Link: Leave bundle "B-1"
May 20 16:55:50 pbc01 mpd: [B-1] Bundle: Status update: up 0 links, total bandwidth 9600 bps
May 20 16:55:50 pbc01 mpd: [B-1] IPCP: Close event
May 20 16:55:50 pbc01 mpd: [B-1] IPCP: state change Opened --> Closing
May 20 16:55:50 pbc01 mpd: [B-1] IPCP: SendTerminateReq #3
May 20 16:55:50 pbc01 mpd: [B-1] IPCP: LayerDown
May 20 16:55:50 pbc01 mpd: [B-1] IFACE: Down event
May 20 16:55:50 pbc01 mpd: [B-1] CCP: Close event
May 20 16:55:50 pbc01 mpd: [B-1] CCP: state change Opened --> Closing
May 20 16:55:50 pbc01 mpd: [B-1] CCP: SendTerminateReq #2
May 20 16:55:50 pbc01 mpd: [B-1] CCP: LayerDown
May 20 16:55:50 pbc01 mpd: [B-1] IPCP: Down event
May 20 16:55:50 pbc01 mpd: [B-1] IPCP: LayerFinish
May 20 16:55:50 pbc01 mpd: [B-1] Bundle: No NCPs left. Closing links...
May 20 16:55:50 pbc01 mpd: [B-1] IPCP: state change Closing --> Initial
May 20 16:55:50 pbc01 mpd: [B-1] CCP: Down event
May 20 16:55:50 pbc01 mpd: [B-1] CCP: LayerFinish
May 20 16:55:50 pbc01 mpd: [B-1] CCP: state change Closing --> Initial
May 20 16:55:50 pbc01 mpd: [B-1] Bundle: Shutdown
May 20 16:55:50 pbc01 mpd: [L-1] LCP: SendTerminateReq #5
May 20 16:55:50 pbc01 mpd: [L-1] LCP: LayerDown
May 20 16:55:50 pbc01 mpd: [L-1] LCP: Down event
May 20 16:55:50 pbc01 mpd: [L-1] LCP: LayerFinish
May 20 16:55:50 pbc01 mpd: [L-1] LCP: state change Closing --> Initial
May 20 16:55:50 pbc01 mpd: [L-1] Link: SHUTDOWN event
May 20 16:55:50 pbc01 mpd: [L-1] Link: Shutdown

В чем проблема. Помогите, третий день не могу разобраться. Очень хочется
поскорее избавиться от UG5.

Содержание
Сообщения в этом обсуждении
"через PF не устанавливается vpn соединение с mpd5"
Отправлено SDenis , 21-Май-14 00:34 
>[оверквотинг удален]
> May 20 16:55:50 pbc01 mpd: [B-1] Bundle: Shutdown
> May 20 16:55:50 pbc01 mpd: [L-1] LCP: SendTerminateReq #5
> May 20 16:55:50 pbc01 mpd: [L-1] LCP: LayerDown
> May 20 16:55:50 pbc01 mpd: [L-1] LCP: Down event
> May 20 16:55:50 pbc01 mpd: [L-1] LCP: LayerFinish
> May 20 16:55:50 pbc01 mpd: [L-1] LCP: state change Closing --> Initial
> May 20 16:55:50 pbc01 mpd: [L-1] Link: SHUTDOWN event
> May 20 16:55:50 pbc01 mpd: [L-1] Link: Shutdown
> В чем проблема. Помогите, третий день не могу разобраться. Очень хочется
> поскорее избавиться от UG5.

Поставь OpenVPN site-to-site с PSK и не мучайся

"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirxxx , 21-Май-14 09:54 

> Поставь OpenVPN site-to-site с PSK и не мучайся

OpenVPN более тяжелый вариант для наших целей. mpd5 вполне устраивал. Причем в двух офисах, где уже установлены FreeBSD, соединения с mpd5 через шлюз FreeBSD работают. Этот шлюз с FreeBSD отличается только тем, что на нем еще запущен BIND, а у тех шлюзов DNS сервером является windows 2008.

"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirxxx , 22-Май-14 16:50 
Так и не могу разобраться в чем проблема. Не пойму проблема в работе PF или mpd5 сервера. Куда копать. Вообще PF хороший файрвол или лучше посмотреть в сторону ipfirewall?


"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirxxx , 22-Май-14 17:24 
Решил посмотреть tcpdump на стороне сервера mpd5.
Где 200.1.1.1офис от куда я подключаюсь, 85.1.1.1 офис куда я подключаюсь где запущен mpd5 сервер.
при подключении с winodws xp через FreeBSD+PF видно, что подключение по порту 1723 проходит, по протоколу GRE идут запросы на соединение но ответа так и не дождавшись  отваливается.
tcpdump -n -i em1 src 200.1.1.1 and not port ssh

###########################################################

16:56:18.466460 IP 200.1.1.1.55415 > 85.1.1.1.1723: Flags [S], seq 4095329785, win 65535, options [mss 1460,nop,nop,sackOK], length 0
16:56:18.505937 IP 200.1.1.1.55415 > 85.1.1.1.1723: Flags [P.], seq 4095329786:4095329942, ack 4021654256, win 65535, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(2600) HOSTNAME() VENDOR(Microsoft Windows NT)
16:56:18.532671 IP 200.1.1.1.55415 > 85.1.1.1.1723: Flags [P.], seq 156:324, ack 157, win 65379, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID(49152) CALL_SER_NUM(29847) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
16:56:18.565909 IP 200.1.1.1.55415 > 85.1.1.1.1723: Flags [P.], seq 324:348, ack 189, win 65347, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(64919) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
16:56:18.566788 IP 200.1.1.1> 85.1.1.1: GREv1, call 64919, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23
16:56:20.599642 IP 200.1.1.1> 85.1.1.1: GREv1, call 64919, seq 1, length 37: LCP, Conf-Request (0x01), id 1, length 23
16:56:23.589851 IP 200.1.1.1> 85.1.1.1: GREv1, call 64919, seq 2, length 37: LCP, Conf-Request (0x01), id 2, length 23
16:56:27.556127 IP 200.1.1.1> 85.1.1.1: GREv1, call 64919, seq 3, length 37: LCP, Conf-Request (0x01), id 3, length 23
16:56:31.568265 IP 200.1.1.1> 85.1.1.1: GREv1, call 64919, seq 4, length 37: LCP, Conf-Request (0x01), id 4, length 23
16:56:35.554530 IP 200.1.1.1> 85.1.1.1: GREv1, call 64919, seq 5, length 37: LCP, Conf-Request (0x01), id 5, length 23
16:56:35.557905 IP 200.1.1.1.55415 > 85.1.1.1.1723: Flags [P.], seq 348:364, ack 337, win 65199, length 16: pptp CTRL_MSGTYPE=StopCCRQ REASON(1)
16:56:35.560528 IP 200.1.1.1.55415 > 85.1.1.1.1723: Flags [F.], seq 364, ack 354, win 65183, length 0

#######################################################
Если я подключаюсь через UG5.4 получаю следующую картину. Видно что клиент делает запрос по протоколу GRE и получает ответ.  И соединение создается.
####################################################
17:08:55.890114 IP 200.1.1.1.55110 > 85.1.1.1.1723: Flags [S], seq 94566878, win 65535, options [mss 1460,nop,nop,sackOK], length 0
17:08:55.953579 IP 200.1.1.1.55110 > 85.1.1.1.1723: Flags [P.], seq 94566879:94567035, ack 415383139, win 65535, length 156: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) FRAME_CAP(A) BEARER_CAP(A) MAX_CHAN(0) FIRM_REV(2600) HOSTNAME() VENDOR(Microsoft Windows NT)
17:08:56.026037 IP 200.1.1.1.55110 > 85.1.1.1.1723: Flags [P.], seq 156:324, ack 157, win 65379, length 168: pptp CTRL_MSGTYPE=OCRQ CALL_ID(32768) CALL_SER_NUM(29862) MIN_BPS(300) MAX_BPS(100000000) BEARER_TYPE(Any) FRAME_TYPE(E) RECV_WIN(64) PROC_DELAY(0) PHONE_NO_LEN(0) PHONE_NO() SUB_ADDR()
17:08:56.101371 IP 200.1.1.1.55110 > 85.1.1.1.1723: Flags [P.], seq 324:348, ack 189, win 65347, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(46814) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
17:08:56.103875 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 0, length 37: LCP, Conf-Request (0x01), id 0, length 23
17:08:56.167459 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 1, ack 1, length 38: LCP, Conf-Request (0x01), id 1, length 20
17:08:56.234295 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, ack 2, no-payload, length 12
17:08:58.060537 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 2, ack 3, length 39: LCP, Conf-Reject (0x04), id 2, length 21
17:08:58.101758 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 3, ack 4, length 43: LCP, Conf-Ack (0x02), id 3, length 25
17:08:58.101877 IP 200.1.1.1.55110 > 85.1.1.1.1723: Flags [P.], seq 348:372, ack 189, win 65347, length 24: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(46814) SEND_ACCM(0xffffffff) RECV_ACCM(0xffffffff)
17:08:58.101887 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 4, length 32: LCP, Ident (0x0c), id 2, length 20
17:08:58.102001 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 5, length 37: LCP, Ident (0x0c), id 3, length 25
17:08:58.154099 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 6, ack 5, length 80: CHAP, Response (0x02), id 1, Value 2cbb8fe995570303779025971df7c5ae00000000000000008f4f79e13008e203f5f45a2ea991400bdc8b1a08dcd94bd600, Name Vladimir
17:08:58.215946 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 7, ack 8, length 28: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 4, length 12
17:08:58.216062 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 8, length 48: IPCP, Conf-Request (0x01), id 5, length 36
17:08:58.216069 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 9, length 24: IPCP, Conf-Reject (0x04), id 1, length 12
17:08:58.216183 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 10, length 24: unknown ctrl-proto (0x80fd), Conf-Ack (0x02), id 1, length 12
17:08:58.291021 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 11, ack 9, length 28: unknown ctrl-proto (0x80fd), Conf-Request (0x01), id 6, length 12
17:08:58.291398 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 12, ack 11, length 34: IPCP, Conf-Request (0x01), id 7, length 18
17:08:58.291404 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 13, length 24: IPCP, Conf-Ack (0x02), id 2, length 12
17:08:58.364854 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 14, ack 13, length 34: IPCP, Conf-Request (0x01), id 8, length 18
17:08:58.528150 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 15, length 57: compressed PPP data
17:08:58.543256 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 16, length 113: compressed PPP data
17:08:58.618211 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 17, length 178: compressed PPP data
17:08:58.633704 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 18, length 345: compressed PPP data
17:08:59.273347 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 19, length 113: compressed PPP data
17:08:59.428385 IP 200.1.1.1> 85.1.1.1: GREv1, call 46814, seq 20, length 57: compressed PPP data
###########################################################
Причем иногда соединения создаются и через FreeBSD+PF. Но очень редко и не понятно, по какой причине.


"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirxxx , 22-Май-14 23:44 
Еще есть такой нюанс канал в этом офисе, от куда я подключаюсь ассиметричный, на закачку 10Мбит на отдачу 2Мбит. Может в этом проблема. Потому что когда я начинаю в ручную выставлять скорость подключения на внешнем канале 10Мбит полудумлекс некоторое время подключения срабатываю, потом перестают работать. Потом возвращаю в автомат может тоже подключиться а может и не подключиться. Чаще нет. Но вот через UG подключения по VPN работают как часы.
"через PF не устанавливается vpn соединение с mpd5"
Отправлено SDenis , 22-Май-14 23:59 
> Еще есть такой нюанс канал в этом офисе, от куда я подключаюсь
> ассиметричный, на закачку 10Мбит на отдачу 2Мбит. Может в этом проблема.
> Потому что когда я начинаю в ручную выставлять скорость подключения на
> внешнем канале 10Мбит полудумлекс некоторое время подключения срабатываю, потом перестают
> работать. Потом возвращаю в автомат может тоже подключиться а может и
> не подключиться. Чаще нет. Но вот через UG подключения по VPN
> работают как часы.

https://www.pfsense.org/

"через PF не устанавливается vpn соединение с mpd5"
Отправлено SDenis , 23-Май-14 00:04 
>> Еще есть такой нюанс канал в этом офисе, от куда я подключаюсь
>> ассиметричный, на закачку 10Мбит на отдачу 2Мбит. Может в этом проблема.
>> Потому что когда я начинаю в ручную выставлять скорость подключения на
>> внешнем канале 10Мбит полудумлекс некоторое время подключения срабатываю, потом перестают
>> работать. Потом возвращаю в автомат может тоже подключиться а может и
>> не подключиться. Чаще нет. Но вот через UG подключения по VPN
>> работают как часы.
> https://www.pfsense.org/

https://doc.pfsense.org/index.php/PPTP_VPN

"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirxxx , 09-Июн-14 18:28 
Ничего не помогло. Я сейчас вообще ничего не понимаю. Как только в правилах pf определяю политику
block in all
block out log all
или
block all
никакие правила фильтрации типа
pass quick inet proto gre from $lan_net to any keep state
или
pass out on $ext_if proto gre from $lan_net to any keep state
или
pass on { $int_if, $ext_if } proto gre to any keep state
Короче пиши как хочешь но gre нормально не проходит.
Причем pfctl -sr показывает
##############################################
scrub in all fragment reassemble
block drop all
pass quick inet proto tcp from any to any port = ntp flags S/SA keep state
pass quick inet proto tcp from any to any port = ssh flags S/SA keep state
pass quick inet proto tcp from any to any port = smtp flags S/SA keep state
pass quick inet proto tcp from any to any port = domain flags S/SA keep state
pass quick inet proto tcp from any to any port = http flags S/SA keep state
pass quick inet proto tcp from any to any port = https flags S/SA keep state
pass quick inet proto tcp from any to any port = 821 flags S/SA keep state
pass quick inet proto tcp from any to any port = pptp flags S/SA keep state
pass quick inet proto tcp from any to any port = nfsd flags S/SA keep state
pass quick inet proto tcp from any to any port = sunrpc flags S/SA keep state
pass quick inet proto tcp from any to any port = pop3 flags S/SA keep state
pass quick inet proto tcp from any to any port = smtps flags S/SA keep state
pass quick inet proto tcp from any to any port = submission flags S/SA keep state
pass quick inet proto udp from any to any port = domain keep state
pass quick inet proto udp from any to any port = ntp keep state
pass quick inet proto udp from any to any port = sunrpc keep state
pass quick inet proto udp from any to any port = 821 keep state
pass quick inet proto udp from any to any port = 1723 keep state
pass quick inet proto udp from any to any port = nfsd keep state
pass on em1 proto gre all keep state
pass on em0 proto gre all keep state
##############################################
Если в политике блокировки написать
block in log on $ext_if all
Ну тогда и для gre можно правила не прописывать все будет работать.
Не пойму в двух офисах работает с настройками указанными выше в этом бьюсь уже третью неделю не работает.
Пробовал на freebsd 9.2 и на freebsd 10. Сетевые карты поставил intel 1000. Все перепробовал ничего не работает.
Причем с cisco pix 510 в стоящем в другом офисе соединяется без проблем и с pptp server на windows тоже соединяется а вот с mpd5 на freebsd еще в двух офисах отказывается.
конфигурации pf.conf во всех офисах одинаковые, отличаются только названиями интерфейсов.

"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirsxxx , 15-Июн-14 15:08 
Запустил я pf  в режиме отладки и в логе messages стали сыпаться сообщения:
pf_map_addr: selected address 185.88.288.22
где 185.88.288.22 ip адрес внешней сетевой карты
pf: NAT proxy port allocation (50001-65535) failed
Ничего по этим сообщения в интернете я не нашел подскажите что это.

Канал подключения асимметричный 10 мбит закачка 2 мбит отдача. Может все проблемы отсюда идут?

"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirsxxx , 15-Июн-14 15:28 
И что правда никто не сталкивался c такими сообщениями? Что они означают?

pf_map_addr: selected address 185.88.288.22

где 185.88.288.22 ip адрес внешней сетевой карты
pf: NAT proxy port allocation (50001-65535) failed

Ничего по этим сообщения в интернете, я не нашел. Кроме англоязычного форума в котором описан частный случай для решения которого вместо keep state предлагают
использовать no state.
"через PF не устанавливается vpn соединение с mpd5"
Отправлено Ingoa , 16-Июн-14 12:05 
> И что правда никто не сталкивался c такими сообщениями? Что они означают?
> 
pf_map_addr: selected address 185.88.288.22
> где 185.88.288.22 ip адрес внешней сетевой карты
> 
pf: NAT proxy port allocation (50001-65535) failed
> Ничего по этим сообщения в интернете, я не нашел. Кроме англоязычного форума
> в котором описан частный случай для решения которого вместо keep state
> предлагают
> использовать no state.

Раньше у PF была проблема с GRE- не мог более одного коннекта делать (freebsd 6.2)
Как теперь обстоят дела сказать не могу

"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirxxx , 16-Июн-14 13:37 
> Раньше у PF была проблема с GRE- не мог более одного коннекта
> делать (freebsd 6.2)
> Как теперь обстоят дела сказать не могу

Сейчас если PF разрешает прохождение GRE пакетов то соединений можно делать сколько угодно. На практике в разные стороны одновременно около 10 vpn соединений работает  без проблем. Вот только правила как то странно срабатывают в PF для GRE. В одном офисе все работает без проблем с одним общим правилом

pass quick inet proto gre from any to any keep state

а в другом офисе работает тоже, вот только правила нужно описать более подробно.
Например так
pass in $int_if inet proto gre from $lan_net to any keep state
pass out $ext_if inet proto gre from lan_net to any keep state

Вот с чем это связано не понимаю. И очень хочу это узнать. Не люблю работать, когда не до конца все понятно.
И еще не понятно что означают появление данных сообщений в режиме отладки PF

pf_map_addr: selected address 185.88.288.22


где 185.88.288.22 ip адрес внешней сетевой карты

pf: NAT proxy port allocation (50001-65535) failed

"через PF не устанавливается vpn соединение с mpd5"
Отправлено vladimirxxx , 16-Июн-14 13:38 
> Раньше у PF была проблема с GRE- не мог более одного коннекта
> делать (freebsd 6.2)
> Как теперь обстоят дела сказать не могу

Сейчас если PF разрешает прохождение GRE пакетов то соединений можно делать сколько угодно. На практике в разные стороны одновременно около 10 vpn соединений работает  без проблем. Вот только правила как то странно срабатывают в PF для GRE. В одном офисе все работает без проблем с одним общим правилом

pass quick inet proto gre from any to any keep state

а в другом офисе работает тоже, только правила нужно описать более подробно, как показано выше не работает.
Например так
pass in $int_if inet proto gre from $lan_net to any keep state
pass out $ext_if inet proto gre from lan_net to any keep state

Вот с чем это связано не понимаю. И очень хочу это узнать. Не люблю работать, когда не до конца все понятно.
И еще не понятно, что означают появление данных сообщений в режиме отладки PF?

pf_map_addr: selected address 185.88.288.22


где 185.88.288.22 ip адрес внешней сетевой карты

pf: NAT proxy port allocation (50001-65535) failed