Openvpn ошибка 10060 - Решение и исправление самых разных ошибок на TopOshibok.ru

Kios: OpenVpn Newbie; Posts: 3; Joined: Wed Mar 13, 2019 8:33 am

read TCP_CLIENT: Unknown error (code=10060)

Hi all,

Wed Mar 13 09:29:05 2019 read TCP_CLIENT: Unknown error (code=10060)
Wed Mar 13 09:29:05 2019 Connection reset, restarting [-1]
Wed Mar 13 09:29:05 2019 SIGUSR1[soft,connection-reset] received, process restarting
Wed Mar 13 09:29:10 2019 WARNING: —ns-cert-type is DEPRECATED. Use —remote-cert-tls instead.

I’m getting this error randomly (every few minutes or something like that). It’s really bothering me a quite bit. On my old workstation everything works fine, but on the new one I’m faced with this issue. Because I’m using VMware Workstation app, it disconnects me every time, and I need to log in :S, that is really pain in the ass.

I’ve googled for ages, but didn’t find any soultions that could help me.

Any help would be appricated,
thanks.

novaflash: OpenVPN Inc.; Posts: 1073; Joined: Fri Apr 13, 2012 8:43 pm

Re: read TCP_CLIENT: Unknown error (code=10060)

Post

by novaflash » Wed Mar 13, 2019 8:43 am

Look for Windows socket error code 10060.

In short, your connection is getting disrupted, and OpenVPN then can’t do its job.

I’m still alive, just posting under the openvpn_inc alias now as part of a larger group.

Kios: OpenVpn Newbie; Posts: 3; Joined: Wed Mar 13, 2019 8:33 am

Re: read TCP_CLIENT: Unknown error (code=10060)

Post

by Kios » Wed Mar 13, 2019 1:17 pm

Thanks. To be honest I’ve googled 10060, bud didn’t find anything useful. I’ve found this https://www.youtube.com/watch?v=dknUbTRZsCY , but didn’t help.

And Sometimes I can see this message appearing when the connection is reconnected.
Edit:
Wed Mar 13 15:07:06 2019 [xxx.xxx.xxx.xxx] Inactivity timeout (—ping-restart), restarting
Wed Mar 13 15:07:06 2019 SIGUSR1[soft,ping-restart] received, process restarting
Wed Mar 13 15:07:11 2019 WARNING: —ns-cert-type is DEPRECATED. Use —remote-cert-tls instead.

Last edited by Kios on Wed Mar 13, 2019 2:10 pm, edited 1 time in total.

novaflash: OpenVPN Inc.; Posts: 1073; Joined: Fri Apr 13, 2012 8:43 pm

Re: read TCP_CLIENT: Unknown error (code=10060)

Post

by novaflash » Wed Mar 13, 2019 1:59 pm

Try literally googling for: Windows socket error code 10060. Guaranteed to have results that are relevant.

I’m still alive, just posting under the openvpn_inc alias now as part of a larger group.

Kios: OpenVpn Newbie; Posts: 3; Joined: Wed Mar 13, 2019 8:33 am

Re: read TCP_CLIENT: Unknown error (code=10060)

Post

by Kios » Thu Mar 14, 2019 7:51 am

novaflash wrote: ↑

Wed Mar 13, 2019 1:59 pm

Try literally googling for: Windows socket error code 10060. Guaranteed to have results that are relevant.

I’ve did that and only two things that I’ve found are:
https://kb.globalscape.com/Knowledgebas … 10384.aspx -> regarding the regedit entery that doesn’t exist on win10

And the second one is the internetProperties -> Lan options that is by default ok with me.

There are some recommendation regarding the firewall I’ve created inbound/outbound rules for port 1194 but didn’t helped.

I’m having feeling that I’m running in the circle whole time :S

novaflash: OpenVPN Inc.; Posts: 1073; Joined: Fri Apr 13, 2012 8:43 pm

Re: read TCP_CLIENT: Unknown error (code=10060)

Post

by novaflash » Thu Mar 14, 2019 10:36 am

Yeah. So, we can’t really help you either. This error is an error reported by the operating system’s methods of communicating with the outside world. And they’re saying that the connection was lost. This has nothing to do with an OpenVPN problem. This is a connection problem. Like a broken Internet connection or such. If it was an OpenVPN error, then we could have given you some suggestions, but this is an error coming from the OS.

I’m still alive, just posting under the openvpn_inc alias now as part of a larger group.

PegLeg: OpenVpn Newbie; Posts: 1; Joined: Thu Oct 13, 2022 10:14 am

Windows socket error code 10060 FIX

Post

by PegLeg » Thu Oct 13, 2022 10:16 am

Hi,
Midweek windows released an update to windows 10,
A security/cumulative update, I allowed windows to automatically update and install it.

The update is KB5018410

This update sends Open VNP round in circles with a “Windows socket error code 10060”

I have removed the update and now I can log back in to open VNP.

Should you be experiencing this problem.

1: open SETTINGS from the windows start key in lower left corner of desktop
2: select UPDATES & SECURITY
3: Select VIEW UPDATES in the centre of the ecreen
4: select UNINSTALL UPDATES
5: highlight update KB5018410 only
6: press UNINSTALL
7: wait for it to complete and restart the pc.

Источник

Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Вы должны войти, чтобы создавать сообщения и темы.

(так и не повторилось) OpenVPN и ошибка 10060

Вчера переехал со старого кинетика на 3.0.12.RU.10122020 / AP-Gateway(Router) / MT7621 CPU, MT7615DN 2T2R DBDC, 1000FDX. Подключение PurePPPoE, Justlan. Настольный комп по LAN гигабит. И сразу же стали происходить реконнекты клиента OpenVPN. Оговорюсь сразу, работаю через этого клиента не меньше пяти лет, сервер в моём городе, почти весь 2020 год клиент не выключался. Ни разу не видел такой причины разрыва соединения. И как только сменил роутер, началось. Через произвольные интервалы времени (иногда 10 минут, иногда 3 часа) происходит переконнект с сервером. В логе OpenVPN примерно следующее:

Thu Dec 10 18:34:56 2020 Initialization Sequence Completed
Thu Dec 10 18:56:40 2020 read TCP_CLIENT: Unknown error (code=10060)
Thu Dec 10 18:56:40 2020 Connection reset, restarting [-1]
Thu Dec 10 18:56:40 2020 SIGUSR1[soft,connection-reset] received, process restarting

Я на сервере не единственный клиент, но реконнекты там только у меня, остальные 50+ клиентов работают без сбоев.

Запускал в фоне пинги до гугла (8.8.8.8) и до собственно сервера с впн, в момент потери соединения пинги не тормозят, как были 22 мс и 1 мс соответственно, так и идут как вкопанные.

В логах роутера в эти моменты ничего нет.

Есть идеи, куда копать и что попробовать? Может какие-то расширенные логи есть? PPPoE посмотреть, например…

Опять вангу звать? Ок. Ванга грит keepalive… Больше ничего не говорит.

Что это за причина мне неведомо, но предполагаю (и ванга согласна) что за 7600с ни одного пакета по соединению не прошло и оно было вынесено из контрака как мёртврое (что верно ибо нафиг память на него тратить ещё). Что бы этого не происходило есть механизи keepalive в т.ч. в openvpn.

Не уточнил сразу: на компе работал mstsc-клиент, внутри которого по rdp я воочию наблюдаю последствия таких реконнектов в виде фриза на минуту. То есть по туннелю трафик был, была активная работа. Да и ping 10 был в конфиге ovpn

Ни я не ванга ничего не можем сказать на эту тему. Все предположеия которые можно сделать из данных в репорте даны выше. Увы, я не автор openvpn и даже не автор винды что бы по какому-то адовому error code (всяко винда возвращает) понять что ж там по факту случилось.

Роутер ничего не знает о вашем openvpn для него все соединения это udp или tcp, ну если нет под них конкретного ALG. Под openvpn ессно его нет и быть не может.

Как стандарт openvpn ISO то же не принимался. Т.е. RFC нет. Все остальные TCP прикладухи работают нормально? Ну значит и дебажить нужно начинать со стороны самого openvpn чего ему не нравиться. А к нам приходить уже с конкретикой.

Так что ой. Ничего кроме вышесказанного мне сказать не чего.

P.S. 2 раза намекнул уже что данных мало и даже базовые вещи указанные в теме рядом на тему того какие данные по минимуму нужно предоставлять не выполнены. Хотя они врятли помогут пока не будет понятно что там openvpn думает и что это за ошибка такая и чего значит. Вы думаете я зря к Ванге обращаюсь. =)))

Ванга тут ещё подсказывает, грит может NAT Offload вырубить. Ибо всякую нестандартщину таки временами при работающем оффлоаде может подплющивать. Хотя куда стандартнее TCP… =)

В общем не в курсе. Может вы там в netdiag в произвольное время clear cache тыкаете. Или провайдер решил пошалить (рядом есть темы где «началось» со сменой роутера, а оказалось совпало с работами на стороне провайдера. По описанию формата «началось», к сожалени даже лучшие европейские медиумы ничего сказать не в силах. Особенно в полночь.

P.S. Пинги в фоне не прерываются значит в логах PPPOE смотерть нечего т.е. сессия не теряется. Запсутите параллельно mtr и помониторьте потери. Запросто может оказаться что где-то на промежуточном хопе в моменты отвалов лавинообразно возникают потери. Чудес не бывает. Но что бы я мог помочь, мне нужны данные, особенно когда речь идёт о сервисах которые я лично не юзаю и о них мне ничего неизвестно. Тогда нужны данные начиная с версии сервера на обратном конце, всех настроек и сервера и клиента и т.д. и т.п. Правда это в любом случае вопросы то наверное уже мимо, и роутер тут очень сильно сбоку… Но mtr в отличии от пинга (интервал только поменьше поставьте) возможно подскажет в чём беда и где.

Да я понимаю, что это рвётся в первую очередь соединение операционки. И OpenVPN после этого ничего поделать уже не может.

У меня была надежда, что можно какие-нибудь детальные логи включить посмотреть, может это у провайдера что-то не честно. Кстати, можете себе плашку Квант-Телекома (Джастлан их бренд) повесить на страницу операторов интернета в ЦФО

Ой эти все плашки. =))) Лучше бы они в тест бы железки бы запросили, глядишь какие-нить нюансы бы выяснились.

P.S. см о mtr выше, вот он может попутно что-то подсказать. Роутер чего, он занатил и выплюнул пакет (ну грубо говоря), если tcp и не получил ack плюнул ещё несколько раз и забил. Он транзитный узел. Хоть циска будь хоть кто угодно. Диагностировать на его уровне особенно нечего как минимум до понимания чего не нравиться клиенту или серверу. Даже Шерлоку нужно понимать от чего отталкиваться. А тут как в том мультике «-Ничего не понимаю… —Аналогично!» =)))

Да забыл. Размер пакета тоже и пингу и mtr поставить ну пусть 1400, на мелких пакетах потери можно и не заметить.

Вчера погонял mtr на штатных настройках. В момент обрыва соединения каких-то отклонений в динамике показателей не заметил. Сегодня увеличил размер с 64 до 1400, качественно ничего не изменилось. Картинка за вчера

Вечером слушал онлайн-радио (не из-под VPN), один раз оно тоже прервалось одновременно с обрывом соединения OpenVPN, хотя были и такие реконнекты, когда радио не затыкалось.

Сегодня выключил NAT offload и теперь жду. Пока мало времени прошло

Спрашивал у товарища сегодня не видит ли он у себя чего подобного. Грит нет и порекомендовал стартовать openvpn с ключиками -remote peer и –ping 5 если ходит поверх другого туннеля с NAT (pppoe тоже подпадает под это).

-remote peer и –ping 5

Эти ключики есть в конфиге.

С выключенным NAT offload вот уже 9 часов нет ни одного реконнекта.

А вот зацепка: я попробовал задействовать файрвол на роутере. Просто переключил в Enable пункт MAC/IP/Port Filtering и нажал Apply, даже не вводя никакие правила. И тут же знакомая ошибка 10060 и реконнект. Делаю Disable и Apply — опять реконнект

Цитата: Lexus от 11/12/2020, 23:20

-remote peer и –ping 5

Эти ключики есть в конфиге.

С выключенным NAT offload вот уже 9 часов нет ни одного реконнекта.

Плохо. Пробуйте отключать оффлоады не полностью а перейти только в софтварный и только в хардварный. Выяснить нужно какой оффлоад приводит к тому что openvpn подплющивает.

Скорее всего это будет хардварный. Который увы из себя представляет чёрный ящик и максимум что от текущего состояния с ним можно сделать это исключать выборочно трафик из него. Т.к. openvpn может работать по любому порту и использовать как tcp так и udp то придётся видимо делать крутилку индивидуально.

А вот зацепка: я попробовал задействовать файрвол на роутере. Просто переключил в Enable пункт MAC/IP/Port Filtering и нажал Apply, даже не вводя никакие правила. И тут же знакомая ошибка 10060 и реконнект. Делаю Disable и Apply — опять реконнект

Это не зацепка, а штатное поведение. Что бы правила применялись не когда-нить потом а сразу, при любых манипуляциях на странице фаервола после нажатия применить сбрасываются все стэйты контрака и текущие соединения порвуться.

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

Цитата: sfstudio от 12/12/2020, 08:13

Плохо. Пробуйте отключать оффлоады не полностью а перейти только в софтварный и только в хардварный. Выяснить нужно какой оффлоад приводит к тому что openvpn подплющивает.

По умолчанию был включен Complex. Когда я стал отключать оффлоад, то попробовал сначала перейти на рекомендуемый для PPPoE режим Hardware. В течение часа в нём тоже произошел реконнект и я просто поставил Disable. Software вчера не пробовал, запущу сегодня. Отпишу тогда

Upd: 7 часов, полёт стабильный

В общем, на софтовом оффлоаде проблем нет, как и на выключенном

Ок. Сейчас соберётся 3.0.14 проверим на ней. Если будет повторяться скажу что ещё нужно будет проверить и сделаем тады крутилку что бы можно было по портам выкусывать трафик из PPE т.к. порт зарание неизвестен увы.

ООочень всё это всё же странно, есть догадка почему такое может быть, но скорее из области фантастики т.к. приводило бы к проблемам не только с openvpn а вообще с любыми TCP. Скорее всё же что-то там такое openvpn пытается такое в заголовках tcp чудить что блок PPE аппаратно переварить не в силах. А значит только выкусывать.

Попробую у себя развернуть повторить на всякий. Но не факт что повториться.

Цитата: sfstudio от 14/12/2020, 08:44

Ок. Сейчас соберётся 3.0.14 проверим на ней. Если будет повторяться скажу что ещё нужно будет проверить и сделаем тады крутилку что бы можно было по портам выкусывать трафик из PPE т.к. порт зарание неизвестен увы.

Накатил 3.0.14, сделал сброс и минимальные настройки: OpenVPN разорвался через полтора часа.

приводило бы к проблемам не только с openvpn а вообще с любыми TC

Когда я онлайн-радио слушал, воспроизведение пропадало одновременно с некоторыми разрывами OpenVPN. Причем без обновления страницы радио воспроизведение само не восстанавливалось.

Что за радио? Openvpn у меня вот прямо сейчас работает и ни единого разрыва.

Жду когда порвется.

Может хоть на радио повторю…

Цитата: sfstudio от 14/12/2020, 14:24

Что за радио? Openvpn у меня вот прямо сейчас работает и ни единого разрыва.

101.ru

Сейчас одновременно с RDP по OpenVPN, запущенному на компьютере с LAN, я полтора часа проводил видеоконференцию с помощью Jitsi meet с андроид-телефона по Wi-Fi. Не интересовался, что там за протокол, но соединение Jitsi не рвалось, а OpenVPN за это время раза 4 реконнектился. Сервер в обоих случаях один и тот же. Либо протокол более устойчив к обрывам сессии, либо дело в том, что Jitsi работал поверх WLAN (и напрямую без VPN, сам по себе), а OpenVPN поднят на LAN-интерфейсе

Или еще 100500 причин. Хоть загадайся пока у меня повторяемости нет.

Как и за 10ток лет не было массовых жалоб.

Это веяния каких-то изменений либо на стороне приложений либо на стороне ос которые видимо и приводят к какому-то хитрому поведению ppe.

Вот это в разы вероятнее.

Бум пробовать разобраться.

Ок с радио проверю.

Радио играет уже более 12 часов через OpenVPN работающий через 2шт DUO-G каскадом по LAN. Проблемы ни первой ни второй не вижу ;(

Ось какая на клиентах?

Единственная догадка которая приходит в голову это то что таки регулярно есть потери где-то по пути. В случае с PPE отсутствует практически буферизация т.е. нет шансов что передатчик задетектит потери и перепошлёт пакет и обработка таких ситуаций ложиться на клиентскую ось. В софт режиме из-за избыточной буферизации проблему может быть просто не видно или она ооочень сильно отодвигается во времени.

Косвенно об этом может говорить отсутсвие проблемы через wifi т.к. там сам драйвер тасует пакеты, занимается агрегацией и т.д. т.е. имеет очень жирный буфер (иначе скорость по радио была бы мягко сказать), в то время как по LAN для сессий обслуживаемых PPE выплёвывается буквально сразу из него напрямую в железо минуя всю программную обработку включая буферизацию.

Но это всё же только догадка.

Попробуем локализовать траблу и придумать что-то.

Для этого нужно для начала выяснить.

В обоих ли направлениях оффлоад приводит к такому поведению. Для этого используем тулзу hw_nat

Only Speed UP (0=Upstream, 1=Downstream, 2=Bi-Direction) flow 
Ex: hw_nat -Z 1

После полной загрузки командуем hw_nat -Z 1 т.е. переключаем в режим оффлоада только в download path. Проверяем. Затем так же только с hw_nat -Z 0.

Эти настройки не сохраняются т.е. работают до релоада драйвера PPE.

Радио играет уже более 12 часов через OpenVPN

У меня стрим радио был запущен параллельно туннелю, но не в нём. И иногда прерывались оба соединения, а иногда только впн.

Ось какая на клиентах?

Домашние компьютеры на вин10 2004. Сегодня полдня работал с другого домашнего компа (воткнут в соседний порт LAN) — те же проблемы.

Для этого нужно для начала выяснить. В обоих ли направлениях оффлоад приводит к такому поведению

Да, в обоих. И после hw_nat -Z 1, и после hw_nat -Z 0 наблюдаются реконнекты

Ок буду искать винду. Не могу на рабочем ПК выделить ей столько рабочего времени на повторение. Под *nix (разных) не повторяется ни в туннеле ни сбоку.

Запустил OpenVPN до того же сервера под Ubuntu 20.04 (внутри WSL2 виндов, хост — всё та же win10), которая выходит в свет через VirtualBox-сетевой адаптер в режиме NAT. За 8 часов ни одного реконнекта

Вывод? Tcp стэк винды чудит или возможно какой-нить встроенный в антивирус фаер плющит что и приводит к чудесам на стороне ppe.

Wsl2 нынче тупо виртуалка

В общем на чистой 10тке (специально водрузил на старый ноут свежую систему) так же не увидел проблемы.

Что стоит из антивирусов и т.п. в системе? Вот почти уверен где-то там собака зарыта. Надо добиться повторяемости у меня что бы придумать как обойти безболезненно. Ну или хотя бы понять кому репортить.

Что стоит из антивирусов и т.п. в системе?

Kaspersky Anti-Virus 21.2. Встроенный в вин10 дефендер отключен настолько, насколько это возможно. Ну офис, браузеры и игры тут вроде влиять не должны, а больше и нет ничего особенного.

Вот момент обрыва соединения: пакет 13628

С касперским были траблы в RTNL из-за чего с goahead спозли на nginx. Он время от времени решал дропать часть ACK при этом UI роутера начинал страшно тормозить, ибо goahead не посылал следующую порцию данных.

Решением было добавление в исключения адреса роутера у касперского. Отключение его не помогало никак. Либо адрес в исключения либо полное удаление.

Дампы трафика тут ни чем не помогут (особенно в виде скринов). Мне нужна повторяемость. Буду пробовать с касперским чего делать. Надеюсь у них есть бесплатная версия. Ибо тырить софт не приучен.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

I am seeing a few users intermittently disconnect with this error.
They can connect for several hours at times. It reconnects or check auth in the background every hour with no input needed. It had been doing this on this connection every hour for 8 hours.

I see auth errors in server log but that is after the inital client error, which does not appear anywhere else in the client logs for that day.
Any help would be appreciated.

Windows 10

Client:
Tue Sep 08 22:09:12 2020 read TCP_CLIENT: Unknown error (code=10060)

Tue Sep 08 22:09:12 2020 Connection reset, restarting [-1]

Tue Sep 08 22:09:12 2020 SIGUSR1[soft,connection-reset] received, process restarting

Tue Sep 08 22:09:12 2020 MANAGEMENT: >STATE:1599617352,RECONNECTING,connection-reset,,,,,

Tue Sep 08 22:09:12 2020 Restart pause, 5 second(s)

Server:
Tue Sep 8 22:09:17 2020 us=810157 MULTI: multi_create_instance called

Tue Sep 8 22:09:17 2020 us=813514 Re-using SSL/TLS context

Tue Sep 8 22:09:17 2020 us=814147 Control Channel MTU parms [ L:1623 D:1210 EF:40 EB:0 ET:0 EL:3 ]

Tue Sep 8 22:09:17 2020 us=814258 Data Channel MTU parms [ L:1623 D:1500 EF:123 EB:406 ET:0 EL:3 ]

Tue Sep 8 22:09:17 2020 us=814428 Local Options String (VER=V4): ‘V4,dev-type tun,link-mtu 1559,tun-mtu 1500,proto TCPv4_SERVER,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server’

Tue Sep 8 22:09:17 2020 us=814503 Expected Remote Options String (VER=V4): ‘V4,dev-type tun,link-mtu 1559,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client’

Tue Sep 8 22:09:17 2020 us=814673 TCP connection established with [AF_INET]x.x.x.x:59161

Tue Sep 8 22:09:17 2020 us=814715 TCPv4_SERVER link local: (not bound)

Tue Sep 8 22:09:17 2020 us=814747 TCPv4_SERVER link remote: [AF_INET]x.x.x.x:59161

Tue Sep 8 22:09:28 2020 us=280416 x.x.x.x:59161 TLS: Initial packet from [AF_INET]x.x.x.x:59161, sid=eb55346d 8eb04e34

Tue Sep 8 22:09:28 2020 us=370859 x.x.x.x:59161 VERIFY OK: depth=1, CN=H226693

Tue Sep 8 22:09:28 2020 us=371239 x.x.x.x:59161 VERIFY OK: depth=0, CN=client

Tue Sep 8 22:09:28 2020 us=430178 x.x.x.x:59161 peer info: IV_VER=2.4.6

Tue Sep 8 22:09:28 2020 us=430260 x.x.x.x:59161 peer info: IV_PLAT=win

Tue Sep 8 22:09:28 2020 us=430295 x.x.x.x:59161 peer info: IV_PROTO=2

Tue Sep 8 22:09:28 2020 us=430326 x.x.x.x:59161 peer info: IV_NCP=2

Tue Sep 8 22:09:28 2020 us=430355 x.x.x.x:59161 peer info: IV_LZ4=1

Tue Sep 8 22:09:28 2020 us=430385 x.x.x.x:59161 peer info: IV_LZ4v2=1

Tue Sep 8 22:09:28 2020 us=430414 x.x.x.x:59161 peer info: IV_LZO=1

Tue Sep 8 22:09:28 2020 us=430443 x.x.x.x:59161 peer info: IV_COMP_STUB=1

Tue Sep 8 22:09:28 2020 us=430506 x.x.x.x:59161 peer info: IV_COMP_STUBv2=1

Tue Sep 8 22:09:28 2020 us=430537 x.x.x.x:59161 peer info: IV_TCPNL=1

Tue Sep 8 22:09:28 2020 us=430568 x.x.x.x:59161 peer info: IV_GUI_VER=OpenVPN_GUI_11

AUTH-PAM: BACKGROUND: received command code: 0

AUTH-PAM: BACKGROUND: USER: jsmith

AUTH-PAM: BACKGROUND: my_conv[0] query=’Password: ‘ style=1

AUTH-PAM: BACKGROUND: user ‘jsmith’ failed to authenticate: Authentication failure

Tue Sep 8 22:09:29 2020 us=457900 x.x.x.x:59161 PLUGIN_CALL: POST /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1

Tue Sep 8 22:09:29 2020 us=457959 x.x.x.x:59161 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so

Tue Sep 8 22:09:29 2020 us=458081 x.x.x.x:59161 TLS Auth Error: Auth Username/Password verification failed for peer

Tue Sep 8 22:09:29 2020 us=474240 x.x.x.x:59161 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Tue Sep 8 22:09:29 2020 us=474319 x.x.x.x:59161 [client] Peer Connection Initiated with [AF_INET]x.x.x.x:59161

Tue Sep 8 22:09:30 2020 us=714174 x.x.x.x:59161 PUSH: Received control message: ‘PUSH_REQUEST’

Tue Sep 8 22:09:30 2020 us=714295 x.x.x.x:59161 Delayed exit in 5 seconds

Tue Sep 8 22:09:30 2020 us=714344 x.x.x.x:59161 SENT CONTROL [client]: ‘AUTH_FAILED’ (status=1)

Tue Sep 8 22:09:30 2020 us=785965 x.x.x.x:59161 Connection reset, restarting [0]

Tue Sep 8 22:09:30 2020 us=786036 x.x.x.x:59161 SIGUSR1[soft,connection-reset] received, client-instance restarting

Tue Sep 8 22:09:30 2020 us=786311 TCP/UDP: Closing socket

Источник

I’ve been using your script a lot last 5 months maybe, and even made a fork without encryption and compression to fully utilize the potential speed. The problem is that possibly after a corporate firewall update about a week ago I could not connect as usual using my fork, as it turns out even the latest version of your script is not able to connect. Both UDP and TCP do not connect properly. I know that some people have already come across similar stuff, but maybe you could suggest a solution for me. Could it possibly be a certificate issue? Thank you

UDP:

Sun Jun 10 11:57:11 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Sun Jun 10 11:57:11 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Sun Jun 10 11:57:11 2018 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10
Sun Jun 10 11:57:11 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun Jun 10 11:57:11 2018 Need hold release from management interface, waiting…
Sun Jun 10 11:57:11 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘state on’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘log all on’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘echo all on’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘bytecount 5’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘hold off’
Sun Jun 10 11:57:11 2018 MANAGEMENT: CMD ‘hold release’
Sun Jun 10 11:57:11 2018 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Sun Jun 10 11:57:11 2018 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Sun Jun 10 11:57:11 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:57:11 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 11:57:11 2018 UDP link local: (not bound)
Sun Jun 10 11:57:11 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:57:11 2018 MANAGEMENT: >STATE:1528610231,WAIT,,,,,,
Sun Jun 10 11:58:11 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 11:58:11 2018 TLS Error: TLS handshake failed
Sun Jun 10 11:58:11 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 11:58:11 2018 MANAGEMENT: >STATE:1528610291,RECONNECTING,tls-error,,,,,
Sun Jun 10 11:58:11 2018 Restart pause, 5 second(s)
Sun Jun 10 11:58:16 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:58:16 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 11:58:16 2018 UDP link local: (not bound)
Sun Jun 10 11:58:16 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:58:16 2018 MANAGEMENT: >STATE:1528610296,WAIT,,,,,,
Sun Jun 10 11:59:16 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 11:59:16 2018 TLS Error: TLS handshake failed
Sun Jun 10 11:59:16 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 11:59:16 2018 MANAGEMENT: >STATE:1528610356,RECONNECTING,tls-error,,,,,
Sun Jun 10 11:59:16 2018 Restart pause, 5 second(s)
Sun Jun 10 11:59:21 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:59:21 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 11:59:21 2018 UDP link local: (not bound)
Sun Jun 10 11:59:21 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 11:59:21 2018 MANAGEMENT: >STATE:1528610361,WAIT,,,,,,
Sun Jun 10 12:00:21 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:00:21 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:00:21 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:00:21 2018 MANAGEMENT: >STATE:1528610421,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:00:21 2018 Restart pause, 5 second(s)
Sun Jun 10 12:00:26 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:00:26 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:00:26 2018 UDP link local: (not bound)
Sun Jun 10 12:00:26 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:00:26 2018 MANAGEMENT: >STATE:1528610426,WAIT,,,,,,
Sun Jun 10 12:01:26 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:01:26 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:01:26 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:01:26 2018 MANAGEMENT: >STATE:1528610486,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:01:26 2018 Restart pause, 5 second(s)
Sun Jun 10 12:01:31 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:01:31 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:01:31 2018 UDP link local: (not bound)
Sun Jun 10 12:01:31 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:01:31 2018 MANAGEMENT: >STATE:1528610491,WAIT,,,,,,
Sun Jun 10 12:02:32 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:02:32 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:02:32 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:02:32 2018 MANAGEMENT: >STATE:1528610552,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:02:32 2018 Restart pause, 10 second(s)
Sun Jun 10 12:02:42 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:02:42 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:02:42 2018 UDP link local: (not bound)
Sun Jun 10 12:02:42 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:02:42 2018 MANAGEMENT: >STATE:1528610562,WAIT,,,,,,
Sun Jun 10 12:03:42 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:03:42 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:03:42 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:03:42 2018 MANAGEMENT: >STATE:1528610622,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:03:42 2018 Restart pause, 20 second(s)
Sun Jun 10 12:04:02 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:04:02 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:04:02 2018 UDP link local: (not bound)
Sun Jun 10 12:04:02 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:04:02 2018 MANAGEMENT: >STATE:1528610642,WAIT,,,,,,
Sun Jun 10 12:05:02 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:05:02 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:05:02 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:05:02 2018 MANAGEMENT: >STATE:1528610702,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:05:02 2018 Restart pause, 40 second(s)
Sun Jun 10 12:05:42 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:05:42 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 12:05:42 2018 UDP link local: (not bound)
Sun Jun 10 12:05:42 2018 UDP link remote: [AF_INET]165.227.143.71:1194
Sun Jun 10 12:05:42 2018 MANAGEMENT: >STATE:1528610742,WAIT,,,,,,
Sun Jun 10 12:06:42 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sun Jun 10 12:06:42 2018 TLS Error: TLS handshake failed
Sun Jun 10 12:06:42 2018 SIGUSR1[soft,tls-error] received, process restarting
Sun Jun 10 12:06:42 2018 MANAGEMENT: >STATE:1528610802,RECONNECTING,tls-error,,,,,
Sun Jun 10 12:06:42 2018 Restart pause, 80 second(s)

UDP config:

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote 165.227.143.71 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
comp-lzo
setenv opt block-outside-dns
key-direction 1
verb 3

TCP:

Sun Jun 10 23:16:47 2018 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Sun Jun 10 23:16:47 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Sun Jun 10 23:16:47 2018 library versions: OpenSSL 1.1.0h 27 Mar 2018, LZO 2.10
Sun Jun 10 23:16:47 2018 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Sun Jun 10 23:16:47 2018 Need hold release from management interface, waiting…
Sun Jun 10 23:16:48 2018 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘state on’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘log all on’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘echo all on’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘bytecount 5’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘hold off’
Sun Jun 10 23:16:48 2018 MANAGEMENT: CMD ‘hold release’
Sun Jun 10 23:16:48 2018 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Sun Jun 10 23:16:48 2018 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
Sun Jun 10 23:16:48 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:16:48 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:16:48 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:16:48 2018 MANAGEMENT: >STATE:1528651008,TCP_CONNECT,,,,,,
Sun Jun 10 23:16:49 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:16:49 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:16:49 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:16:49 2018 MANAGEMENT: >STATE:1528651009,WAIT,,,,,,
Sun Jun 10 23:17:13 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:17:13 2018 Connection reset, restarting [-1]
Sun Jun 10 23:17:13 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:17:13 2018 MANAGEMENT: >STATE:1528651033,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:17:13 2018 Restart pause, 5 second(s)
Sun Jun 10 23:17:18 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:18 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:17:18 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:17:18 2018 MANAGEMENT: >STATE:1528651038,TCP_CONNECT,,,,,,
Sun Jun 10 23:17:19 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:19 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:17:19 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:19 2018 MANAGEMENT: >STATE:1528651039,WAIT,,,,,,
Sun Jun 10 23:17:41 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:17:41 2018 Connection reset, restarting [-1]
Sun Jun 10 23:17:41 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:17:41 2018 MANAGEMENT: >STATE:1528651061,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:17:41 2018 Restart pause, 5 second(s)
Sun Jun 10 23:17:46 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:46 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:17:46 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:17:46 2018 MANAGEMENT: >STATE:1528651066,TCP_CONNECT,,,,,,
Sun Jun 10 23:17:47 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:47 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:17:47 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:17:47 2018 MANAGEMENT: >STATE:1528651067,WAIT,,,,,,
Sun Jun 10 23:18:08 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:18:08 2018 Connection reset, restarting [-1]
Sun Jun 10 23:18:08 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:18:08 2018 MANAGEMENT: >STATE:1528651088,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:18:08 2018 Restart pause, 5 second(s)
Sun Jun 10 23:18:13 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:13 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:18:13 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:18:13 2018 MANAGEMENT: >STATE:1528651093,TCP_CONNECT,,,,,,
Sun Jun 10 23:18:14 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:14 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:18:14 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:14 2018 MANAGEMENT: >STATE:1528651094,WAIT,,,,,,
Sun Jun 10 23:18:35 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:18:35 2018 Connection reset, restarting [-1]
Sun Jun 10 23:18:35 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:18:35 2018 MANAGEMENT: >STATE:1528651115,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:18:35 2018 Restart pause, 5 second(s)
Sun Jun 10 23:18:40 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:40 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:18:40 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:18:40 2018 MANAGEMENT: >STATE:1528651120,TCP_CONNECT,,,,,,
Sun Jun 10 23:18:41 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:41 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:18:41 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:18:41 2018 MANAGEMENT: >STATE:1528651121,WAIT,,,,,,
Sun Jun 10 23:19:02 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:19:02 2018 Connection reset, restarting [-1]
Sun Jun 10 23:19:02 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:19:02 2018 MANAGEMENT: >STATE:1528651142,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:19:02 2018 Restart pause, 10 second(s)
Sun Jun 10 23:19:12 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:12 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:19:12 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:19:12 2018 MANAGEMENT: >STATE:1528651152,TCP_CONNECT,,,,,,
Sun Jun 10 23:19:13 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:13 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:19:13 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:13 2018 MANAGEMENT: >STATE:1528651153,WAIT,,,,,,
Sun Jun 10 23:19:35 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:19:35 2018 Connection reset, restarting [-1]
Sun Jun 10 23:19:35 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:19:35 2018 MANAGEMENT: >STATE:1528651175,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:19:35 2018 Restart pause, 20 second(s)
Sun Jun 10 23:19:55 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:55 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:19:55 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:19:55 2018 MANAGEMENT: >STATE:1528651195,TCP_CONNECT,,,,,,
Sun Jun 10 23:19:56 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:56 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:19:56 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:19:56 2018 MANAGEMENT: >STATE:1528651196,WAIT,,,,,,
Sun Jun 10 23:20:17 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:20:17 2018 Connection reset, restarting [-1]
Sun Jun 10 23:20:17 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:20:17 2018 MANAGEMENT: >STATE:1528651217,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:20:17 2018 Restart pause, 40 second(s)
Sun Jun 10 23:20:57 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:20:57 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:20:57 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:20:57 2018 MANAGEMENT: >STATE:1528651257,TCP_CONNECT,,,,,,
Sun Jun 10 23:20:58 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:20:58 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:20:58 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:20:58 2018 MANAGEMENT: >STATE:1528651258,WAIT,,,,,,
Sun Jun 10 23:21:20 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:21:20 2018 Connection reset, restarting [-1]
Sun Jun 10 23:21:20 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:21:20 2018 MANAGEMENT: >STATE:1528651280,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:21:20 2018 Restart pause, 80 second(s)
Sun Jun 10 23:22:40 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]46.101.235.206:443
Sun Jun 10 23:22:40 2018 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sun Jun 10 23:22:40 2018 Attempting to establish TCP connection with [AF_INET]46.101.235.206:443 [nonblock]
Sun Jun 10 23:22:40 2018 MANAGEMENT: >STATE:1528651360,TCP_CONNECT,,,,,,
Sun Jun 10 23:22:41 2018 TCP connection established with [AF_INET]46.101.235.206:443
Sun Jun 10 23:22:41 2018 TCP_CLIENT link local: (not bound)
Sun Jun 10 23:22:41 2018 TCP_CLIENT link remote: [AF_INET]46.101.235.206:443
Sun Jun 10 23:22:41 2018 MANAGEMENT: >STATE:1528651361,WAIT,,,,,,
Sun Jun 10 23:23:03 2018 read TCP_CLIENT: Unknown error (code=10060)
Sun Jun 10 23:23:03 2018 Connection reset, restarting [-1]
Sun Jun 10 23:23:03 2018 SIGUSR1[soft,connection-reset] received, process restarting
Sun Jun 10 23:23:03 2018 MANAGEMENT: >STATE:1528651383,RECONNECTING,connection-reset,,,,,
Sun Jun 10 23:23:03 2018 Restart pause, 160 second(s)

TCP config:

client
dev tun
proto tcp
sndbuf 0
rcvbuf 0
remote 46.101.235.206 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
comp-lzo
setenv opt block-outside-dns
key-direction 1
verb 3

Источник

Posted by robert k wild 2022-05-24T15:42:11Z

hi all,

getting this error on openvpn client connecting to an openvpn server

the funny thing is the client can open up a telnet session to the server, so they can hit the tcp port, the openvpn server is using tcp not udp

the client is in cairo so they block vpn especially openvpn, even using a different port doesnt help

can i put a new line in the client config or the server config?

anyone else have suggestions

thanks,

rob

5 Replies

Using a reverse proxy maybe on port 443? It’d be an interesting try since port 443 will be harder to detect that it’s openvpn traffic. I found this blog that might help you out.

https://blog.jarrousse.org/getting-openvpn-and-nginx-to-share-port-443/ Opens a new window

Was this post helpful?
thumb_up
thumb_down
Will I be a able to sshin via SSH tunnel if the openvpn server is on a sophos xgs firewall

Was this post helpful?
thumb_up
thumb_down
Can the users create an ssh tunnel to the Fw and then run up openvpn client

Was this post helpful?
thumb_up
thumb_down
What is your end goal? I think if they’re able to ssh into the firewall they wouldn’t need a VPN too? Maybe the approach could be a different style of VPN like ipsec with L2TP or something like that? Some more details of what you are trying to do will help.

Was this post helpful?
thumb_up
thumb_down
My end goal is for Cairo staff to VPN in on the sophos xgs Fw as ATM they cant as Egypt block openvpn or any VPN come to think of it

Was this post helpful?
thumb_up
thumb_down

Read these next…

Exchange falling apart.

Collaboration

it has been a week that my exchange server does not work well anymore.it seems to stop delivering email and quarantined mailboxes, I thought the issue was space since I was under 10% storage so I went ahead and enabled circular logging. The server ran fin…
Windows search bar completely unreliable

Windows

So this is annoying. Boss couldn’t find his VPN this morning (OpenVPN Client) and was freaking out. Can anyone help me out with a link to explain why Windows search is so unreliable? I mean, I know it is. But looking for something to direct boss to, o…
Snap! — Reusable Spacecraft, Robot CEO, 5,000 Free Audiobooks, Extinct RNA

Spiceworks Originals

Your daily dose of tech news, in brief.

Welcome to the Snap!

Flashback: September 20, 1983: RSA Algorithm Patent Is Awarded (Read more HERE.)

Bonus Flashback: September 20, 1970: Luna 16 lands on the moon (Read more HERE.)

You need to …
firewall for home lab

Security

I’d like to add a firewall in my home lab servers to create an ipsec tunnel to my office lab servers. It’s been a while since I’ve looked at small firewalls and thought getting a rec from the community would save me some research time. I don’t need anythi…
Anyone know what connector I need for this?

Hardware

Its an old hp Prodesk 600 g1 DM. I’m trying to fit a sata ssd in there and the circled port is what i need to power the sata drive apparently?