Openvpn options error failed to negotiate cipher with server

---

---

---

---

---

---

Hi all,

Trying to set up an OpenVPN connection on pfSense 2.4.5-RELEASE-p1. I am using the SSL-TLS+user auth method. I have a Apple Macbook with Tunnelblick 3.8.4 (build 5600), where I have imported the .ovpn config file generated from the pfSense OpenVPN client conf exporter plugin.

When I try connecting, it fails, with this error:

      1606165530.305305 b000 Options error: Unrecognized option or missing or extra parameter(s) in /Library/Application Support/Tunnelblick/Users/will/pcol-gw-wdennis.tblk/Contents/Resources/config.ovpn:4: data-ciphers (2.4.9)

I have set the NCP Algorithms on the pSense server to include all of the AES-* algo’s. The data-ciphers* lines in the client config are:

data-ciphers AES-128-CFB1:AES-128-CFB8:AES-128-OFB:AES-192-CBC:AES-192-CFB:AES-192-CFB1:AES-192-CFB8:AES-192-OFB:AES-256-CBC:AES-256-CFB:AES-256-CFB1:AES-256-CFB8:AES-256-OFB
data-ciphers-fallback AES-128-CBC

Thanks for any help or info you can provide.

I found that the latest OpenVPN client exporter updates generates OpenVPN 2.5 configs even on pfSense 2.4.5-p1 and when the OpenVPN server is still version 2.4x

I had to check don’t include 2.5 config options

You shouldn’t blindly include all the AES algorithms. Stick to the GCM and CBCs. Most likely explanation is that your client platform doesn’t support one or more of the ciphers.

The client export generates OpenVPN 2.5 configs because it exports OpenVPN 2.5 installers, so that’s probably OK (provided your client platform is running OpenVPN 2.5…)

Your log message does say your client is OpenVPN 2.4.9, though, so you probably do need to update the client to one that uses OpenVPN 2.5.0 or tick the Legacy box and export again.

yea, the error message said,

... config.ovpn:4: data-ciphers (2.4.9)

so I assumed his client was 2.4.9 and not 2.5, but yea, that is a lot of ciphers as well to enable… yea, easiest just to stick GCM/CBC like @jimp said

Thanks for the help, folks!

I upgraded Tunnelblick to 3.8.5beta01 (build 5610), which has OpenVPN 2.5 (also had to set «OpenVPN version» drop in Settings to «Latest», which is OpenVPN 2.5.0 w/ OpenSSL 1.1.1h)

Also edited my client config, it is now:

dev tun
persist-tun
persist-key
data-ciphers AES-128-CBC:AES-192-CBC:AES-192-CFB:AES-192-OFB:AES-256-CBC:AES-256-CFB:AES-256-OFB
data-ciphers-fallback AES-128-CBC
auth SHA256
tls-client
client
resolv-retry infinite
remote vpn-gw.mycompany.com 1194 udp4
verify-x509-name "vpn-gw.mycompany.com" name
auth-user-pass
remote-cert-tls server

Now I do get connected, but I do not have a route to the remote LAN, just one for the VPN network itself (local LAN is 192.168.100.0/24, OVPN network is 192.168.5.0/24, and remote LAN is 192.168.10.0/24):

mymac:~ me$ netstat -nr -f inet | grep -v -e I -e "/32"
Routing tables

Destination        Gateway            Flags        Netif Expire
default            192.168.100.1      UGSc           en0
127                127.0.0.1          UCS            lo0
127.0.0.1          127.0.0.1          UH             lo0
169.254            link#4             UCS            en0      !
192.168.5          192.168.5.2        UGSc         utun6
192.168.5.2        192.168.5.2        UH           utun6
192.168.100        link#4             UCS            en0      !
224.0.0/4          link#4             UmCS           en0      !

The end of the Tunnelblick log has:

                           13:05:17 *Tunnelblick:  Start of output from client.up.tunnelblick.sh
                           WARNING: $route_vpn_gateway is empty
                           13:05:19 *Tunnelblick:  NOTE: No network configuration changes need to be made.
                           13:05:19 *Tunnelblick:  WARNING: Will NOT monitor for other network configuration changes.
                           13:05:19 *Tunnelblick:  WARNING: Will NOT disable IPv6 settings.
                           13:05:19 *Tunnelblick:  DNS servers '192.168.100.1' will be used for DNS queries when the VPN is active
                           13:05:19 *Tunnelblick:  NOTE: The DNS servers do not include any free public DNS servers known to Tunnelblick. This may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.
                           13:05:19 *Tunnelblick:  Flushed the DNS cache via dscacheutil
                           13:05:19 *Tunnelblick:  /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil
                           13:05:19 *Tunnelblick:  Notified mDNSResponder that the DNS cache was flushed
                           13:05:19 *Tunnelblick:  Notified mDNSResponderHelper that the DNS cache was flushed
                           13:05:19 *Tunnelblick:  End of output from client.up.tunnelblick.sh
                           13:05:19 *Tunnelblick:  **********************************************
2020-11-24 13:05:19.792773 Initialization Sequence Completed
2020-11-24 13:05:19.792939 MANAGEMENT: >STATE:1606241119,CONNECTED,SUCCESS,192.168.5.2,71.xxx.xxx.xxx,1194,,
2020-11-24 13:05:21.018480 *Tunnelblick: Routing info stdout:
   route to: 192.168.100.1
destination: 192.168.100.1
  interface: en0
      flags: <UP,HOST,DONE,LLINFO,WASCLONED,IFSCOPE,IFREF,ROUTER>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500      1116 
stderr:

2020-11-24 13:05:21.018824 *Tunnelblick: Warning: DNS server address 192.168.100.1 is not a public IP address and is not being routed through the VPN.


2020-11-24 13:05:26.193775 *Tunnelblick: This computer's apparent public IP address (71.zzz.zzz.zzz) was unchanged after the connection was made

So it seems I may be missing some needed entries yet on the pfSense (server) side? I made the OVPN config on pfSense via the wizard.

I know its 20 min long these days, but worth a watch and goes over all this settings, including routing to your local network: https://www.youtube.com/watch?v=PgielyUFGeQ

Are you probably missing server settings for IPv4 Local network(s) and IPv6 Local network(s)

I’m having this problem even with the 2.5.0 client on windows.

2021-05-12 08:13:40 OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
....
2021-05-12 08:13:54 OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's cipher ('AES-128-CBC') to --data-ciphers (currently 'AES-128-GCM') if you want to connect to this server.

the generated ovpn file has

data-ciphers AES-128-GCM
data-ciphers-fallback AES-128-CBC

if I mark the «legacy client» option it changes to

cipher AES-128-CBC

and the client can connect.
It seems the client is ignoring the data-ciphers-fallback option.

Command line pfSense :

openvpn --help

The first line tells you that the latest pfSense (2.5.1) is using

OpenVPN 2.5.1 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Apr  5 2021

I only export settings from pfSense, not the ‘executable Windows OpenVPON Installer package’, I download the latest OpebVPN client from OpenVPN (it’s also open source).

Get it from here : https://openvpn.net/community-downloads/

Like pfSense, don’t stay on «2.5.0». OpenVPN had issues to, so they went to 2.5.1 to stabilised, for now, on 2.5.2.
The 2.5.2 client works fine with the OpenVPN server 2.5.1 on pfSense.

Btw : It’s just pure coincidence that OpenVPN uses nearly identical version numbers as the CE version of pfSense.

@gertjan thank you, but for me and my users the all in one installer is more convenient. I didn’t know that openvpn 2.5.0 had issues.

@gertjan said in Getting error on «data-ciphers» line on OVPN client:

Get it from here : https://openvpn.net/community-downloads/

I just tried with the 2.5.2 openvpn client and it has the same problem:

Wed May 12 10:14:28 2021 OpenVPN 2.5.2 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 21 2021
....
Wed May 12 10:16:22 2021 OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's cipher ('AES-128-CBC') to --data-ciphers (currently 'AES-128-GCM') if you want to connect to this server.

maybe it’s because I’m still with pfSense 2.4.5p1 that has openvpn 2.4.9 (I cannot upgrade to 2.5.1 due to its problems with NAT and multi WAN)

@olivluca said in Getting error on «data-ciphers» line on OVPN client:

openvpn 2.5.0 had issues.

As pfSEnse, they have a FAQ, manual, forum etc.
Yes, they have issues — like any other huge (OpenVPN is huge ….) (software) product.

The shift from 2.4.x to 2.5.x has special help pages, with all the details about these changes.

If you use OpenVPN, don’t hesistate. Bookmark this one — and use it.

@gertjan said in Getting error on «data-ciphers» line on OVPN client:

Yes, they have issues — like any other huge (OpenVPN is huge ….) (software) product.

Sure, but I didn’t mean it like that, I was referring to the interaction with the «client export» generated settings. Anyway, the latest release of openvpn has the same problem.

   1СникКривыеРуки

08.01.21 — 19:49

Прошу помочь советом.

Стояло 6 лет win 8.1, но решил перейти на Win10 по ряду причин.

Все нормально, НО!

ОДНО из соединений OpenVPN перестало работать.

Итак.

Есть несколько настроенных соединений OpenVPN с расширением ovpn и последняя версия OpenVPN 64 битная.

Но из 3 соединений на разные сервера одно не работает. Причем не работает то, которое самое нужное.

Остальные 2 соединения на другие сервера — работают и на старой и на новой винде.

Ставил старый винт с win8.1, вычищал OpenVPN и все заново переставлял — все работает, как и работало.

А на новой,- что только не делал — и запуск под Администратором, и установку предыдущих версий и проч.

2 соединения работают, а это самое главное — нет.

Системные администраторы на работе из дома под собой проверили (у них win10) — работает нормально.

Прошу помочь советом — что делать и куда смотреть.

   1СникКривыеРуки

1 — 08.01.21 — 19:50

   1СникКривыеРуки

2 — 08.01.21 — 19:51

   1СникКривыеРуки

3 — 08.01.21 — 19:51

   Йохохо

4 — 08.01.21 — 20:00

failed to negotiate cipher with server.  Add the server’s cipher (‘BF-CBC’)

   1СникКривыеРуки

5 — 08.01.21 — 20:19

   1СникКривыеРуки

6 — 08.01.21 — 20:19

тема закрыта

   Доктор Манхэттен

7 — 08.01.21 — 23:26

(0) OpenVPN — зло. Нужно использовать стандартную VPN.

   Злопчинский

8 — 09.01.21 — 00:37

(7) вот например стандартный впн у меня не работал. потому что серый айпи. при этом опен впн — работал

   Доктор Манхэттен

9 — 09.01.21 — 00:39

   Злопчинский

10 — 09.01.21 — 00:45

(9) я хз сомнительно или нет. но заставить подключаться по штатному ВПН — не получилось. Порезfys пакеты у провайдера видимо. купил за 150р/месяц белый айпи — все стало мгновенно хорошо. и по штатному ВПН.

   DJ Anthon

11 — 09.01.21 — 08:38

(7) ее блочат некоторые провайдеры. в забайкальском крае — ТТК, а там он очень популярен.

(5) да, в ней куча глюков, пришлось искать старую.

   DJ Anthon

12 — 09.01.21 — 08:40

(10) к сожалению, не могу заставить бабушек покупать домой всякие белые айпи ((

   Провинциальный 1сник

13 — 09.01.21 — 08:50

(7) Стандартная vpn с имитацией диалапа — убога до невозможности.

   Провинциальный 1сник

14 — 09.01.21 — 08:57

(11) А я давно замечаю, что как только какое-то ПО вылижут до идеального состояния — сразу делается рефакторинг с нуля на каком-то новомодном тулките или среде разработке, и всё работать перестает нормально. Неоднократно такое замечал. Эффект шила в попе у разработчиков что ли такой..

   Йохохо

15 — 09.01.21 — 09:00

(11) WireGuard работает по своему протоколу, на произвольном порту, русифицирован и конфиг можно юзеру по почте отправить. Я еще не донастроил, но вроде перспективно)

   DJ Anthon

16 — 09.01.21 — 09:17

(15) у меня микротик, он умеет поднимать pptp и openvpn. pptp заблочили, я перешел на openvpn. а WireGuard линевый, я в нем не спец. да и переводить килотонны мануалов на русский, а потом еще на понятный русский неохота. а по опенвпну есть мануалы для ламеров, я по ним все настроил. да, было сначала страшно, но буквально все настраивается за полчаса, не знаю, почему раньше не попробовал все это дело. единственная проблема, что опенвпн, поднятый на роутере ASUS работает не так, как на микротике — он пропускает в интернет после коннекта к впн, а микротиковский впн блочит все, пока не отключишься. это даже лучше для клиентов, чтобы работали и не отвлекались, причину найти не могу, но для работы достаточно.

   Йохохо

17 — 09.01.21 — 09:26

(16) для меня наоборот микротик это макось с диалектом на ингрише. опенвпн не хочу т.к. древний интерфейс, а проблема как раз в домохозяйках удаленщицах с зверцд вин 7, пптп то работает. ВайрГвард тоже с глюками, но мб факультативно доковыряю

   Злопчинский

18 — 09.01.21 — 15:36

(16) «а микротиковский впн блочит все, пока не отключишься.»

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

   NorthWind

19 — 09.01.21 — 16:08

   NorthWind

20 — 09.01.21 — 16:10

если работаете иногда на андроидном телефоне/планшете через VPN, то там все еще проще. В стандартном VPN-клиенте есть поле ввода «Маршруты пересылки». Вот туда и прописываете подсеть локалки предприятия, с которой работаете. И вуаля — после того как загорится значок VPN в прямоугольнике, доступ в инет у дрюши не пропадет.

   Йохохо

21 — 09.01.21 — 16:27

(19) там есть route -p . Но возможно микротик не учитывает дефаулт гейтвей, они же гордые, им подавай пряморуких

   Провинциальный 1сник

22 — 09.01.21 — 17:32

(19) Чтобы задать маршрут к удаленной сети через впн, не меняя шлюза по умолчанию, нужно указывать идентификатор сетевого интерфейса, а он при каждом подключении разный. Так что route -p не катит..

   mistеr

23 — 09.01.21 — 17:36

(5) Вопрос чисто из любопытства. Зачем тебе OpenVPN, если тебе пофиг на «INSECURE cipher»?

   ДедМорроз

24 — 09.01.21 — 17:36

Начиная с windows 8,есть возможность указывать маршруты в привязке в сетевому соединению,тогда они будут включаться только при его установке.

Но,печальна ситуация,когда какая-то подсесть организации совпадает с подсетью провайдера.

   Провинциальный 1сник

25 — 09.01.21 — 19:16

(24) «Но,печальна ситуация,когда какая-то подсесть организации совпадает с подсетью провайдера.»

Скорее не с подсетью провайдера, а с подсетью клиента. У них от роутера часто 192.168.x и в организации та же. Провайдеры же обычно используют более экзотические серые подсети, 100 или 172.

   NorthWind

26 — 09.01.21 — 20:37

(25) ну тут уже сисадмин организации злобная буратина… По крайней мере можно сделать какую-нибудь 192.168.112.*, а не 192.168.0.* или 1.*

   ДедМорроз

27 — 09.01.21 — 23:33

Провайдеры пытаются раздать подсети так,чтобы они в разных регионах не повторялись — от этого «экзотические» номера и получаются.

   ДедМорроз

28 — 09.01.21 — 23:35

У клиентов,как раз,все более просто,стандартные для роутеров подсети 0, 1 или 2.

Более экзотические варианты встречаются,если кто-то прописывает вручную.

   DJ Anthon

29 — 10.01.21 — 08:05

(17) так вот у меня как раз PPTP-то и не работает, я был бы рад его использовать. А удаленщицам кидаю только дистриб по почте, в котором все зашито, им надо только установить, ничего настраивать не надо, все прописано в конфиге. насчет того, что это макось на инглише — к ней хотя бы мануалы есть русские. для остального софта надо штудировать все на английском. сейчас посмотрел этот WireGuard — русского не нашел.

(18) в инете есть сотня советов и все они сводятся к одному — поменять маршрут, только вот для этого должно одно условие соблюдаться — подсети должны быть разные. а у меня они одинаковые. то есть и в офисе подсетка 192.168.1.1, и у большинства юзеров дома тоже 192.168.1.1. в офисе не вариант менять подсеть — там все айпи в оборудовании зашиты, на это год надо, чтобы все заменить, так как штатного сисадмина там нет. у домохозяек дома менять тоже не вариант, они, как правило, не знают пароля от роутера, да и ехать к ним не вариант, их много и они далеко. я надеялся настроить так, чтобы только 1-2 адреса открыть из офиса, грубо говоря, объединить сетки, но роутеры мне показывают хер. даже если я пытаюсь указать шлюз офиса, интернета все равно нет. самое интересное, что на роутере ASUS впн спокойно все объединял сам и я даже не думал, что эта проблема вообще возникнет. тут вроде есть толковые сисдамины, но они говорят — единственный способ — менять подсетку в офисе на другие адреса. не буду. мне за это не платят.

   DJ Anthon

30 — 10.01.21 — 08:08

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

   DJ Anthon

31 — 10.01.21 — 08:14

(21) где-то в роутере надо прописывать, чтобы он впновских юзеров пускал в инет. но мне туда сказали не лазить, разрешили только сервер опенвпн дали поднять. поэтому я ничего не могу проверить.

   Доктор Манхэттен

32 — 10.01.21 — 08:31

(13) Не используй имитацию диалапа.

   Йохохо

33 — 10.01.21 — 08:32

(30) это в настройках отправляемых клиенту должно быть, что то про пуш роут афаир

   spectre1978

34 — 10.01.21 — 08:40

(30) команду вводить на той машине, которая подключается к удаленной сети.

   Провинциальный 1сник

35 — 10.01.21 — 09:26

(32) Штатные впн в винде по другому не умеют

   Провинциальный 1сник

36 — 10.01.21 — 09:31

(27) Скорее, чтобы не пересечься со стандартной подсетью бытовых роутеров. А там в 99% случаев 192.168.x, так что выбор 100 или 172 серой сети наиболее логичен, некоторые провайдеры дают 10 — но это уже есть риск наткнуться на такую подсеть у клиента..

   spectre1978

37 — 10.01.21 — 14:11

(29) если подсети совпадают, тогда пипец. В этом случае маршрутизация не будет нормально работать.

   Йохохо

38 — 10.01.21 — 14:27

(37) если пиринга нет между клиентами, иногда тошнит но работает)

   ДедМорроз

39 — 10.01.21 — 15:20

Вариант такой

Делаем для vpn свою подсеть и для нее же пишем правила трансляции для всех машин,которые в офисе должны быть доступны,то есть каждой выделяем ещё и адрес из созданной для vpn сети.

Сетей для vpn сделать как минимум две,чтобы в случае совпадения клиенту можно было дать другую.

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

   ДедМорроз

40 — 10.01.21 — 15:26

   DJ Anthon

41 — 10.01.21 — 17:20

(37) самое смешное, что адреса не совпадают (ну, кроме шлюзов, конечно). но если честно, мне вообще все это непонятно. при соединении вообще создаются адреса 10.0.0.х, для чего они тогда нужны? почему бы не выдавать адреса по DHCP? куча адресов свободна, но как их настроить, хз. в мануалах все все по одной схеме делают, шаг влево, шаг вправо — ничего не работает. я вообще хотел бы, чтобы можно было половину одной сетки объединить с половиной другой. или по маске какой-нибудь. там, до 200-х адресов пусть будут домашние адреса, после — офисные. но так низзя (

   DJ Anthon

42 — 10.01.21 — 17:21

(40) вот, это у меня и не получается. надо всего пару адресов прокинуть, я писал маршруты до них.

   Доктор Манхэттен

43 — 11.01.21 — 07:30

(35) Все она умеет. Обнови винду до десятки.

(41) похоже ты делал по мануалу лан2лан, это без маршрутов не работает конечно

Hi,

This is awesome in many ways. Better behaviour, better code and a nice
way forward to really get rid of the BF-CBC default cipher.

It's also somewhat tricky, so here goes for a review purely based on
stare-at-code:

On 17-07-2020 15:47, Arne Schwabe wrote:
> This reworks the NCP logic to be more strict about what is
> considered an acceptable result of an NCP negotiation. It also
> us to finally drop BF-CBC support by default.
> 
> All new behaviour is currently limited to server/client
> mode with pull enabled. P2p mode without pull does not change.
> 
> New Server behaviour:
> - when a client announces its supported ciphers through either
>   OCC or IV_CIPHER/IV_NCP we reject the client with a
>   AUTH_FAILED message if we have no common cipher.
> 
> - When a client does not announce any cipher in either
>   OCC or NCP we by reject it unless fallback-cipher is
>   specified in either ccd or config.
> 
> New client behaviour:
> - When no cipher is pushed (or a cipher we refused to support)
>   and we also cannot support the server's server announced in
>   OCC we fail the connection and log why
> 
> - If fallback-cipher is specified we will in the case that
>   cipher is missing from occ use the fallback cipher instead
>   of failing the connection
> 
> Both client and server behaviour:
> - We only announce --cipher xyz in occ if we are willing
>   to support that cipher.
> 
>   It means that we only announce the fallback-cipher if
>   it is also contained in --data-ciphers
> 
> Compatiblity behaviour:
> 
> In 2.5 both client and server will automatically set
> fallback-cipher xyz if --cipher xyz is in the config and
> also add append the cipher to the end of data-ciphers.
> 
> We log a warn user about this and point to --data-ciphers and
> --fallback-cipher. This also happens if the configuration
> contains an explicit --cipher BF-CBC.
> 
> If --cipher is not set, we only warn that previous versions
> allowed BF-CBC and point how to reenable BF-CBC. This might
> break very few config where someone connects a very old
> client to a 2.5 server but at some point we need to drop
> the BF-CBC and those affected use will already have a the
> scary SWEET32 warning in their logs.
> 
> In short: If --cipher is explicitly set 2.6 will work the same as
> 2.4 did. When --cipher is not set, BF-CBC support is dropped and
> we warn about it.
> 
> Examples how breaking the default BF-CBC will be logged:
> 
> Client side:
>  - Client connecting to server that does not push cipher but
>    has --cipher in OCC
> 
>     OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's cipher ('BF-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-CBC') if you want to connect to this server.
> 
>  - Client connecting to a server that does not support OCC:
> 
>    OPTIONS ERROR: failed to negotioate cipher with server. Configure --fallback-cipher if you want connect to this server.
> 
> Server Side:
> 
> - Server has a client only supporting BF-CBC connecting:> diff --git a/doc/man-sections/protocol-options.rst
b/doc/man-sections/protocol-options.rst

[ Used the output of "git diff -w" to review, so pasting that here is
"original" too. ]

> diff --git a/doc/man-sections/protocol-options.rst b/doc/man-sections/protocol-options.rst
> index 051f1d32..ab22b415 100644
> --- a/doc/man-sections/protocol-options.rst
> +++ b/doc/man-sections/protocol-options.rst
> @@ -57,6 +57,9 @@ configured in a compatible way between both the local and remote side.
>    http://www.cs.ucsd.edu/users/mihir/papers/hmac.html
>  
>  --cipher alg
> +  This option is deprecated for server-client mode and ``--data-ciphers``
> +  or rarely `--data-ciphers-fallback`` should be used instead.
> +
>    Encrypt data channel packets with cipher algorithm ``alg``.
>  
>    The default is :code:`BF-CBC`, an abbreviation for Blowfish in Cipher
> @@ -183,8 +186,9 @@ configured in a compatible way between both the local and remote side.
>    ``--server`` ), or if ``--pull`` is specified (client-side, implied by
>    setting --client).
>  
> -  If both peers support and do not disable NCP, the negotiated cipher will
> -  override the cipher specified by ``--cipher``.
> +  If no common cipher is found is found during cipher negotiation, the

Duplicate "is found".

> +  connection is terminated. To support old clients/server that do not
> +  provide any cipher support see ``data-ciphers-fallback``.
>  
>    Additionally, to allow for more smooth transition, if NCP is enabled,
>    OpenVPN will inherit the cipher of the peer if that cipher is different
> @@ -201,8 +205,18 @@ configured in a compatible way between both the local and remote side.
>    This list is restricted to be 127 chars long after conversion to OpenVPN
>    ciphers.
>  
> -  This option was called ``ncp-ciphers`` in OpenVPN 2.4 but has been renamed
> -  to ``data-ciphers`` in OpenVPN 2.5 to more accurately reflect its meaning.
> +  This option was called ``--ncp-ciphers`` in OpenVPN 2.4 but has been renamed
> +  to ``--data-ciphers`` in OpenVPN 2.5 to more accurately reflect its meaning.
> +
> +--data-ciphers-fallback alg
> +
> +    Configure a cipher that is used to fall back to if the peer does announce
> +    the cipher in OCC.

Isn't OCC to much detail here? I'd suggest something like "if we could
not determine which cipher the peer is willing to use".

> +    This option should normally not be needed.  It only exists to allow
> +    connecting to old servers or if supporting old clients as server.
> +    The are only OpenVPN 2.3 and older version that have configured with
> +    `--enable-small`.

I find this somewhat hard to read and understand, probably because it
/is/ not so easy to understand but... A sugestion (native speakers,
please help improve!):

This option should only be needed when connecting to peers which run
OpenVPN 2.3 or earlier, and are compiled with the --enable-small flag
(typically used on routers or other embedded devices).

>  --ncp-disable
>    Disable "Negotiable Crypto Parameters". This completely disables cipher
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index e92a0dc1..accab850 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -727,7 +727,8 @@ warn_insecure_key_type(const char *ciphername, const cipher_kt_t *cipher)
>      {
>          msg(M_WARN, "WARNING: INSECURE cipher (%s) with block size less than 128"
>              " bit (%d bit).  This allows attacks like SWEET32.  Mitigate by "
> -            "using a --cipher with a larger block size (e.g. AES-256-CBC).",
> +            "using a --cipher with a larger block size (e.g. AES-256-CBC). "
> +            "Support for these insecure cipher will be removed in OpenVPN 2.6.",

These insecure cipher*s*.

> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -2374,7 +2374,30 @@ do_deferred_options(struct context *c, const unsigned int found)
>          {
>              /* If the server did not push a --cipher, we will switch to the
>               * remote cipher if it is in our ncp-ciphers list */
> -            tls_poor_mans_ncp(&c->options, c->c2.tls_multi->remote_ciphername);
> +            bool useremotecipher = tls_poor_mans_ncp(&c->options,
> +                                                     c->c2.tls_multi->remote_ciphername);
> +
> +            if (!useremotecipher && !c->options.enable_ncp_fallback)
> +            {
> +                /* Give appropiate error message */
> +                if (c->c2.tls_multi->remote_ciphername)
> +                {
> +                    msg(D_TLS_ERRORS, "OPTIONS ERROR: failed to negotiate "
> +                        "cipher with server.  Add the server's "
> +                        "cipher ('%s') to --data-ciphers (currently '%s') if "
> +                        "you want to connect to this server.",
> +                        c->c2.tls_multi->remote_ciphername,
> +                        c->options.ncp_ciphers);
> +                }
> +                else
> +                {
> +                    msg(D_TLS_ERRORS, "OPTIONS ERROR: failed to negotioate "

Typo: negotiate.

> +                        "cipher with server. Configure "
> +                        "--data-ciphers-fallback if you want connect "

Typo: if you want *to* connect.

> +                        "to this server.");
> +                }
> +                return false;
> +            }

This block seems to use more indentation levels than needed. Consider
something like:

  else if (ncp_enabled) {
    if (!remote_ciphername) {
      msg("Failed to negotiate, configure --data-ciphers-fallback");
      return false;
    }
    if (!tls_poor_mans_ncp) {
      msg("Failed to negotiate, add cipher xxx to --data-ciphers");
      return false;
    }
  }

>          }
>          struct frame *frame_fragment = NULL;
>  #ifdef ENABLE_FRAGMENT
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index 9bda38b0..a1f65127 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -1777,7 +1777,7 @@ multi_client_connect_setenv(struct multi_context *m,
>   * - choosen cipher
>   * - peer id
>   */
> -static void
> +static bool
>  multi_client_set_protocol_options(struct context *c)
>  {
>  
> @@ -1807,8 +1807,11 @@ multi_client_set_protocol_options(struct context *c)
>      }
>  
>      /* Select cipher if client supports Negotiable Crypto Parameters */
> -    if (o->ncp_enabled)
> +    if (!o->ncp_enabled)
>      {
> +        return true;
> +    }
> +

Hm, in this case I don't think this improves things. This turns

  if (foo) {
    do_foo_stuff;
  }
  if (bar) {
    do_bar_stuff;
  }

into

  if (foo) {
    do_foo_stuff;
  }
  if (!bar) {
    return;
  }
  do_bar_stuff;

I think the orignal code flow is easier to understand. If there's too
much indentation for you liking, you can split part of it into a
separate function.

(This is just about this first if, I totally agree about the flow change
below.)

>      /* if we have already created our key, we cannot *change* our own
>       * cipher -> so log the fact and push the "what we have now" cipher
>       * (so the client is always told what we expect it to use)
> @@ -1820,43 +1823,69 @@ multi_client_set_protocol_options(struct context *c)
>               "server has already generated data channel keys, "
>               "re-sending previously negotiated cipher '%s'",
>               o->ciphername );
> +        return true;
>      }
> -        else
> -        {
> +
>      /*
>       * Push the first cipher from --data-ciphers to the client that
>       * the client announces to be supporting.
>       */
> -            char *push_cipher = ncp_get_best_cipher(o->ncp_ciphers, o->ciphername,
> -                                                    peer_info,
> +    char *push_cipher = ncp_get_best_cipher(o->ncp_ciphers, peer_info,
>                                              tls_multi->remote_ciphername,
>                                              &o->gc);
>  
>      if (push_cipher)
>      {
>          o->ciphername = push_cipher;
> +        return true;
>      }
> -            else
> -            {
> +
> +    /* NCP cipher negotiation failed. Try to figure out why exactly it
> +     * failed and give good error messages and potentially do a fallback
> +     * for non NCP clients */
>      struct gc_arena gc = gc_new();
> +    bool ret = false;
> +
>      const char *peer_ciphers = tls_peer_ncp_list(peer_info, &gc);
> +    /* If we are in a situation where we know the client ciphers, there is no
> +     * reason to fall back to a cipher that will not be accepted by the other
> +     * side, in this situation we fail the auth*/
>      if (strlen(peer_ciphers) > 0)
>      {
> -                    msg(M_INFO, "PUSH: No common cipher between server and "
> -                        "client. Expect this connection not to work. Server "
> -                        "data-ciphers: '%s', client supported ciphers '%s'",
> +        msg(M_INFO, "PUSH: No common cipher between server and client. "
> +            "Server data-ciphers: '%s', client supported ciphers '%s'",
>              o->ncp_ciphers, peer_ciphers);
>      }
> +    else if (tls_multi->remote_ciphername)
> +    {
> +        msg(M_INFO, "PUSH: No common cipher between server and client. "
> +            "Server data-ciphers: '%s', client supports cipher '%s'",
> +            o->ncp_ciphers, tls_multi->remote_ciphername);
> +    }
>      else
>      {
> -                    msg(M_INFO, "No NCP data received from peer, falling back "
> -                        "to --cipher '%s'. Peer reports in OCC --cipher '%s'",
> -                        o->ciphername, np(tls_multi->remote_ciphername));
> +        msg(M_INFO, "PUSH: No NCP or OCC cipher data received from peer.");
> +
> +        if (o->enable_ncp_fallback && !tls_multi->remote_ciphername)
> +        {
> +            msg(M_INFO, "Using data channel cipher '%s' since "
> +                "--data-ciphers-fallback is set.", o->ciphername);
> +            ret = true;
>          }
> -                gc_free(&gc);
> +        else
> +        {
> +            msg(M_INFO, "Use --data-ciphers-fallback with the cipher the "
> +                "client is using if you want to allow the client to connect");
>          }
>      }
> +    if (!ret)
> +    {
> +        auth_set_client_reason(tls_multi, "Data channel cipher negotiation "
> +                                          "failed (no shared cipher)");
>      }
> +
> +    gc_free(&gc);
> +    return ret;
>  }
>  
>  /**
> @@ -2394,13 +2423,17 @@ multi_client_connect_late_setup(struct multi_context *m,
>      mi->context.c2.context_auth = CAS_SUCCEEDED;
>  
>      /* authentication complete, calculate dynamic client specific options */
> -    multi_client_set_protocol_options(&mi->context);
> -
> -    /* Generate data channel keys */
> -    if (!multi_client_generate_tls_keys(&mi->context))
> +    if (!multi_client_set_protocol_options(&mi->context))
>      {
>          mi->context.c2.context_auth = CAS_FAILED;
>      }
> +    /* Generate data channel keys only if setting protocol options
> +     * has not failed */
> +    else if (!multi_client_generate_tls_keys(&mi->context))
> +    {
> +
> +        mi->context.c2.context_auth = CAS_FAILED;
> +    }
>  
>      /* send push reply if ready */
>      if (mi->context.c2.push_request_received)
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 6d7dbf9f..5beaba0f 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -855,7 +855,6 @@ init_options(struct options *o, const bool init_gc)
>  #if P2MP
>      o->scheduled_exit_interval = 5;
>  #endif
> -    o->ciphername = "BF-CBC";
>      o->ncp_enabled = true;
>      o->ncp_ciphers = "AES-256-GCM:AES-128-GCM";
>      o->authname = "SHA1";
> @@ -3041,6 +3040,69 @@ options_postprocess_verify(const struct options *o)
>      }
>  }
>  
> +static void
> +options_postprocess_cipher(struct options *o)
> +{
> +    if (!o->pull && !(o->mode == MODE_SERVER))
> +    {
> +        /* we are in the classic P2P mode */
> +        /* cipher negotiation (NCP) currently assumes --pull or --mode server */
> +        o->ncp_enabled = false;
> +        msg( M_WARN, "Dynamic cipher negioation is disabled since neither "

Typo: negoatiation. Also "dynamic" seems redundant, "negotiation"
already implies that.

As a side note: this warning message should be good enough for devs too,
so we probably don't need the comments above that say the same.

> +             "P2MP client nor server mode is enabled" );

Was already in the orignal code, but: no space needed after msg(.

> +        /* If the cipher is not set default to BF-CBC, we will warn that this
> +         * is deprecated on cipher initialisation, no need to warn here as
> +         * well */

I had to read this twice to understand meaning. Maybe something like "if
the cipher is not set, we set it to the old default value 'BF-CBC'." or so?

> +        if (!o->ciphername)
> +        {
> +            o->ciphername = "BF-CBC";
> +        }
> +        return;
> +    }
> +
> +    /* M2P mode */

I think this is "P2MP mode"?

> +    if (!o->ciphername)
> +    {
> +        msg(M_WARN, "--cipher is not set. Previous OpenVPN version defaulted to "
> +            "BF-CBC as fallback when dynamic cipher negotiation failed "
> +            " in this case. If you need this fallback please "
> +            "add '--data-ciphers-fallback BF-CBC' to your configuration "
> +            "and/or add BF-CBC to --data-ciphers");
> +
> +        /* We still need to set the ciphername to BF-CBC since various other
> +         * parts of OpenVPN assert that the ciphername is set */
> +        o->ciphername = "BF-CBC";
> +
> +        if (!o->ncp_enabled)
> +        {
> +            msg(M_USAGE, "--ncp-disable needs an explicit --cipher or "
> +                "--data-ciphers-fallback config option");
> +        }
> +    }
> +    else if (!o->enable_ncp_fallback
> +             && !tls_item_in_cipher_list(o->ciphername, o->ncp_ciphers))
> +    {
> +        msg(M_WARN, "DEPRECATED OPTION: --cipher set to '%s' but missing in"
> +            " --ncp-ciphers (%s). Future OpenVPN version will "
> +            "ignore --cipher for dynamic cipher negotiations. "
> +            "Add '%s' to --data-ciphers or change --cipher '%s' to "
> +            "--data-ciphers-fallback '%s' to silence this warning.",
> +            o->ciphername, o->ncp_ciphers, o->ciphername,
> +            o->ciphername, o->ciphername);
> +        o->enable_ncp_fallback = true;
> +
> +        /* Append the --cipher to ncp_ciphers to allow it in NCP */
> +        char *ncp_ciphers = gc_malloc(strlen(o->ncp_ciphers)
> +                                      +strlen(o->ciphername) + 1, false, &o->gc);
> +
> +        strcpy(ncp_ciphers, o->ncp_ciphers);
> +        strcat(ncp_ciphers, ":");
> +        strcat(ncp_ciphers, o->ciphername);

Can we please avoid using strcpy and strcat? Using openvpn_snprintf()
should result in simpler code, and makes it easier to ensure that we
won't overflow.

Actually, looks like this already overflows, since there is no space for
the null-byte in ncp_ciphers.

> +        o->ncp_ciphers = ncp_ciphers;
> +    }
> +}
> +
>  static void
>  options_postprocess_mutate(struct options *o)
>  {
> @@ -3053,6 +3115,7 @@ options_postprocess_mutate(struct options *o)
>      helper_keepalive(o);
>      helper_tcp_nodelay(o);
>  
> +    options_postprocess_cipher(o);
>      options_postprocess_mutate_invariant(o);
>  
>      if (o->ncp_enabled)
> @@ -3113,16 +3176,6 @@ options_postprocess_mutate(struct options *o)
>              "include this in your server configuration");
>          o->dh_file = NULL;
>      }
> -
> -    /* cipher negotiation (NCP) currently assumes --pull or --mode server */
> -    if (o->ncp_enabled
> -        && !(o->pull || o->mode == MODE_SERVER) )
> -    {
> -        msg( M_WARN, "disabling NCP mode (--ncp-disable) because not "
> -             "in P2MP client or server mode" );
> -        o->ncp_enabled = false;
> -    }
> -
>  #if ENABLE_MANAGEMENT
>      if (o->http_proxy_override)
>      {
> @@ -3658,14 +3711,22 @@ options_string(const struct options *o,
>       */
>  
>      buf_printf(&out, ",dev-type %s", dev_type_string(o->dev, o->dev_type));
> -    buf_printf(&out, ",link-mtu %u", (unsigned int) calc_options_string_link_mtu(o, frame));
> +    if (o->ciphername)
> +    {
> +        /* the link-mtu that we send has only a meaning if have a fixed
> +         * cipher (p2p) or have a fallback cipher for older non ncp
> +         * clients. If we do have a fallback cipher, do not send it */

This confuses me. The code reads like it's dependent on --cipher, rather
than --fallbck-cipher. Also shouldn't this be "If we *don't* have a
fallback cipher"?

> +        buf_printf(&out, ",link-mtu %u",
> +                   (unsigned int) calc_options_string_link_mtu(o, frame));
> +    }
>      buf_printf(&out, ",tun-mtu %d", PAYLOAD_SIZE(frame));
>      buf_printf(&out, ",proto %s",  proto_remote(o->ce.proto, remote));
>  
> +    bool p2p_nopull = o->mode == MODE_POINT_TO_POINT && !PULL_DEFINED(o);
>      /* send tun_ipv6 only in peer2peer mode - in client/server mode, it
>       * is usually pushed by the server, triggering a non-helpful warning
>       */
> -    if (o->ifconfig_ipv6_local && o->mode == MODE_POINT_TO_POINT && !PULL_DEFINED(o))
> +    if (o->ifconfig_ipv6_local && p2p_nopull)
>      {
>          buf_printf(&out, ",tun-ipv6");
>      }
> @@ -3695,7 +3756,7 @@ options_string(const struct options *o,
>          }
>      }
>  
> -    if (tt && o->mode == MODE_POINT_TO_POINT && !PULL_DEFINED(o))
> +    if (tt && p2p_nopull)
>      {
>          const char *ios = ifconfig_options_string(tt, remote, o->ifconfig_nowarn, gc);
>          if (ios && strlen(ios))
> @@ -3751,8 +3812,15 @@ options_string(const struct options *o,
>  
>          init_key_type(&kt, o->ciphername, o->authname, o->keysize, true,
>                        false);
> -
> -        buf_printf(&out, ",cipher %s", cipher_kt_name(kt.cipher));
> +        /* Only announce the cipher to our peer if we are willing to
> +         * support it */
> +        const char *ciphername = cipher_kt_name(kt.cipher);
> +        if (p2p_nopull || !o->ncp_enabled
> +            || (o->ncp_enabled
> +                && tls_item_in_cipher_list(ciphername, o->ncp_ciphers)))

This second check for o->ncp_enabled is not needed. You already ensured
it's true before. (Saves you a line wrap.)

I wonder though, isn't it too soon to stop sending cipher? Looks like
both 2.3 and 2.4 clients will currently print options warnings if cipher
is missing from OCC. The earlier NCP versions carefully tries to send
what the peer expected here to prevent bogus warnings.

> +        {
> +            buf_printf(&out, ",cipher %s", ciphername);
> +        }
>          buf_printf(&out, ",auth %s", md_kt_name(kt.digest));
>          buf_printf(&out, ",keysize %d", kt.cipher_length * 8);
>          if (o->shared_secret_file)
> @@ -3870,7 +3938,8 @@ options_warning_safe_scan2(const int msglevel,
>          || strprefix(p1, "keydir ")
>          || strprefix(p1, "proto ")
>          || strprefix(p1, "tls-auth ")
> -        || strprefix(p1, "tun-ipv6"))
> +        || strprefix(p1, "tun-ipv6")
> +        || strprefix(p1, "cipher "))
>      {
>          return;
>      }
> @@ -7860,6 +7929,12 @@ add_option(struct options *options,
>          VERIFY_PERMISSION(OPT_P_NCP|OPT_P_INSTANCE);
>          options->ciphername = p[1];
>      }
> +    else if (streq(p[0], "data-ciphers-fallback") && p[1] && !p[2])
> +    {
> +        VERIFY_PERMISSION(OPT_P_INSTANCE);
> +        options->ciphername = p[1];
> +        options->enable_ncp_fallback = true;
> +    }
>      else if ((streq(p[0], "data-ciphers") || streq(p[0], "ncp-ciphers"))
>              && p[1] && !p[2])
>      {
> diff --git a/src/openvpn/options.h b/src/openvpn/options.h
> index c5df2d18..877e9396 100644
> --- a/src/openvpn/options.h
> +++ b/src/openvpn/options.h
> @@ -503,6 +503,8 @@ struct options
>      bool shared_secret_file_inline;
>      int key_direction;
>      const char *ciphername;
> +    bool enable_ncp_fallback;      /**< If defined fall back to
> +                                    * ciphername if NCP fails */
>      bool ncp_enabled;
>      const char *ncp_ciphers;
>      const char *authname;
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 91ab3bf6..06dc9f8f 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -1932,13 +1932,14 @@ tls_session_update_crypto_params(struct tls_session *session,
>          return true;
>      }
>  
> -    if (!session->opt->server
> -        && 0 != strcmp(options->ciphername, session->opt->config_ciphername)
> +    bool cipher_allowed_as_fallback = options->enable_ncp_fallback
> +                                      && streq(options->ciphername, session->opt->config_ciphername);
> +
> +    if (!session->opt->server && !cipher_allowed_as_fallback
>          && !tls_item_in_cipher_list(options->ciphername, options->ncp_ciphers))
>      {
> -        msg(D_TLS_ERRORS, "Error: pushed cipher not allowed - %s not in %s or %s",
> -            options->ciphername, session->opt->config_ciphername,
> -            options->ncp_ciphers);
> +        msg(D_TLS_ERRORS, "Error: pushed cipher not allowed - %s not in %s",
> +            options->ciphername, options->ncp_ciphers);
>          /* undo cipher push, abort connection setup */
>          options->ciphername = session->opt->config_ciphername;
>          return false;
> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
> index 8e432fb7..528b31ea 100644
> --- a/src/openvpn/ssl_ncp.c
> +++ b/src/openvpn/ssl_ncp.c
> @@ -211,9 +211,8 @@ tls_peer_ncp_list(const char *peer_info, struct gc_arena *gc)
>  }
>  
>  char *
> -ncp_get_best_cipher(const char *server_list, const char *server_cipher,
> -                    const char *peer_info,  const char *remote_cipher,
> -                    struct gc_arena *gc)
> +ncp_get_best_cipher(const char *server_list, const char *peer_info,
> +                    const char *remote_cipher, struct gc_arena *gc)
>  {
>      /*
>       * The gc of the parameter is tied to the VPN session, create a
> @@ -242,15 +241,6 @@ ncp_get_best_cipher(const char *server_list, const char *server_cipher,
>              break;
>          }
>      }
> -    /* We have not found a common cipher, as a last resort check if the
> -     * server cipher can be used
> -     */
> -    if (token == NULL
> -        && (tls_item_in_cipher_list(server_cipher, peer_ncp_list)
> -            || streq(server_cipher, remote_cipher)))
> -    {
> -        token = server_cipher;
> -    }
>  
>      char *ret = NULL;
>      if (token != NULL)
> @@ -262,16 +252,18 @@ ncp_get_best_cipher(const char *server_list, const char *server_cipher,
>      return ret;
>  }
>  
> -void
> +bool
>  tls_poor_mans_ncp(struct options *o, const char *remote_ciphername)
>  {
> -    if (o->ncp_enabled && remote_ciphername
> +    if (remote_ciphername
>          && 0 != strcmp(o->ciphername, remote_ciphername))
>      {
>          if (tls_item_in_cipher_list(remote_ciphername, o->ncp_ciphers))
>          {
>              o->ciphername = string_alloc(remote_ciphername, &o->gc);
>              msg(D_TLS_DEBUG_LOW, "Using peer cipher '%s'", o->ciphername);
> +            return true;
>          }
>      }
> +    return false;
>  }
> diff --git a/src/openvpn/ssl_ncp.h b/src/openvpn/ssl_ncp.h
> index d00c222d..98f80286 100644
> --- a/src/openvpn/ssl_ncp.h
> +++ b/src/openvpn/ssl_ncp.h
> @@ -44,10 +44,13 @@ tls_peer_supports_ncp(const char *peer_info);
>   * "Poor man's NCP": Use peer cipher if it is an allowed (NCP) cipher.
>   * Allows non-NCP peers to upgrade their cipher individually.
>   *
> + * Returns true if we switched to the peer's cipher
> + *
>   * Make sure to call tls_session_update_crypto_params() after calling this
>   * function.
>   */
> -void tls_poor_mans_ncp(struct options *o, const char *remote_ciphername);
> +bool
> +tls_poor_mans_ncp(struct options *o, const char *remote_ciphername);

I think we almost always put the return type on the same line in header
files. (Don't know why, but it seems quite consistent.)
-Steffan

#
2 года назад

(отредактировано

1 год, 12 месяцев назад)

Сообщения:

231

Участник с: 30 августа 2016

Есть личный впн сервер «в подвале». Все работало почти год без проблем. ВПН используется только для доступа к локальной сети сервера. Всего подключено 4 андроида, 2 ПК и ноут. В начале года обновил арч на сервере и на компах (везде версия OpenVPN 2.5.0).

На днях заметил, что на ноуте начало глючить соединение с впн сервером. Примерно каждые 2 минуты пропадает связь примерно на минуту, потом само восстанавливается. Если запустить пинг, то через 500-700 пингов, идет простой, после восстановления связи пинг продолжается.

Интернет при этом продолжает работать без сбоев. Тестил через три интернета: проводной местный провайдер, раздача с мобилы и вайфай на работе.

В логах сервера ничего странного нет:
/var/log/openvpn.log

DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Could not determine IPv4/IPv6 protocol. Using AF_INET

/var/log/openvpn-status.log

TITLE,OpenVPN 2.4.9 [git:makepkg/9b0dafca6c50b8bb+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 20 2020
TIME,Tue Jan 12 12:08:48 2021,1610442528
HEADER,CLIENT_LIST,Common Name,Real Address,Virtual Address,Virtual IPv6 Address,Bytes Received,Bytes Sent,Connected Since,Connected Since (time_t),Username,Client ID,Peer ID
CLIENT_LIST,alina-pc,85.140.6.219:56527,10.8.0.18,,90915,98585,Tue Jan 12 08:24:46 2021,1610429086,UNDEF,2170,2
CLIENT_LIST,like-pc,85.140.6.219:49920,10.8.0.14,,6900399,27892775,Tue Jan 12 08:15:29 2021,1610428529,UNDEF,2169,1
HEADER,ROUTING_TABLE,Virtual Address,Common Name,Real Address,Last Ref,Last Ref (time_t)
ROUTING_TABLE,10.8.0.14,like-pc,85.140.6.219:49920,Tue Jan 12 12:08:28 2021,1610442508
ROUTING_TABLE,10.8.0.18,alina-pc,85.140.6.219:56527,Tue Jan 12 12:04:55 2021,1610442295
GLOBAL_STATS,Max bcast/mcast queue length,5
END

systemctl status [email protected]

[email protected] - OpenVPN service for server
     Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled)
     Active: active (running) since Tue 2021-01-12 12:09:20 MSK; 21h ago
       Docs: man:openvpn(8)
             https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
             https://community.openvpn.net/openvpn/wiki/HOWTO
   Main PID: 472290 (openvpn)
     Status: "Initialization Sequence Completed"
      Tasks: 1 (limit: 19069)
     Memory: 2.3M
     CGroup: /system.slice/system-openvpnx2dserver.slice/[email protected]
             └─472290 /usr/bin/openvpn --status /run/openvpn-server/status-server.log --status-version 2 --suppress-timestamps --config server.conf

янв 12 12:09:20 b12srv systemd[1]: Starting OpenVPN service for server...
янв 12 12:09:20 b12srv systemd[1]: Started OpenVPN service for server.

На двух ПК и андроидах перебоев нет. На ноуте и ПК арч почти идентичен.

В чем может быть проблема? Что проверить?

kurych

#
2 года назад

Темы:

0

Участник с: 06 ноября 2011

Если проблема наблюдается только с подключением ноута, то и проблему, очевидно, надо искать на ноуте. Логи, dmesg…

abc

#
2 года назад

Сообщения:

231

Участник с: 30 августа 2016

kurych
Логи, dmesg

На ноутбуке при запуске впн соединения в статусе:
systemctl status [email protected]

● [email protected] - OpenVPN tunnel for laptop
     Loaded: loaded (/usr/lib/systemd/system/[email protected]; enabled; vendor preset: disabled)
     Active: active (running) since Tue 2021-01-12 13:23:23 MSK; 22h ago
...
янв 13 11:44:19 archlinux openvpn[1634]: OPTIONS IMPORT: --ifconfig/up options modified
янв 13 11:44:19 archlinux openvpn[1634]: OPTIONS IMPORT: route options modified
янв 13 11:44:19 archlinux openvpn[1634]: OPTIONS IMPORT: peer-id set
янв 13 11:44:19 archlinux openvpn[1634]: OPTIONS IMPORT: adjusting link_mtu to 1624
янв 13 11:44:19 archlinux openvpn[1634]: OPTIONS IMPORT: data channel crypto options modified
янв 13 11:44:19 archlinux openvpn[1634]: Data Channel: using negotiated cipher 'AES-256-GCM'
янв 13 11:44:19 archlinux openvpn[1634]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
янв 13 11:44:19 archlinux openvpn[1634]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
янв 13 11:44:19 archlinux openvpn[1634]: Preserving previous TUN/TAP instance: tun0
янв 13 11:44:19 archlinux openvpn[1634]: Initialization Sequence Completed

Во время потери связи в статусе через некоторое время добавляется:

янв 13 11:53:58 archlinux openvpn[1634]: [b12] Inactivity timeout (--ping-restart), restarting
янв 13 11:53:58 archlinux openvpn[1634]: SIGUSR1[soft,ping-restart] received, process restarting
янв 13 11:53:58 archlinux openvpn[1634]: Restart pause, 5 second(s)

То есть как и при пинге, сервер перестает пинговаться. Потом происходит переподключение.

В dmesg в это время нечего не появляется. journalctl показывает то же самое, что и листинг выше.

На сервере в конфиге впн пробовал менять параметр keepalive. Было 10 120, ставил 5-30 30-300 (первая цифра период пингования в сек, вторая цифра время на ответ на пинг)

Других логов у меня нет или я не знаю, что еще смотреть.

abc

#
2 года назад

Сообщения:

231

Участник с: 30 августа 2016

Если со стандартным значением keepalive 10 120 остальные клиенты работают без потери связи, то проблема точно не на сервере. Конфиги на всех ПК одинаковые, за исключением ключей/сертификатов. Сейчас я на работе. ПК с утра пинговал впн сервер три часа без потери пакетов. Проблема точно в ноутбуке.

Holden

#
2 года назад

Сообщения:

155

Участник с: 29 октября 2020

abc

Если у Вас версия OpenVPN 2.5.0 , то самым быстрым решением будет откат до 2.4.0.

/var/log/openvpn.log
DEPRECATED OPTION: –cipher set to ‘AES-256-CBC’ but missing in –data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore –cipher for cipher negotiations……

Или загуглите по вышеприведенному фрагменту Вашего лога.

abc

#
2 года назад

Сообщения:

231

Участник с: 30 августа 2016

Holden
DEPRECATED OPTION: –cipher set to ‘AES-256-CBC’ but missing in –data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore –cipher for cipher negotiations

Исправил.

Holden
откат до 2.4.0.

Нашел 2.4.8. Так же разрывает соединение.

Holden

#
2 года назад

Сообщения:

155

Участник с: 29 октября 2020

abc

Вы попробуйте отсюда начать. Первая ссылка которую startpage мне открыл. Проблемы с ключами шифрования. Мне просто не на чем попробовать у себя, вообще, я всегда под ВПН, но у меня сейчас не дедик. Просто купил годовую подписку и все.

vasek

#
2 года назад

(отредактировано

2 года назад)

Участник с: 17 февраля 2013

Holden
Проблемы с ключами шифрования

Вряд ли проблема связана с шифрованием, проблема в другом.
Его система понимает устаревший шифр AES-256-CBC, иначе бы не было соединения вообще (скорее всего используется TLS 1.2, который понимает более 30 шифров, в том числе и AES-256-CBC).

Ошибки не исчезают с опытом — они просто умнеют

abc

#
2 года назад

Сообщения:

231

Участник с: 30 августа 2016

Все само починилось, я ничего не нажимал. На днях из-за метели свет вырубили. После включения сервера проблема исчезла. За неделю-две до начала проблем обновлял сервер. Видимо требовался ребут.