» Kerio Control (ex Kerio WinRoute Firewall)

Maza777
Нет, у меня ситуация несколько иная http://www.avsoft.ru/forum/read.php?PAGE_NAME=read&FID=21&TID=13969&TITLE_SEO=13969-dns-lookup-failed&%3FFID=21&%3FPAGE_NAME=list . Просто источник проблемы м.б. один и тот же - глюки в Веб-фильтре.

HankHank
для правила DNS я протокол инспектор выключал, это же я так понимаю и есть web filter он типа

подкажите люди добрые.
имею работающий веб фильтр, категория соц сети блокирует сайт если он идёт через 80-й порт, как только он переходит на 443-й веб фильтр уже бесполезен. если же прописывать URL по маске, то тоже самое по 80-му порту блокируется сайт, по 443-у нет.
так вот вопрос: можно ли вообще как-то фильтровать\блокировать\разрешать трафик по https ?

neyasyt9
Можно если создать на Kerio Control сертификат и установить его на всех клиентах.

Столкнулся c проблемой на Win 10 после установки vpn клиента 8/9 версии. Даже без подключения к VPN серверу в таблице маршрутизации висят маршруты до VPN сервера. Отлично помню, раньше на winxp, win7 таких проблем не наблюдалось, необходимые маршруты появлялись только после подключения клиента к VPN серверу.
Очистка и обновления таблицы маршрутизации не помогли, как впрочем и переустановка клиента. Приходится держать клиента в режиме постоянное соединение, чтобы находясь даже в самом офисе днс имена нормально резолвились.
Кто-то сталкивался с таким поведением?

Maza777
У меня для DNS-правила внутренней сети (LAN->PUBLIC) стоит "по умолчанию". Как я понимаю, важно Protocol Inspector указать именно для этого правила, не для брандмауэра.
Попробую поставить "нет".

Вообще, с этим инспектором большие непонятки. Статьи http://kb.kerio.com/product/kerio-control/security/protocol-inspection-in-kerio-control-1689.html явно недостаточно. Где бы посмотреть толкование применения, в каких правилах инспектор нужен, а в каких - нет?

HankHank
Инспектор это по сути компонент сетевой карты, для извлечения из потока трафика статистической информации, он нужен для антивируса, ids, правил, статичтики. У нас он отключен только для входящиего трафика и некоторых фтп серверов.

Iacoyn
что-то не получается. где я мог не правильно сделать?

attaattaatta
Не поделитесь ссылочкой, откуда инфо ?
Слишком много лажи в инете по настройкам KC, так что даже документации разработчиков нужно верить с осторожностью. Надо проверять на практике.
К примеру, они рекомендуют отказываться от Protocol Inspector'а в правилах для клиент-банков. У меня же их штук пять разных, и у всех стоит "по умолчанию". Работает без проблем.

HankHank
Инфо из головы, я с ним с его рождения работаю =)


Цитата:

К примеру, они рекомендуют отказываться от Protocol Inspector'а в правилах для клиент-банков.

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

attaattaatta

Цитата:

это просто лишняя нагрузка на него, и повод для глюков, если вы только трафик секьюрный не расшифровываете на через керио

Какова эта нагрузка на процессор или другие ресурсы по сравнению с отключенным инспектором, на ваш взгляд, или по документации ?


Цитата:

Инфо из головы, я с ним с его рождения работаю

Ну, коли нет живой ссылки, поделитесь знанием, в каких правилах
http://www.avsoft.ru/bitrix/components/bitrix/forum.interface/show_file.php?fid=62041& вы бы отключили Protocol Inspector ?

HankHank
Все зависит от ваших потребностей и причин для его отключения.

attaattaatta
А без зауми можно ?
У меня на отдельных компах временами появляется сообщение "DNS Lookup Failed" http://forum.ru-board.com/topic.cgi?forum=8&topic=45222&start=3020#3 , которое само и проходит.
Хочу разобраться в причинах. Такие простые потребности.

HankHank
А при чем тут protocol inspector ? разбирайтесь с днс. Не вы один тут с такими проблемами. При этом у меня 4 керио прокси 8 версии и ни с одним таких проблем нету. Может стоит смотреть на днс которыми вы пользуетесь. У меня используются внутренние на контроллерах домена, с них форвардит на гугловские паблики.

attaattaatta
DNS внешние. Пробовал разные.
Некорректную работу Proxy Inspector или его применения в правилах рассматриваю как один из вариантов поиска проблемы.
В 6-ой версии KWF "DNS Lookup Failed" не вылезало.
Правила были те же, DNS - тоже.

Добавлено:

Цитата:

Не вы один тут с такими проблемами.

У кого такая же проблема ? Подайте голос.

attaattaatta

Цитата:

у меня 4 керио прокси 8 версии и ни с одним таких проблем нету

Вы принципиально на 9-ю не переходите ? По принципу, "работает, и не трожь", или по каким другим соображениям ?

HankHank
Этож продакшен. Девятка еще не объезжена. Объездят ее кериоты, и мы, тогда уже можно на боевые ставить.

attaattaatta

Цитата:

Этож продакшен. Девятка еще не объезжена. Объездят ее кериоты, и мы, тогда уже можно на боевые ставить.

Дык, кериоты что-то исправляют и одновременно сажают новые баги. Я ввязался по жёсткой необходимости во вневиндовую версию. Сначала 8-ю, потом 9-ю. Всё, вроде, настроил.

Попутно выяснил, что фильтр слов глючит. При этом режет отдельные страницы. Отключил его нафиг и заодно весь контент-фильтр. Отображается теперь корректно.

А вот "DNS Lookup Failed" не могу победить. Вроде, не часто вылезает. И само же налаживается. Но, бывают ситуации, когда эти 5-10 минут отказа броузера отобразить нужную страничку очень критичны. Отключал антивирус с защитой от вторжения, не помогает. Перед праздниками целую неделю злополучное сообщение не вылезало. Хуже всего, что не прослеживается систематика проявления. Не понятно, как ловить.

Потому чисто умозрительно вынужден заново перелопачивать TP и все настройки KC.

attaattaatta

Сегодня после долгого перерыва вылезло на одном из компов опять. В web.log такая запись:

[10/Mar/2016 16:16:29] 192.168.4.22 - "Swiffy Output" http://content.rbc.medialand.ru/t17/a153650/b299002/768x600.swfgsd.html?fc=1239&r5850=5850&link1=http%3A//content.rbc.medialand.ru/http%253A//rbc.ru//%3Fhttp%253A//engine.rbc.medialand.ru/reference%253Fgid%253D6%2526pid%253D1239%2526bid%253D299003%2526rid%253D834333761&clickTAG=http%3A//content.rbc.medialand.ru/http%253A//rbc.ru//%3Fhttp%253A//engine.rbc.medialand.ru/reference%253Fgid%253D6%2526pid%253D1239%2526bid%253D299003%2526rid%253D834333761&link2=http%3A//content.rbc.medialand.ru/http%253A//rbc.ru//%3Fhttp%253A//engine.rbc.medialand.ru/reference%253Fgid%253D6%2526pid%253D1239%2526bid%253D299003%2526rid%253D834333761%2526reference%253Dhttp%25253A//ad.adriver.ru/cgi-bin/click.cgi%25253Fsid%25253D1%252526bt%25253D2%252526ad%25253D560650%252526pid%25253D2223593%252526bid%25253D4285720%252526bn%25253D4285720%252526rnd%25253D988404571&clickTAG2=http%3A//content.rbc.medialand.ru/http%253A//rbc.ru//%3Fhttp%253A//engine.rbc.medialand.ru/reference%253Fgid%25

Я, как сумел, на своём компе, чтобы повторить ситуацию, скопировал кусок адреса
http://content.rbc.medialand.ru/t17/a153650/b299002/768x600.swfgsd.html?fc=1239&r5850=5850&link1=
(Эта часть его была видна в окне с журналом web.log).
Убедился, что выдаётся пресловутое “DNS Lookup Failed”.
Пинганул
content.rbc.medialand.ru, получил 185.72.231.44.
Ради интереса ввёл его в строку броузера http://185.72.231.44 и получил в ответ:

403 Forbidden

Попробовал ввести http://medialand.ru/ - так броузер отобразил страничку. Оказалось, что этому домену соответствует другой IP-шник - 80.68.250.236.

В предыдущий раз на другом сайте, когда возникло “DNS Lookup Failed”, в строке броузера была также очень длинная команда.

Отсюда вопрос:
Нет ли ограничения на размер PUT/GET-запросов в броузере или Керио ?

HankHank
Не знаю зачем вы адресуете это мне, но раз уж так, то:

1. БрАузер

2. Не заслуживающий доверия ответ:
╚ь : content.rbc.medialand.ru
Addresses: 80.68.250.198
80.68.250.200
185.72.231.43
185.72.231.44

attaattaatta

Цитата:

1. БрАузер

Надеюсь, речь не об орфографии. Дело в том, что на компе, где возникла описанная ситуация, - Opera, у меня - FireFox.

Цитата:

2. Не заслуживающий доверия ответ:
╚ь : content.rbc.medialand.ru
Addresses: 80.68.250.198
80.68.250.200
185.72.231.43
185.72.231.44

Не понимаю, что такое "╚ь".
Повторюсь, адрес доменного имени content.rbc.medialand.ru был 185.72.231.44.
Сейчас пишу с другого компа, адрес домена content.rbc.medialand.ru - 80.68.250.200.

Не понимаю, как получается, что у домена medialand.ru адрес один, а у домена более низкого уровня с тем же корнем content.rbc.medialand.ru - IP-адрес другой.
Если это портал со сложной организацией, тогда можно предположить, что возникает какая-то путаница для KC. И он, скорее всего, не справляется.


Добавлено:
Да, возможно, проблема как-то связана с тем, что портал распределён по пулу IP.
Попробовал пингануть content.rbc.medialand.ru минут через десять, получил 185.72.231.43.

HankHank
Именно в орфографии

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

Вы банально не опознаете вывод кросс платформенной команды nslookup.

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

Касательно

Цитата:

Не понимаю, как получается, что у домена medialand.ru адрес один, а у домена более низкого уровня с тем же корнем content.rbc.medialand.ru - IP-адрес другой.
Если это портал со сложной организацией, тогда можно предположить, что возникает какая-то путаница для KC. И он, скорее всего, не справляется.  

Вы пока что немного "не в теме". Набирайтесь опыта.

народ... помогите плиз... задолбался рыть инет... есть 2 офиса(центр и область)... соединил по впн тунелю... ну ни в какую из области в центр с компов нет соединения... с сервера области прикол в том что все работает, а с клиентов нет. как будто сам сервер с керио не хочет переадресовывать в тунель для клиентов. может кто сталкивался?

covex11
разреши все между туннелями и доверенной зоной

Maza777

Цитата:

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

даже пробовал создавать правило все - все - разрешено...
мистика какая то...

прикол в том что на сервере керио в области проходят пакеты. видно что типа пускает, но ничего не работает...
PERMIT "Новое правило" packet to VPN centr, proto:ICMP, len:92, 192.168.1.23 -> 192.168.5.5, type:8 code:0


Добавлено:
может есть какая то не совместимость между версиями керио? на центре стоит 8.6.2 аплианс, а на области 7.4.2 под винду...

разобрался... вопрос исчерпан... но появилась вторая проблема:

на клиентах в области видна половина сети, вторая половина даже не пингуется! ваще в шоке... что за ерунда происходит...

attaattaatta

Цитата:

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

Всё-таки проблема существует. Плохо, что проявляется она относительно редко. И на разных интернет-ресурсах, на разных компах сети.

Напомню настройки.
DNS-сервера (основной и альтернативный) прописываются на клиентских компьютерах.
DNS-модуль KC не используется. Так настроено было всегда, начиная с 6-ой версии KWF. Сегодня уже KC 9.0.1. Описанная сммптоматика появилась в 8.6.2.

Время от времени, бесситемно (бывает, что целую неделю ситуация не возникает, а бывает, что несколько раз в отдельный день) появляется сообщение "DNS Lookup Failed". Оно не сопровождается никакими другими дополнительными записями в журналы KC. Прицельно изучением проблемы пользователи не занимаются. По прошествии некоторого времени (5-10минут) сообщение пропадает.

За последние 3-4 месяца накопилась следующая статистика:
- независимость от операционной сиcтемы, возникает на WXP и W8.1,
- независимость от брАузера )), случалось на Opera, FireFox, Crom,
- типовые приёмы чистки локальных DNS-кешей также не канают:
ipconfig /release
ipconfig /all
ipconfig /flushdns
ipconfig /renew
netsh int ip set dns
netsh winsock reset
и последующая перезагрузка.

Складывается впечатление, что это проблема KC и моей специфической сети.

Вчера с утра наблюдал ситуацию, когда пресловутое сообщение возникло при поиске в Яндексе !? ( http://kazhdysboy.ru/ne-rabotaet/yandex/obzor )
Та же самая поисковая строка сразу же в Гугле дала положительный результат.
Повторные запуски в Яндексе во вновь открытых двух вкладках не дали положительного результата, вылезало "DNS Lookup Failed". По прошествии десяти минут Яндекс заработал.

Я отфильтровал http.log по компу, на котором возник описанный сбой. Но разобраться в причине не могу.

Доброго времени суток!

Внезапно перестало работать VPN соединение по протоколу PPTP.

Схема такова: В офисе сидит народ, который ходит через керио в интернеты, всё работает всё ништяк.
Некоторые работники должны использовать впн соеденение для подключения к удалённому серверу. При попытке подключения стала возникать ошибка 806 и жалуется на GRE протокол.
Но если подключится напрямую к проводу от провайдера, соединение работает и никаких ошибок не возникает.

в логе следующая лабуда:


Код:

[16/Mar/2016 18:12:44] ALLOW "YPPTP" packet from Local Area Connection, proto:TCP, len:52, 10.10.10.55:65086 -> 212.250.220.188:1723, flags:[ SYN ], seq:434990339/4294967295 ack:0, win:8192, tcplen:0
[16/Mar/2016 18:12:44] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:60, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ SYN ], seq:2280498797/1845508457 ack:0, win:29200, tcplen:0
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet from Sharq-FTTH-Unlim, proto:TCP, len:60, 212.250.220.188:1723 -> 192.168.4.10:65086, flags:[ SYN ACK ], seq:2409489409/2409489409 ack:2280498798, win:8192, tcplen:0
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:52, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ ACK ], seq:2280498798/1845508458 ack:2409489410, win:229, tcplen:0
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:52, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ SYN ACK ], seq:2030915208/4294967295 ack:434990340, win:29200, tcplen:0
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet from Local Area Connection, proto:TCP, len:40, 10.10.10.55:65086 -> 212.250.220.188:1723, flags:[ ACK ], seq:434990340/0 ack:2030915209, win:16425, tcplen:0
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet from Local Area Connection, proto:TCP, len:196, 10.10.10.55:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:434990340/0 ack:2030915209, win:16425, tcplen:156
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:40, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ ACK ], seq:2030915209/0 ack:434990496, win:237, tcplen:0
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:208, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:2280498798/1845508458 ack:2409489410, win:229, tcplen:156
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet from Sharq-FTTH-Unlim, proto:TCP, len:208, 212.250.220.188:1723 -> 192.168.4.10:65086, flags:[ ACK PSH ], seq:2409489410/378574201 ack:2280498954, win:513, tcplen:156
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:52, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ ACK ], seq:2280498954/1845508614 ack:2409489566, win:237, tcplen:0
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:196, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ ACK PSH ], seq:2030915209/0 ack:434990496, win:237, tcplen:156
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet from Local Area Connection, proto:TCP, len:208, 10.10.10.55:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:434990496/156 ack:2030915365, win:16386, tcplen:168
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:40, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ ACK ], seq:2030915365/156 ack:434990664, win:245, tcplen:0
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:220, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:2280498954/1845508614 ack:2409489566, win:237, tcplen:168
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet from Sharq-FTTH-Unlim, proto:TCP, len:84, 212.250.220.188:1723 -> 192.168.4.10:65086, flags:[ ACK PSH ], seq:2409489566/378574357 ack:2280499122, win:512, tcplen:32
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:72, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ ACK PSH ], seq:2030915365/156 ack:434990664, win:245, tcplen:32
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet from Local Area Connection, proto:TCP, len:64, 10.10.10.55:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:434990664/324 ack:2030915397, win:16378, tcplen:24
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:40, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ ACK ], seq:2030915397/188 ack:434990688, win:245, tcplen:0
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:76, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:2280499122/1845508782 ack:2409489598, win:237, tcplen:24
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:12:45] ALLOW "YPPTP" packet from Sharq-FTTH-Unlim, proto:TCP, len:52, 212.250.220.188:1723 -> 192.168.4.10:65086, flags:[ ACK ], seq:2409489598/378574389 ack:2280499146, win:512, tcplen:0
[16/Mar/2016 18:12:47] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:12:47] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:12:50] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:12:50] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:12:54] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:12:54] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:12:58] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:12:58] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:02] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:02] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:06] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:06] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:10] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:10] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:14] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:14] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:18] ALLOW "YPPTP" packet from Local Area Connection, proto:GRE, len:57, 10.10.10.55 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:18] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:GRE, len:57, 192.168.4.10 -> 212.250.220.188, plen:29
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet from Local Area Connection, proto:TCP, len:56, 10.10.10.55:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:434990688/348 ack:2030915397, win:16378, tcplen:16
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:40, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ ACK ], seq:2030915397/188 ack:434990704, win:245, tcplen:0
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:68, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:2280499146/1845508806 ack:2409489598, win:237, tcplen:16
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet from Sharq-FTTH-Unlim, proto:TCP, len:200, 212.250.220.188:1723 -> 192.168.4.10:65086, flags:[ ACK PSH ], seq:2409489598/378574389 ack:2280499162, win:512, tcplen:148
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:188, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ ACK PSH ], seq:2030915397/188 ack:434990704, win:245, tcplen:148
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet from Local Area Connection, proto:TCP, len:56, 10.10.10.55:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:434990704/364 ack:2030915545, win:16341, tcplen:16
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:40, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ ACK ], seq:2030915545/336 ack:434990720, win:245, tcplen:0
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:68, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ ACK PSH ], seq:2280499162/1845508822 ack:2409489746, win:245, tcplen:16
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet from Sharq-FTTH-Unlim, proto:TCP, len:68, 212.250.220.188:1723 -> 192.168.4.10:65086, flags:[ ACK PSH ], seq:2409489746/378574537 ack:2280499178, win:512, tcplen:16
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:56, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ ACK PSH ], seq:2030915545/336 ack:434990720, win:245, tcplen:16
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet from Local Area Connection, proto:TCP, len:40, 10.10.10.55:65086 -> 212.250.220.188:1723, flags:[ FIN ACK ], seq:434990720/380 ack:2030915561, win:16337, tcplen:0
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet to Local Area Connection, proto:TCP, len:40, 212.250.220.188:1723 -> 10.10.10.55:65086, flags:[ FIN ACK ], seq:2030915561/352 ack:434990721, win:245, tcplen:0
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:52, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ FIN ACK ], seq:2280499178/1845508838 ack:2409489762, win:245, tcplen:0
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet from Local Area Connection, proto:TCP, len:40, 10.10.10.55:65086 -> 212.250.220.188:1723, flags:[ RST ACK ], seq:434990721/381 ack:2030915561, win:0, tcplen:0
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet from Sharq-FTTH-Unlim, proto:TCP, len:52, 212.250.220.188:1723 -> 192.168.4.10:65086, flags:[ ACK ], seq:2409489762/378574553 ack:2280499179, win:512, tcplen:0
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet from Sharq-FTTH-Unlim, proto:TCP, len:52, 212.250.220.188:1723 -> 192.168.4.10:65086, flags:[ FIN ACK ], seq:2409489762/378574553 ack:2280499179, win:512, tcplen:0
[16/Mar/2016 18:13:22] ALLOW "YPPTP" packet to Sharq-FTTH-Unlim, proto:TCP, len:52, 192.168.4.10:65086 -> 212.250.220.188:1723, flags:[ ACK ], seq:2280499179/1845508839 ack:2409489763, win:245, tcplen:0

HaveANiceDay
Начните с клонирования правила трансляции клиента в интернет, укажите службы GRE, PPTP и иже с ними и отключите для этого правила инспектор протокола в правилах трафика. Не забудьте поставить его выше дефолтного.

Помогите разобраться в таблице маршрутизации, есть несколько системный маршрутов созданных керио, для примера такого вида: сеть 11.11.11.0 маска 255.255.255.0 шлюз пусто интерфейс ethernet1 метрика 0
сеть 22.22.22.0 маска 255.255.255.0 шлюз пусто интерфейс ethernet2 метрика 0
сеть 33.33.33.0 маска 255.255.255.0 шлюз пусто интерфейс ethernet3 метрика 0
И есть еще такой маршрут:
сеть 44.44.44.13 маска 255.255.255.0 шлюз пусто интерфейс ethernet4 метрика 0, вот здесь не понимаю, провайдер выдает диапазон ip с 44.44.44.14-44.44.44.46 т.е. ip 44.44.44.13 у нас нет, тогда откуда керио взял этот ip и не должен-ли этот маршрут выглядеть, как предыдущие сеть 44.44.44.0 маска 255.255.255.0 шлюз пусто интерфейс ethernet4 метрика 0?