Подскажите с настройкой клиент-банка…

ASCII

wan rules

wan_rules.jpg_thumb

dvserg

С лана вроде все ОК, а на Wan у Вас параноя- сделайте общее правило
"Разрешить все tcpudp из LAN subnet to any".

ASCII

@dvserg:

С лана вроде все ОК, а на Wan у Вас параноя- сделайте общее правило
"Разрешить все tcpudp из LAN subnet to any".

Сделал правило, но увы не помогло. Те же сообщения в логах:

Jun 7 14:05:49 pf: 204885 rule 100/0(match): block out on xl0: (tos 0x0, ttl 127, id 17311, offset 0, flags [DF], proto TCP (6), length 181) 192.168.11.12.31954 > 111.111.111.11.2214: FP, cksum 0x15d9 (correct), 2257198530:2257198671(141) ack 1927692587 win 65535

wan-new.jpg_thumb

dvserg

А отключить 2 верхних правила?

ASCII

Отключал, это я сделал в первую очередь :) Ни к каким положительным результатам не приводит. Я уточню, коннект к серверу банка происходит. Вот полный лог stunnel клиента:

2010.06.07 10:06:38 LOG5[2768:3616]: Reading configuration from file stunnel.conf
2010.06.07 10:06:38 LOG7[2768:3616]: Snagged 64 random bytes from C:/.rnd
2010.06.07 10:06:38 LOG7[2768:3616]: Wrote 1024 new random bytes to C:/.rnd
2010.06.07 10:06:38 LOG7[2768:3616]: RAND_status claims sufficient entropy for the PRNG
2010.06.07 10:06:38 LOG7[2768:3616]: PRNG seeded successfully
2010.06.07 10:06:38 LOG7[2768:3616]: Certificate: stunnel.pem
2010.06.07 10:06:38 LOG7[2768:3616]: Certificate loaded
2010.06.07 10:06:38 LOG7[2768:3616]: Key file: stunnel.pem
2010.06.07 10:06:38 LOG7[2768:3616]: Private key loaded
2010.06.07 10:06:38 LOG7[2768:3616]: SSL context initialized for service pop3s
2010.06.07 10:06:38 LOG7[2768:3616]: Certificate: stunnel.pem
2010.06.07 10:06:38 LOG7[2768:3616]: Certificate loaded
2010.06.07 10:06:38 LOG7[2768:3616]: Key file: stunnel.pem
2010.06.07 10:06:38 LOG7[2768:3616]: Private key loaded
2010.06.07 10:06:38 LOG7[2768:3616]: SSL context initialized for service imaps
2010.06.07 10:06:38 LOG7[2768:3616]: Certificate: stunnel.pem
2010.06.07 10:06:38 LOG7[2768:3616]: Certificate loaded
2010.06.07 10:06:38 LOG7[2768:3616]: Key file: stunnel.pem
2010.06.07 10:06:38 LOG7[2768:3616]: Private key loaded
2010.06.07 10:06:38 LOG7[2768:3616]: SSL context initialized for service ssmtp
2010.06.07 10:06:38 LOG7[2768:3616]: Certificate: stunnel.pem
2010.06.07 10:06:38 LOG7[2768:3616]: Certificate loaded
2010.06.07 10:06:38 LOG7[2768:3616]: Key file: stunnel.pem
2010.06.07 10:06:38 LOG7[2768:3616]: Private key loaded
2010.06.07 10:06:38 LOG7[2768:3616]: SSL context initialized for service client
2010.06.07 10:06:38 LOG5[2768:3616]: Configuration successful
2010.06.07 10:06:38 LOG5[2768:3616]: No limit detected for the number of clients
2010.06.07 10:06:38 LOG7[2768:3616]: FD=148 in non-blocking mode
2010.06.07 10:06:38 LOG7[2768:3616]: Option SO_REUSEADDR set on accept socket
2010.06.07 10:06:38 LOG7[2768:3616]: Service pop3s bound to 0.0.0.0:995
2010.06.07 10:06:38 LOG7[2768:3616]: Service pop3s opened FD=148
2010.06.07 10:06:38 LOG7[2768:3616]: FD=136 in non-blocking mode
2010.06.07 10:06:38 LOG7[2768:3616]: Option SO_REUSEADDR set on accept socket
2010.06.07 10:06:38 LOG7[2768:3616]: Service imaps bound to 0.0.0.0:993
2010.06.07 10:06:38 LOG7[2768:3616]: Service imaps opened FD=136
2010.06.07 10:06:38 LOG7[2768:3616]: FD=160 in non-blocking mode
2010.06.07 10:06:38 LOG7[2768:3616]: Option SO_REUSEADDR set on accept socket
2010.06.07 10:06:38 LOG7[2768:3616]: Service ssmtp bound to 0.0.0.0:465
2010.06.07 10:06:38 LOG7[2768:3616]: Service ssmtp opened FD=160
2010.06.07 10:06:38 LOG7[2768:3616]: FD=168 in non-blocking mode
2010.06.07 10:06:38 LOG7[2768:3616]: Option SO_REUSEADDR set on accept socket
2010.06.07 10:06:38 LOG7[2768:3616]: Service client bound to 0.0.0.0:1123
2010.06.07 10:06:38 LOG7[2768:3616]: Service client opened FD=168
2010.06.07 10:06:38 LOG5[2768:3616]: stunnel 4.33 on x86-pc-mingw32-gnu with OpenSSL 1.0.0 29 Mar 2010
2010.06.07 10:06:38 LOG5[2768:3616]: Threading:WIN32 SSL:ENGINE Sockets:SELECT,IPv6
2010.06.07 10:07:47 LOG7[2768:604]: Service client accepted FD=240 from 127.0.0.1:2084
2010.06.07 10:07:47 LOG7[2768:604]: Creating a new thread
2010.06.07 10:07:47 LOG7[2768:604]: New thread created
2010.06.07 10:07:47 LOG7[2768:560]: Service client started
2010.06.07 10:07:47 LOG7[2768:560]: FD=240 in non-blocking mode
2010.06.07 10:07:47 LOG7[2768:560]: Option TCP_NODELAY set on local socket
2010.06.07 10:07:47 LOG5[2768:560]: Service client accepted connection from 127.0.0.1:2084
2010.06.07 10:07:47 LOG7[2768:560]: FD=276 in non-blocking mode
2010.06.07 10:07:47 LOG6[2768:560]: connect_blocking: connecting 194.143.138.138:2214
2010.06.07 10:07:47 LOG7[2768:560]: connect_blocking: s_poll_wait 194.143.138.138:2214: waiting 10 seconds
2010.06.07 10:07:47 LOG5[2768:560]: connect_blocking: connected 194.143.138.138:2214
2010.06.07 10:07:47 LOG5[2768:560]: Service client connected remote server from 127.0.0.1:2085
2010.06.07 10:07:47 LOG7[2768:560]: Remote FD=276 initialized
2010.06.07 10:07:47 LOG7[2768:560]: Option TCP_NODELAY set on remote socket
2010.06.07 10:07:47 LOG7[2768:560]: SSL state (connect): before/connect initialization
2010.06.07 10:07:47 LOG7[2768:560]: SSL state (connect): SSLv3 write client hello A
2010.06.07 10:07:47 LOG3[2768:560]: SSL_connect: Peer suddenly disconnected
2010.06.07 10:07:47 LOG5[2768:560]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2010.06.07 10:07:47 LOG7[2768:560]: Service client finished (0 left)

сбрасывается соединение, а в нормальном виде должно быть так:

2010.06.07 10:09:11 LOG7[2768:604]: Service client accepted FD=268 from 127.0.0.1:2108
2010.06.07 10:09:11 LOG7[2768:604]: Creating a new thread
2010.06.07 10:09:11 LOG7[2768:604]: New thread created
2010.06.07 10:09:11 LOG7[2768:1476]: Service client started
2010.06.07 10:09:11 LOG7[2768:1476]: FD=268 in non-blocking mode
2010.06.07 10:09:11 LOG7[2768:1476]: Option TCP_NODELAY set on local socket
2010.06.07 10:09:11 LOG5[2768:1476]: Service client accepted connection from 127.0.0.1:2108
2010.06.07 10:09:11 LOG7[2768:1476]: FD=280 in non-blocking mode
2010.06.07 10:09:11 LOG6[2768:1476]: connect_blocking: connecting 194.143.138.138:2214
2010.06.07 10:09:11 LOG7[2768:1476]: connect_blocking: s_poll_wait 194.143.138.138:2214: waiting 10 seconds
2010.06.07 10:09:18 LOG5[2768:1476]: connect_blocking: connected 194.143.138.138:2214
2010.06.07 10:09:18 LOG5[2768:1476]: Service client connected remote server from 127.0.0.1:2109
2010.06.07 10:09:18 LOG7[2768:1476]: Remote FD=280 initialized
2010.06.07 10:09:18 LOG7[2768:1476]: Option TCP_NODELAY set on remote socket
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): before/connect initialization
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 write client hello A
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 read server hello A
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 read server certificate A
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 read server done A
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 write client key exchange A
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 write change cipher spec A
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 write finished A
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 flush data
2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 read finished A
2010.06.07 10:09:18 LOG7[2768:1476]: 1 items in the session cache
2010.06.07 10:09:18 LOG7[2768:1476]: 2 client connects (SSL_connect())
2010.06.07 10:09:18 LOG7[2768:1476]: 1 client connects that finished
2010.06.07 10:09:18 LOG7[2768:1476]: 0 client renegotiations requested
2010.06.07 10:09:18 LOG7[2768:1476]: 0 server connects (SSL_accept())
2010.06.07 10:09:18 LOG7[2768:1476]: 0 server connects that finished
2010.06.07 10:09:18 LOG7[2768:1476]: 0 server renegotiations requested
2010.06.07 10:09:18 LOG7[2768:1476]: 0 session cache hits
2010.06.07 10:09:18 LOG7[2768:1476]: 0 external session cache hits
2010.06.07 10:09:18 LOG7[2768:1476]: 0 session cache misses
2010.06.07 10:09:18 LOG7[2768:1476]: 0 session cache timeouts
2010.06.07 10:09:18 LOG6[2768:1476]: SSL connected: new session negotiated
2010.06.07 10:09:18 LOG6[2768:1476]: Negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
2010.06.07 10:09:19 LOG7[2768:1476]: Socket closed on read
2010.06.07 10:09:19 LOG7[2768:1476]: SSL write shutdown
2010.06.07 10:09:19 LOG7[2768:1476]: SSL alert (write): warning: close notify
2010.06.07 10:09:19 LOG6[2768:1476]: SSL_shutdown successfully sent close_notify
2010.06.07 10:09:19 LOG7[2768:1476]: SSL alert (read): warning: close notify
2010.06.07 10:09:19 LOG7[2768:1476]: SSL closed on SSL_read
2010.06.07 10:09:19 LOG7[2768:1476]: Socket write shutdown
2010.06.07 10:09:19 LOG5[2768:1476]: Connection closed: 36 bytes sent to SSL, 937 bytes sent to socket

dvserg

Ну тогда нужно читать про этот туннельв мануалах - не пытается ли сервер Банка установить обратный коннект? Это также можно посмотреть в стейтах (states). Если что - можно будет попробовать сделать его мапингом.

Также смотрите - в pfsense есть тоже пакет stunnel. Может поиграть с ним (если эта таже программа)?

Eugene

Интересно откуда block out появляется.
Глянь /tmp/rules.debug
Найди там это правило (с block out on xl0) и что там в округе этого правило? какие-нибудь комменты?

dvserg

Торможу чего-то - 'block out on xl0:' ясно говорит что исходящий пакет c WAN не пропускается. Там-же NAT от имени WAN все отправляет. Нужно правило 'разрешить tcp/udp с WAN интерфейса в любую сторону'.

Eugene

@dvserg:

Торможу чего-то - 'block out on xl0:' ясно говорит что исходящий пакет c WAN не пропускается.
Нужно правило 'разрешить tcp/udp с WAN интерфейса в любую сторону'.

Через гуи сделать out невозможно, можно только in.

dvserg

@Evgeny:

@dvserg:

Торможу чего-то - 'block out on xl0:' ясно говорит что исходящий пакет c WAN не пропускается.
Нужно правило 'разрешить tcp/udp с WAN интерфейса в любую сторону'.

Через гуи сделать out невозможно, можно только in.

Значит во-истину торможу ???

Eugene

@dvserg:

@Evgeny:

@dvserg:

Торможу чего-то - 'block out on xl0:' ясно говорит что исходящий пакет c WAN не пропускается.
Нужно правило 'разрешить tcp/udp с WAN интерфейса в любую сторону'.

Через гуи сделать out невозможно, можно только in.

Значит во-истину торможу ???

Похоже выходные удались! ;-)))

dvserg

Похоже выходные удались! ;-)))

Нуууу есть немного.. ;)

ASCII

Я посмотрел /tmp/rules.debug и ничего там криминального не нашел, в частности указаний на block out on xl0. Там всего две строки содержащие "block out"

Block all IPv6

block in quick inet6 all
block out quick inet6 all
#–-------------------------------------------------------------------------

default deny rules

#---------------------------------------------------------------------------
block in log quick all label "Default deny rule"
block out log quick all label "Default deny rule"

что мне лично кажется совсем не тем, что может мешать :)

Eugene

Странно… У тебя ж в логе говорится "правило номер 102"
погляди pfctl -sr -vv
что там в сто втором правиле?

ASCII

@Evgeny:

Странно… У тебя ж в логе говорится "правило номер 102"
погляди pfctl -sr -vv
что там в сто втором правиле?

Да, команда показывает правило 102:

[Inserted: uid 0 pid 50821]
@102 block drop out log quick all label "Default deny rule"
[Evaluations: 45 Packets: 45 Bytes: 1800 States: 0 ]

я пробовал удалять дефолтное запрещающее все правило на WAN интерфейсе, и менял его на разрешающее, в итоге 102 правило удаляется и генирируется другое с таким же содержимым

[Inserted: uid 0 pid 1400]
@98 block drop out log quick all label "Default deny rule"
[Evaluations: 2 Packets: 2 Bytes: 362 States: 0 ]

и лог:

Jun 10 09:16:49 pf: 1. 515161 rule 98/0(match): block out on xl0: (tos 0x0, ttl 127, id 31169, offset 0, flags [DF], proto TCP (6), length 181) 77.108.92.4.17532 > 194.143.138.138.2214: FP, cksum 0x89dd (correct), 2293132943:2293133084(141) ack 2406608847 win 65535

Eugene

Так, стоп. А что```
pfctl -sr | grep xl0

ASCII

кажет вот это:

block drop in log quick on xl0 inet proto udp from any port = bootps to 10.6.0.0/24 port = bootpc label "block dhcp client out wan"
block drop in on ! xl0 inet from 77.108.92.0/29 to any
block drop in on xl0 inet6 from fe80::204:75ff:fec2:54f6 to any
block drop in log quick on xl0 inet from 10.0.0.0/8 to any label "block private networks from wan block 10/8"
block drop in log quick on xl0 inet from 127.0.0.0/8 to any label "block private networks from wan block 127/8"
block drop in log quick on xl0 inet from 172.16.0.0/12 to any label "block private networks from wan block 172.16/12"
block drop in log quick on xl0 inet from 192.168.0.0/16 to any label "block private networks from wan block 192.168/16"
block drop in log quick on xl0 from <bogons>to any label "block bogon networks from wan"
pass out quick on xl0 proto icmp all keep state label "let out anything from firewall host itself"
pass out quick on xl0 all flags S/SA keep state (tcp.closed 5) label "let out anything from firewall host itself"
pass out quick on xl0 all flags S/SA keep state label "let out anything from firewall host itself"
pass in quick on xl0 reply-to (xl0 77.108.92.1) inet proto tcp from any to 10.6.0.61 port = smtp flags S/SA keep state label "USER_RULE: NAT SMTP (internet) -> SMTP (local: 10.6.0.61)"
block drop in quick on xl0 reply-to (xl0 77.108.92.1) inet all label "USER_RULE: block all"
pass in quick on xl0 inet proto tcp from any port = ftp-data to (xl0) port > 49000 flags S/SA keep state label "FTP PROXY: PASV mode data connection"</bogons>

Eugene

Похоже клиент или сервер закрывает tcp-connection.
Давай смотреть более детально

tcpdump -ni xl0 host 194.143.138.138

На сколько я понимяю 194.143.138.138 - это удалённая сторона.

ASCII

@Evgeny:

Похоже клиент или сервер закрывает tcp-connection.
Давай смотреть более детально
tcpdump -ni xl0 host 194.143.138.138
На сколько я понимяю 194.143.138.138 - это удалённая сторона.

да! я сам только сегодня дошел до звонка в тех. поддержку банка, где мне сказали что связь с ними возможна только с IP указанного в заявке на подключение, и чтобы его сменить нужно подавать еще какую-то заявку :) В общем поменял WAN адрес на нужный и все заработало. Извиняюсь за отнятое время, и спасибо за помощь)

Eugene

@ASCII:

@Evgeny:
Похоже клиент или сервер закрывает tcp-connection.
Давай смотреть более детально
tcpdump -ni xl0 host 194.143.138.138
На сколько я понимяю 194.143.138.138 - это удалённая сторона.
да! я сам только сегодня дошел до звонка в тех. поддержку банка, где мне сказали что связь с ними возможна только с IP указанного в заявке на подключение, и чтобы его сменить нужно подавать еще какую-то заявку :) В общем поменял WAN адрес на нужный и все заработало. Извиняюсь за отнятое время, и спасибо за помощь)

Ничего, бывает. Хорошо, что заработало, а то Банк всё-таки ;-)