Openvpn tls error reading acknowledgement record from packet

---

---

---

---

---

---

---

OpenVPN Support Forum

Community Support Forum

TLS Error: reading acknowledgement record from packet

TLS Error: reading acknowledgement record from packet

Post by DM » Fri Mar 15, 2019 10:42 pm

I’ve been using OpenVPN Access Server (with license) in my organization, for a while. It’s been working great for about a year, but recently, I upgraded it to version 2.6.1 (from 2.5.x?), and both RADIUS and LDAP authentication no longer work.

Things were previously working well with RADIUS, which has since broken, and I currently have it configured for LDAP, which is slightly less-broken. With RADIUS active, I can no longer use domain credentials to log into the web console or the VPN service. With LDAP active, I can log into the web console with domain credentials, but the VPN client says «Authentication Failed» when I try to connect. Notably, it does so AFTER asking if I want to allow connections to this VPN, in the future, whereas if I just enter a wrong password, it never gets that far. All users in my organization who have tried to connect to the server have experienced the same symptoms.

On the server, there are a bunch of these in /var/log/openvpnas.log (with IP address redacted):

Since the client app was downloaded from the server, which generated it, I would expect the client/server configurations to be compatible. but I could be wrong.

I’ve been working on this for a couple days, now, and I’m completely at a loss as to what the problem might be. Do any of you kind folks have an idea?

Re: TLS Error: reading acknowledgement record from packet

Post by novaflash » Sat Mar 16, 2019 11:19 pm

Sorry, this error doesn’t ring a bell here. Is this a connection over a public network or can you test in a private network to compare?

Also, you should probably contact our support ticket system with these kinds of issues.

Источник

OpenVPN Support Forum

Community Support Forum

TLS Error: reading acknowledgement record from packet

TLS Error: reading acknowledgement record from packet

Post by xarlamp » Tue May 15, 2018 3:21 pm

Hello, i’m trying to setup server on DigitalOcean VPN.
But somewher taked wrong turn.
Now all i got is error: TLS Error: reading acknowledgement record from packet

i have server.conf:

client
dev tun
proto tcp
remote 139.59.183.118 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
cipher AES-128-CBC
auth SHA256
key-direction 1
comp-lzo
verb 3

——BEGIN CERTIFICATE——
*certificate info*
——END CERTIFICATE——

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=RU, ST=MO, L=Moscow, O=Fort-Funston, OU= YOU RKN, CN=Fort-Funston CA/name=server/emailAddress=kkuderko@yandex.ru
Validity
Not Before: May 15 14:02:32 2018 GMT
Not After : May 12 14:02:32 2028 GMT
Subject: C=RU, ST=MO, L=Moscow, O=Fort-Funston, OU= YOU RKN, CN=xarlamp/name=server/emailAddress=kkuderko@yandex.ru
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
*certificate info*
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
Easy-RSA Generated Certificate
X509v3 Subject Key Identifier:
A4:E1:F3:B2:6B:3D:81:46:E8:5C:53:B3:60:45:E9:E2:AB:01:D8:E0
X509v3 Authority Key Identifier:
keyid:1F:85:BF:EE:61:4A:08:DD:54:66:92:2D:37:CC:5E:A6:27:5D:D8:56
DirName:/C=RU/ST=MO/L=Moscow/O=Fort-Funston/OU= YOU RKN/CN=Fort-Funston CA/name=server/emailAddress=kkuderko@yandex.ru
serial:FF:2A:58:E9:06:34:7C:70

X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature
X509v3 Subject Alternative Name:
DNS:xarlamp
Signature Algorithm: sha256WithRSAEncryption
*certificate info*
——BEGIN CERTIFICATE——
*certificate info*
——END CERTIFICATE——

——BEGIN PRIVATE KEY——
*certificate info*
——END PRIVATE KEY——

——BEGIN OpenVPN Static key V1——
*certificate info*
——END OpenVPN Static key V1——

Please help me. Ask any questions you need.
TY

Источник

Прошу помощи с OpenVPN

цель соединить две сети. есть два сервера под ClearOS 6.3

основной офис с подсетью 192.168.0.0/24 и шлюзом с OpenVpn в роли сервера 192.168.0.250 Второй офис c подсетью 192.168.0.2/24 и шлюзом с Openvpn в роли клиента

Иногда коннект происходит и из сети за клиентом пингуется сеть основного офиса. при проблемах в подключении лог клиента выглядит так:

Ну как минимум keepalive одинаковый поставьте.

Одинаковые сети чтоль на обоих концах?

нет конечно вторая сеть 192.168.2.0/24, у шлюза во второй сети ip 192.168.2.1 внутренний

пробовал tcp вместо udp?

Tue Mar 26 12:35:45 2013 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Tue Mar 26 12:35:45 2013 TLS Error: TLS handshake failed

пробовал, вроде по стабильней, но мне нужно sip пускать между этими сетями

TCP в OpenVPN не имеет смысла.

я беру подсказку- звонок другу tazhate

аргументируешь?
при убогих каналах на удп далеко не уедешь

cast tazhate , у него лучше получится :).

лишь бы не скатился до уровня мегабакса с брызганьем слюнями, а-ля «тсп говно, удп форева» без аргументов

А просто помониторить состояние коннективности между точками, мимо VPN ? Есть много разных вариантов, как результат icmp echo в какую-нибудь rrd писать.

при убогих каналах на удп далеко не уедешь

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

А ты уверен, что канал нормальный между офисами?
Провайдер одинаковый хотя бы?

ну вот у меня были случаи, когда опенвпн по удп дох, а по тсп нормально работал.

проверял пингом, все нормально.

сейчас эту же ошибку TLS ERROR наблюдаю на виндовом машине которая на ходиться в основном офисе, то есть подключение по локальной сети до сервера

ну вот у меня были случаи, когда опенвпн по удп дох, а по тсп нормально работал.

Надо было внимательно логи смотреть и прочие радости.

Пинг — не показатель. Погоняй iperf например.

Надо было внимательно логи смотреть и прочие радости.
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed

вот такое же было

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

еще пока был активным vpn туннель, была ошибка в которой было про mtu=1400, код ошибки 90, может кто пояснит как правильно прописать mtu-tun,mssfix? как я понял по умолчанию стоит mtu=1500,а mssfix=1450

была ошибка в которой было про mtu=1400, код ошибки 90, может кто пояснит как правильно прописать mtu-tun,mssfix? как я понял по умолчанию стоит mtu=1500,а mssfix=1450

А как два офиса видят друг друга? Имею ввиду физическую связность. Езернеты/адслы/вифи? Понизь мту, вполне может помочь. 1400 вполне норм будет.

в основном офисе на шлюзе стоит multi-wan: проводной интернет(pppoe через ethernet) и Yota-модем в usb, на обоих static ip,в удаленном Yota-модем в роутер, а дальше в шлюз с OpenVPN. При подключении на ip проводного инета, он подключается, но рандомно падает с приведенным выше логом, может минут на 20,может меньше.И при этом как то заметил пару ошибок с упоминанием mtu=1400 код 90. Как я выяснил у проводного провайдера mtu=1500, а у Yota mtu=1400.

можешь помочь с мту? я так понимаю указание в обоих конфигах mtu-tun=1400 недостаточно,там есть же еще всякие mtu extra,mssfix

udp внутри udp — bad udp внутри tcp — good tcp внутри tcp — bad

у меня на yota была такая же проблема, решение не нашел, благо yota была заменена на нормальный интернет

напомни, если не лень, как работает опенвпн с

может я чего то не понимаю

Дык все просто. В конфиге как сервера, так и клиента. Последняя строка нужна только если клиент — винда.

ну данные изменения не повлияли на работу vpn

Попробуйте переключиться на udp и задать ″link-mtu 800″ и на сервере и на клиенте.

он и так под udp

Хорошо, значит я не правильно понял ваш третий комментарий.

Ещё можно попробовать icmp-пакеты больших размеров не через vpn-тунель, а напрямую (″ping -s 2000″) и больше (10000-30000). Если YOTA не режет icmp, то ping с размером больше MTU физического линка приводит к появлению нескольких фрагментов (пакетов) идущих по линии подряд. Это хорошая проверка качества линии и, возможно, что вы просто хотите от YOTA невозможного.

Вообщем, клиент под виндой в основном офисе подключаясь к серверу OpenVPN по локальной сети работает отлично!

Ради интереса упростил конфиги до:

лог на клиенте стал выглядеть так:

Я так понимаю,что проблема в потерях пакетов. С этим можно как нибудь бороться?Может какой нить PPTP или IPSec поднять, поможет ли?Или что посоветуете для объединения сетей двух офисов и SIP между ними?

Проблемы с потерей пакетов диагностируются с помощью утилит ping, iperf. Можно с помощью nc и tcpdump. openvpn не относится к утилитам диагностики канала.

Иногда на радиоканалах помогает небольшое значение в ″link-mtu″.

PPtP ещё более критичен к потери пакетов, чем openvpn.

Если у вас на физическом уровне заметные потери пакетов, то никакие тунели не спасут, особенно для SIP-трафика.

Проблемы с потерей пакетов диагностируются с помощью утилит ping, iperf. Можно с помощью nc и tcpdump. openvpn не относится к утилитам диагностики канала.

это понятное дело, сейчас iperf запустил, выложу лог.

Иногда на радиоканалах помогает небольшое значение в ″link-mtu″.

а что означает link-mtu?

По этому логу у вас нормальный канал.

Но, нужно добавить серверу опцию ″-i 10″ и перенаправить вывод в файл, чтобы потом можно было оценить, «размазаны» ли потери пакетов равномерно, или есть интервалы времени, когда вобще пакеты не проходят. Тесты сделать в оба направления (можно одновременно на разных портах на каждой машине запустить и сервер и клиент).

Если у вас безлимитный трафик, то надо сделать тест делать минут 20-30, раз у вас разрывы связи были где-то через 20 мин.

Все результаты тестов сюда выкладывать не надо, это ваш канал, вам понимать, можно ли на нём работать.

Можно поделать тесты в разное время суток, попробовать одновременно с тестированием загрузить канал другим трафиком (допустим http) и посмотреть, что влияет на потери udp-пакетов.

P.S. link-mtu это ограничение размера udp-пакета, несущего openvpn данные. Чем он меньше, тем, ИМХО, на радиоканале больше шансов, что он дойдёт.

в общем переключил на TCP протокол и все заработало. компы по ip адресам открываются из обоих сетей,SIP проходит нормально. Единственный вопрос: в основном офисе есть AD на Win Serv 2008, а вот во удаленном офисе компы не видят его как сервер AD, хотя по IP он открывается, можно с этим чтонить придумать?

и еще вопрос как увеличить soft reset? а то он по умолчанию каждый час происходит?

Источник

Getting this?

Dec 28 04:16:28 DD-WRT-INTERNET-ASUS daemon.notice openvpn[18115]: TCP connection established with [AF_INET]192.168.0.76:64101
Dec 28 04:16:29 DD-WRT-INTERNET-ASUS daemon.notice openvpn[18115]: 192.168.0.76:64101 TLS: Initial packet from [AF_INET]192.168.0.76:64101, sid=6624e5bc bebf0a81
Dec 28 04:16:29 DD-WRT-INTERNET-ASUS daemon.err openvpn[18115]: 192.168.0.76:64101 TLS Error: reading acknowledgement record from packet
Dec 28 04:16:29 DD-WRT-INTERNET-ASUS daemon.err openvpn[18115]: 192.168.0.76:64101 Fatal TLS error (check_tls_errors_co), restarting
Dec 28 04:16:29 DD-WRT-INTERNET-ASUS daemon.notice openvpn[18115]: 192.168.0.76:64101 SIGUSR1[soft,tls-error] received, client-instance restarting

Enable TLS on the server:

Copy paste the ta.key contents into the TLS Auth Key box of the DD-WRT router.  Ensure your .ovpn config file also contains this:

# If a tls-auth key is used on the server
# then every client must also have the key.
tls-auth ta.key 1

Ensure the ovpn.conf file on the DD-WRT router has the following config:

root@DD-WRT-INTERNET-ASUS:/tmp/openvpn# cat openvpn.conf
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
keepalive 10 120
verb 3
mute 3
syslog
writepid /var/run/openvpnd.pid
management 127.0.0.1 14
management-log-cache 100
topology subnet
script-security 2
port 1194
proto tcp4-server
cipher aes-256-cbc
auth sha256
client-connect /tmp/openvpn/clcon.sh
client-disconnect /tmp/openvpn/cldiscon.sh
client-config-dir /jffs/etc/openvpn/ccd
comp-lzo adaptive
tls-server
ifconfig-pool-persist /tmp/openvpn/ip-pool 86400
client-to-client
push «redirect-gateway def1»
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
tcp-nodelay
tun-mtu 1500
mtu-disc yes
server 10.1.1.0 255.255.255.0
dev tun2
tls-auth /tmp/openvpn/ta.key 0
push «dhcp-option DNS 192.168.0.224»
push «dhcp-option DNS 192.168.0.44»
push «dhcp-option DNS 192.168.0.154»
push «route 192.168.0.0 255.255.255.0»
root@DD-WRT-INTERNET-ASUS:/tmp/openvpn#
 

Cheers,
TK

This entry was posted

on Saturday, December 28th, 2019 at 4:35 am and is filed under NIX Posts.
You can follow any responses to this entry through the RSS 2.0 feed.

You can leave a response, or trackback from your own site.