Через PF не устанавливается vpn соединение с mpd5

[vladimirxxx]

В двух офисах стоят шлюзы на 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 или в mpd5.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[vladimirxxx]

Решил посмотреть 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. Но очень редко и не понятно, по какой причине.

[vladimirxxx]

Так и не могу разобраться в чем проблема. Не пойму проблема в работе PF или mpd5 сервера. Куда копать. Вообще PF хороший файрвол или лучше посмотреть в сторону ipfirewall? Раньше PF очень даже устраивал.

[Alex Keda]

провайдер точно ничё не рубит?
то что раньше не рубил, а тут вдруг начал - ничё не значит, и не такие чудесные совпадения в жизни случались...

[vladimirxxx]

Завтра уточню у провайдера. Есть такое подозрение. Во всех офисах с такими конфигами работает без проблем, а здесь заморочка какая то. Неделю бьюсь уже. Канал подает Вымпелком через оптику, но канала какой то древний в том плане, что подключение ассиметричное на закачку 10Мбит а отдачу 2 Мбит. Правда все это конечно хорошо но вот через тормозное UG все работает. А через FreeBSD + PF нет. Иногда подсоединяется и через FreeBSD но закономерности не вижу. Буду рад любому совету, что еще можно проверить.

[admin_sv]

Недавно столкнулся с приколами freebsd 9 в области pf: В pf есть параметр отвечающий за количество записей в таблице keep state, так вот он очень маленький, как только таблица заполнилась другие пакеты игнорируются. Убери из правила keep state.

[andrian_freebsd]

не могу сказать на 100%, но когда поднимается vpn в списке сетевых интерфейсов должны быть имена "ng0" - первый, "ng1" - второй ... Потому у вас в конфиге "pf" должно быть прописаны правила для "ng0" и т.д. А уже на этих интерфесах и можна ограничывать скорость и блокировать порты от клиентов что б не сожерали трафик. Посмотрите "tcpdump" что происходит у вас на интерфейсах, по логе mpd определите проблемного клиента и на каком интерфейсе он сидит.

[andrian_freebsd]

Добавте на внешний интерфейс правило для pptp 1723/tcp #Point-to-point tunnelling protocol .

[Sadok123]

Недавно столкнулся с приколами freebsd 9 в области pf: В pf есть параметр отвечающий за количество записей в таблице keep state, так вот он очень маленький, как только таблица заполнилась другие пакеты игнорируются. Убери из правила keep state.

м... keep state там давно включать не надо, как мне казалось. оно по дефолту работает.

[admin_sv]

да keep state сам дописывается pf-ом. есть предложение включит в конфиг 2 строчки:

Код: Выделить всё

set debug loud

сделает pf общительным. Попытайтесь подключатся он сам все расскажет.
А потом попробовать добавить вот такую строчку:

Код: Выделить всё

set limit states 10000

и еще потестить.
2 строка увеличит размер записей в таблице отвечающей за правила в с keep state.

[vladimirxxx]

Ничего не помогло. Я сейчас вообще ничего не понимаю. Как только в правилах 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 во всех офисах одинаковые, отличаются только названиями интерфейсов.

[vladimirxxx]

Еще такая информация запустил я pf в режиме отладки и в логе messages стали сыпаться сообщения:
pf_map_addr: selected address 185.88.288.22
где 185.88.288.22 ip адрес внешней сетевой карты
pf: NAT proxy port allocation (50001-65535) failed
Ничего по этим сообщения в интернете, я не нашел. Подскажите что это?

[Гость]

а разве pf научился через себя пропускать больше одного gre подкючения?

[vladimirxxx]

В смысле более одного пакета? Если gre подключение идет из внутренней сети тогда как я понимаю пакет gre должен пройти через внутренний интерфейс и внешний интерфейс, а затем обратно. Чему и соответствует правило

Код: Выделить всё

pass quick inet proto gre from $lan_net to any keep state

при политике

Код: Выделить всё

block in all
block out log all

В pflog0 при просмотре видно видно, что gre пакеты проходят на обоих интерфейсах. Но vpn подключение не устанавливается. Хотя в других двух офисах с данными настройками все работает. И из этого офиса я могу подключиться с vpn сервером на cisco pix 506 и vpn сервером на windows 7. А вот с mpd5 на freebsd9.2 + pf нет.

[vladimirxxx]

И что правда никто не сталкивался 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 на шлюзе и пытаться организовать больше одного pptp подключения изнутри наружу на внешний vpn сервер, то на втором подключении будет затык - ошибка 691. Связано с тем, что pf пропускает только одно gre подключение. Как-то так.

[vladimirxxx]

Еще в двух офисах стоят freebsd + pf с аналогичными настройками и там проблем с количеством подключений нет. Работает одновременно до 10 vpn подключений.
Связался с оператором говорит ничего не блокирует. Смотрель tcpdump ничего не блокируется на внешнем интерфейсе удаленного офиса где запущен vpn сервер видно как приходят gre пакеты. Эти gre пакеты как то странно висят и затем появляется сообщение об ошибке. В удаленном офисе тоже проверял не блокируются gre пакеты.

[andrian_freebsd]

А в конфиге pf.conf на работающем сервере эсть строки сборки пакетов? От как у меня?

Код: Выделить всё

#scrab
set skip on lo0
scrub in on $if_inet all fragment reassemble min-ttl 20 max-mss 1462
scrub in on $if_inet all no-df
scrub out on $if_inet all fragment reassemble min-ttl 20 max-mss 1462
scrub on $if_inet all reassemble tcp

А воопще ето нужно когда виндовс фрагментванные пакеты посылает.

Потом, а протокол gre на внешнем и внутреннем интерфейсе нужно пропускать:

Код: Выделить всё

#gre
pass in on $if_int proto gre from <andrian_host> to any
pass out log on $if_int proto gre from any to <andrian_host>

$if_int - ето мой внутренний интерфейс в pf.conf, <andrian_host> - айпі или днс имя хоста прописано в таблице.
ну тоже gre на внешнем

Код: Выделить всё

#gre
pass in quick on $if_inet proto gre from <ext_client> to ($if_inet)

Для мене ну очень не понятны твои политики, (а где in или out) например:

Код: Выделить всё

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

Ти лучше напиши каких интерфейсов ето должно касатся, например:

Код: Выделить всё

# allow TCP and UDP
pass [b]in[/b] quick on [b]$ext_if [/b]proto udp from any to ($ext_if) port $udp_services keep state
pass [b]out[/b] quick on [b]$ext_if [/b] proto tcp from ($ext_if) to any port $tcp_services keep state

а ($ext_if) - потому что ты ж написал
#ALLOW NAT
nat on $ext_if from $lan_net to any -> ($ext_if)
зничить мир будет видит айпи адрес твой внешний, тогда и выпускать смисл все, может и политик тогда не надо?!
Посмотри внемательно на настройки pf.conf вот документация http://www.openbsd.org/faq/pf/index.html

[vladimirxxx]

А в конфиге pf.conf на работающем сервере эсть строки сборки пакетов? От как у меня?

Код: Выделить всё
#scrab
set skip on lo0
scrub in on $if_inet all fragment reassemble min-ttl 20 max-mss 1462
scrub in on $if_inet all no-df
scrub out on $if_inet all fragment reassemble min-ttl 20 max-mss 1462
scrub on $if_inet all reassemble tcp

Согласно описанию pf которое Вы мне в конце прислали, то в простейшем варианте можно

Код: Выделить всё

scrub in all 

и srub будет работать

Потом, а протокол gre на внешнем и внутреннем интерфейсе нужно пропускать:

Код: Выделить всё
#gre
pass in on $if_int proto gre from <andrian_host> to any
pass out log on $if_int proto gre from any to <andrian_host>
$if_int - ето мой внутренний интерфейс в pf.conf, <andrian_host> - айпі или днс имя хоста прописано в таблице.
ну тоже gre на внешнем

Код: Выделить всё
#gre
pass in quick on $if_inet proto gre from <ext_client> to ($if_inet)

Опять согласно мануалу на pf можно расписывать как хочется подробно хоть по ip адресам кому куда ходить
но запись

Код: Выделить всё

pass quick on { $int_if, $ext_if } proto gre to any keep state

говорит о том, что на данных интерфейса все пакеты с протоколом gre пропуска куда угодно, а
если кто то установить соединение то keep state значить и в обратную сторону для того кто установил
соединение тоже пакеты пропускать.
Вообще можно написать

pass quick proto gre all keep state

тоже должно работать интерфейсы и направления pf сам определяет.

Ти лучше напиши каких интерфейсов ето должно касатся, например:

Код: Выделить всё
# allow TCP and UDP
pass in quick on $ext_if proto udp from any to ($ext_if) port $udp_services keep state
pass out quick on $ext_if proto tcp from ($ext_if) to any port $tcp_services keep state

здесь тоже самое можно описывать можно просто написать

Код: Выделить всё

pass quick inet proto udp to any port $udp_services keep state
pass inet proto tcp to any port $tcp_services keep state

Это значит пропускать на всех интерфейсах от кого угодно куда угодно указанные в макросах порты с сохранение состояния соединения.

Так что если есть реально предложения, из-за чего может нормально не работать PPTP соединения пишите.

Еще в двух офисах стоят такие же freebsd+pf конфигурация файлов аналогичная между собой у них все работает без проблем и к ним все подсоединяется сколько хочешь vpn клиентов.
Во только с третим офисом вот такая проблема. Причем из этот проблемного офиса подключаюсь к офису где стоит cisco pix 506 и там запущен vpn сервер pptp и к нему все подключается.
Значит gre проходит. Еще есть vpn сервер запущен на windows 7 стандартно и к нему подключается без проблем.
Так что похоже gre проходит без проблем, что показывает tcpdump смотрел на всех интерфейсах и на стороне клиента и сервера, все там проходит.
Ощущение что есть какая то не совместимость или кривая работа при подключении через freebsd+pf к freebsd+pf+mpd5.
Потому что когда я подключаюсь через usergate 5 или на прямую из дома или от куда угодно к freebsd+pf+mpd5 все работает без проблем.

Так что пишите буду пробовать.
PS вместо srub in all
поставил как мне рекомендовали причем на обоих pf

Код: Выделить всё

scrub in on $if_inet all fragment reassemble min-ttl 20 max-mss 1462
scrub in on $if_inet all no-df
scrub out on $if_inet all fragment reassemble min-ttl 20 max-mss 1462
scrub on $if_inet all reassemble tcp

и пробовал более конкретно прописать правила для протокола gre как Вы мне рекомендовали.
Ситуацию ни как это не изменило... Если чесно то с этой проблемой не могу разобрать уже месяц. Я в шоке.

[Alex Keda]

а чё, какие-то проблемы разом поднять gre и l2tp на сервере?
я вот для одних клиентов так и сделал.
у кого нормально раобтает - те просто жмут при настройке далее, далее, далее.
а те у кого ненормально, заходят в настройки и выбирают тип ВПН - l2tp

Код: Выделить всё

grep -v '#' /usr/local/etc/mpd5/mpd.conf
startup:


default:
        load pptp_server
        load l2tp_server

pptp_server:
        set ippool add pool1 192.168.150.101 192.168.150.199
        create bundle template B
        set iface enable proxy-arp
        set iface idle 1800
        set iface enable tcpmssfix
        set ipcp yes vjcomp
        set ipcp ranges 192.168.150.254/32 ippool pool1
        set ipcp dns 192.168.140.1
        set bundle enable compression
        set ccp yes mppc
        set mppc yes e40
        set mppc yes e128
        set mppc yes stateless
        create link template P pptp
        set link action bundle B
        set link enable multilink
        set link yes acfcomp protocomp
        set link no pap chap
        set link enable chap
        set link keep-alive 10 60
        set link mtu 1460
        set pptp self 123.123.123.123
        set auth enable system-acct
        set link enable incoming

l2tp_server:
        set ippool add pool1 192.168.150.101 192.168.150.199
        create bundle template C
        set iface enable proxy-arp
        set iface idle 1800
        set iface enable tcpmssfix
        set ipcp yes vjcomp
        set ipcp ranges 192.168.150.254/32 ippool pool1
        set ipcp dns 192.168.140.1
        set bundle enable compression
        set ccp yes mppc
        set mppc yes e40
        set mppc yes e128
        set mppc yes stateless
        create link template L l2tp
        set link action bundle C
        set link enable multilink
        set link yes acfcomp protocomp
        set link no pap chap
        set link enable chap
        set link keep-alive 10 60
        set link mtu 1460
        set l2tp self 123.123.123.123
        set auth enable system-acct
        set link enable incoming

[andrian_freebsd]

C

scrub in all

не согласен так как на петле lo интерфейсе нет нужди сбирать пакеты.

[andrian_freebsd]

Еще такая информация запустил я pf в режиме отладки и в логе messages стали сыпаться сообщения:
pf_map_addr: selected address 185.88.288.22
где 185.88.288.22 ip адрес внешней сетевой карты
pf: NAT proxy port allocation (50001-65535) failed
Ничего по этим сообщения в интернете, я не нашел. Подскажите что это?

У вас на интерфейсе динамические адреса, или что ето за адрес 185.88.288.22, у вас же я так понял должен быть 200.1.1.1?
А каким образом у вас доступ к интернету организовано на №3 офисе?

[vladimirxxx]

l2tp_server

Да я так уже настроил, работает без проблем. Но l2tp сам по себе не поддерживает шифрования и нужно отключать в windows через реестр IPsec, что не очень удобно.
Мне уже стало дело принципа почему не работает gre через pf, хотя в других офисах в такой конфигурации все работает.
Сейчас времени будет побольше запущу IPFW и попробую через него, блин больше чем уверен все будет работать.
Но к PF я больше привык и хотелось бы работать с ним.

не согласен так как на петле lo интерфейсе нет нужди сбирать пакеты.

Код: Выделить всё

set skip on lo0

и никаких проблем.

У вас на интерфейсе динамические адреса, или что ето за адрес 185.88.288.22, у вас же я так понял должен быть 200.1.1.1?
А каким образом у вас доступ к интернету организовано на №3 офисе?

Извините сам запутался т.к. адреса вымышленные, действительно должен быть 200.1.1.1, это адрес внешней сетевой карты подключенной к интернет.
Адрес статический. Подключен через провайдера Вымпелком оборудование установлено Nortel Networks 1800-24T.

[vladimirxxx]

В режиме отладки pf при подключении с vpn клиента появляется сообщение

Код: Выделить всё

 kernel: pf: NAT proxy port allocation (1024-65535) failed

Что оно означает толком в интернете ничего не нашел.
Кто может объяснить, что это.
правила nat писал двух видов
так

Код: Выделить всё

nat on $ext_if from $lan_net to any -> ($ext_if) port 1024:65535

и так

Код: Выделить всё

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

все равно это сообщение вылазит когда с клиента из внутренней сети подключиться к vpn серверу.
Мне кажется проблема именно в этом и если с этим разобраться то должно заработать.

[vladimirxxx]

Нашел описание данной проблемы
http://lists.freebsd.org/pipermail/free ... 53699.html
и в нем говорится, что это Responsible:freebsd-bugs и как решение предложено воспользоваться патчем код
которого представлен внизу.
Как воспользоваться данным кодом или как то нужно обновить sys/contrib/pf/net/pf_lb.c ?