Replay windows backtrack occurred

Replay-window backtrack occurred[]

If you are getting this error/warning anywhere in your connection log

and you step into any serious connectivtiy issues on UDP, then don’t fret.

There are two ways to resolve and optimise this issue.

1. The first option is to submit a ticket via support.nvpn.net and stating that you are having this issue while providing your connection log and we will switch you over to an optimized UDP configuration, which in 90% resolves exactly this typical UDP problem.

Important note : Understand that NOT automatically everyone who encounters this known and UDP typical warning, always has connection problems from this. It is solely and only for the user who encounters this error AND as a result of this, stumbles into slowdowns and similar connection issues (and this especially on heavy download tasks / torrent, but not on regular browsing).

2. The second option is this; since the problem is caused by using the UDP protocol, you can switch over to a TCP protocol (443) IP instead. To do this, go to the Client Area and tick the box labeled to the left of «I need a :443 IP», then once the box is ticked, hit the «I need a :443 IP» button. Proceed to download the new config, replace your current config with the new one. This will cause a 5-10% drop in speed and higher latency and less IPs available, so the first option is always reccommended first.

Windows → Настройка OpenVPN клиента на Windows 10

И снова здравствуйте.
Эта последняя статья посвященная OpenVPN в целом и настройке клиента в частности. В этот раз мы настроим с вами клиента под Windows 10 но на предыдущих версиях этой операционной системы все это тоже будет работать. Задача следующая, обеспечить подключение клента к нашему OpenVPN серверу, который мы настраивали в с статье: Настраиваем OpenVPN сервер Linux на примере Ubuntu мы уже можем настраивать клиента Ubuntu, осталось дело за малым, чем мы сейчас и займемся.
Чтобы приступить к настройке, нам необходимо скачать, этого самого, клиента для Windows, я качал под 64 разрядную ОС.
Тут все просто, качаем клиента с сайта openvpn.net/index.php/download/community-downloads.html
Запускаем установку и следуем указаниям инсталятора, по принципу Next -> Next -> OK

Переходим в директорию с установленным OpenVPN

Нам необходимо создать там файл, назовем его client.ovpn с содержимым:

Нам необходимо получить с OpenVPN сервера 4 файла:

Где:
ca.crt и ta.key первый является сертификатом удостоверяющего центра, второй это ключ шифрования OpenVPN сервера, они должны быть у каждого пользователя!
user.crt и user.key ключ и сертификат пользователя, у каждого пользователя они свои т.е. создаются персонально

Дальше на остается запустить OpenVPN клиента:

Нажимаем подключиться:

Появится лог подключения, который при установке соединения исчезнет:

Иконка подключения станет зеленой, значит соединение установлено и работает нормально, также появится плашка в которой будет написан присвоенный IP адрес

Для клиентов Windows есть особенность, необходимо указывать IP адреса из диапазона в 4 адреса т.е. если вы хотите присвоить клиенту адрес 172.16.10.4 то соединение на другом конце должны быть из диапазона:

Иначе соединение обрывается, во так все просто.

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

Оpenvpn потери пакетов

Добрый день !
Возможно кто-нибудь сталкивался с подобной проблемой, подскажите. Дано:

Маршрутизируемая vpn сеть (10.10.10.0/24)
Несколько локальных сетей дополнительных офисов 192.168.х.0/24 (!=192.168.0.0/24)
Сеть 192.168.0.0/24 — сеть филиала, где находится СП — 192.168.0.100 и vpn шлюз — 192.168.0.1 == 10.10.10.1

Проблема в следующем, из одного доп.офиса, (подсеть 192.168.1.0/24) до 192.168.0.0/24 _именно_через_туннель_ (!) имеются потери пакетов (%25-%50)
Что касаемо остальных офисов 192.168.4.0/24 потерь нет.
Что удивительно, mtr показывает потери только через vpn туннель (т.е до 10.10.10.1), через улицу же до внешней ip (222.222.222.222 == 10.10.10.1) потерь нет.
Конфигурации серверов везде одинаковые. Я бы предположил что потери идут на уровне провайдера, но тогда почему через улицу потерь нет ?
Я в тупике, прощу помощи. Конфигурации приложу.

Ждем конфигураций и логов

Лог с сервера при соединении /var/log/openvpn.log:

Лог с клиента /var/log/openvpn.log

Что еще можно выложить ?

Я бы предположил что потери идут на уровне провайдера, но тогда почему через улицу потерь нет ?

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

Выше ^^ правильная рекомендация. Если она не поможет:

Посмотрите, нет ли у вас проблем с роутингом или firewall’ом на обоих концах туннеля, посмотрите системные логи на предмет подозрительных записей.

Ну вариантов оперативно это попробовать нет.
Да и думаю, что udp при столь сильной потере пакетов работает лучше, нежели tcp.
Соединение с интернетом по adsl, попробую сменить модем, если ситуация не измениться, провайдера.
Просто нужно быть точно уверенным, что проблема не на нашей стороне.

Да и думаю, что udp при столь сильной потере пакетов работает лучше, нежели tcp

Это понятно, просто это такой тестовый workaround — замаскировать трафик под обычный https. А вот udp https не бывает, так что может и не прокатить.

Там вроде даже есть хитрый режим сосуществования на одном порту с HTTPS сервером.

может в одном из роутеров cpu на 100% загружен?

от этого тоже могут быть потери

Подтверждаю, что провайдеры не любят udp.

У меня один провайдер как-то хитро рубит udp. Или по достижению определённого объёма или ещё как, но постоянно udp порт по которому идёт тунельный трафик начинает очень сильно резаться, но не наглухо, а так, что проходят около 10% пакетов. Если запускать тунель на другом порту, то всё хорошо работает сутки другие, а потом опять начинаются потери. Идти ругаться с провайдером мне не охото, поэтому раз в сутки скрипт назначает для тунеля новый порт.

но не наглухо, а так, что проходят около 10% пакетов

Пров вряд ли режет. Ну просто нету таких настроек в промышленном сетевом оборудовании для «хитрого дропа». Ставить серваки с несколькими 10G картами для этого — сомнительная идея. На firewall от paloalto, fortinet и других тож такого нету. Даю 99,9% что пров непричем. Проверь, не забит ли с какой из сторон канал? может у тебя глючит сетевое оборудование или в нем есть специальные «фичи частичного дропа»? Например, частичный дроп пинга на ASA — это нормально. Сколько головняка отымел из-за этого.

у меня провайдер ютуб режет, имхо

Три девятки это круто :-)) Я знаю, что такое поведение как у меня реализовать сложно. Но я долго проверял, что режется только udp, и именно тот порт, по которому работает тунель. Ощущение, что провайдер по каким-то признакам признаёт порт «плохим» и весь трафик этого порта загоняет в шейпер с очень низкой полосой.

Когда по тунелю начинались большие потери пакетов, простое переключение тунеля на другой порт исправляет ситуацию, при этом по udp-порту, где был тунель, трафик так и остаётся с потерями, что проверял с помощью nc и tcpdump. 10% это взял так с потолка. Там поведение такое, что может секунд 30-60 вобще ничего по этому udp-порту не проходить, а потом несколько секунд все пакеты ходят. При этом по другим udp-портам пакеты ходят без потерь.

Больше всего похоже, что провайдер обрабатывая статистику выявляет udp-порты с которых идёт раздача торрентов и заворачивает их все (от всех абонентов) в один шейпер. Когда пакетов много шейпер и будет их дропать, торрентам не так критичны потери пакетов, поэтому абоненты особо не возмущаются. И такое в принципе реализуется без серверов с 10G сетёвками. Но может сделано что-то другое.

Средний. Если верить том, что дано здесь http://yamobi.ru/posts/ekaterinburg_internet.html то на январь 2012 у него было 55 тыс. подключений.

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

Механизм такой — если на твой аккаунт по радиусу передается соответствующий параметр, то тебя можно завернуть на нужную трассу, где ресурсы могут быть блокированы/частично блокированы сетевым экраном. На каждой из трасс можно применять свои фильтры. Но в любом случае делать частичный дроп — слабоумие. Если пров мелкий, то может будут мутить такую гадость пакетным фильтром на серваке, на который заворачивается трафик. По таким фокусам я не особый тебе помощник. Еще есть какие-то особые хитрые прокси, которые используются мобильными операторами. Попробуй порыть в этом направлении, если у тебя выдается айпишник из диапазона для LAN.

И еще попробуй уменьшить mtu для туннеля, например до 1300. У провайдера внутри все может быть не так просто, как кажется на первый взгляд обычному пользователю.

Плюсую этого камрада.
Еще можно не 443, а какой-нибудь левый порт из верхних, но tcp обязательно. С udp частенько бывают проблемы.

Разумное предположение. У меня была схожая ситуация — в один прекрасный день через одного провайдера упала скорость pptp. Поменял на openvpn — скорость вернулась к тарифной.

Сделал так, потери сильно уменьшились

чет там пошаманил, потери вообще исчезли.

А если удалить вот это:

-t mangle -A OUTPUT -p udp —dport 9876 -j TOS —set-tos Minimize-Delay

Сегодня специально проверял. Потери опять появляются %15-18, но в меньшей степени, было %25-%50.

OpenVPN Support Forum

Community Support Forum

No «Replay-window backtrack occurred [x]» messages

No «Replay-window backtrack occurred [x]» messages

Post by catkin » Mon Apr 08, 2013 7:00 am

We would like to resolve an issue of commonly having «Authenticate/Decrypt packet error: bad packet ID (may be a replay)» messages.

We believe the underlying cause is that we have three load-balancing Internet-facing routers at the OpenVPN client site. Presumably the client’s public IP address changes, the server somehow continues service but the UDP packet stream arriving at the client is disrupted.

Research suggests the solution is to configure the client’s replay-window to suit the characteristics of the network and the value to use can be determined by running with verb to 4 to get «Replay-window backtrack occurred [x]» messages.

The client’s config was changed and openvpn restarted using SIGUSR1 which seems to have worked. From the log:

After two days of running with verb 4, we still have plenty of «Authenticate/Decrypt packet error: bad packet ID (may be a replay)» messages but not a single «Replay-window backtrack occurred [x]» message.

Versions and configurations .

Client running OpenVPN 2.1.3 on Debian 6.0.6 with this config:

Re: No «Replay-window backtrack occurred [x]» messages

Post by janjust » Tue Apr 09, 2013 11:18 am

Re: No «Replay-window backtrack occurred [x]» messages

Post by catkin » Wed Apr 10, 2013 4:58 am

Thanks Jan

I’ve done that and will report the effect.

I’m not hopeful because it is the client that has changing public IPs but let’s see.

Re: No «Replay-window backtrack occurred [x]» messages

Post by catkin » Fri Apr 12, 2013 7:35 am

Will continue to monitor the situation, especially as we saw » Authenticate/Decrypt packet error: bad packet ID (may be a replay)» messages on another OpenVPN client yesterday but could not reproduce it this morning.

Testing yesterday, we tail/followed the other OpenVPN client’s syslog in one terminal and pinged the client by OpenVPN address from the OpenVPN server. For each ping there were » Authenticate/Decrypt packet error: bad packet ID (may be a replay)» messages. This casts doubt on whether the underlying cause is the load balancing router because the ping would generate a small number of packets.

When we can reproduce this behaviour, we ping a single packet, at least on the OpenVPN network (the number of packets that then travel over the underlying UDP network is not yet known).

In testing yesterday we noticed the number in brackets (the 281 in » bad packet ID (may be a replay): [ #281 ]«) monotonically increasing by one whereas other reports of this message show discontinuous number sequences with large gaps. This may be associated with why we do not get the «Replay-window backtrack occurred [x]» messages . ?