I get this same error over and over again when trying to connect with multiple profiles. Any assistance would be great.
2020-11-13 16:05:38 OPTIONS ERROR: failed to negotiate cipher with server. Configure —data-ciphers-fallback if you want to connect to this server.
2020-11-13 16:05:38 ERROR: Failed to apply push options
2020-11-13 16:05:38 Failed to open tun/tap interface
2020-11-13 16:05:38 SIGUSR1[soft,process-push-msg-failed] received, process restarting
2020-11-13 16:05:38 Restart pause, 5 second(s)
Hi,
On Fri, Nov 13, 2020 at 01:31:08PM -0800, mcrite wrote:
I get this same error over and over again when trying to connect with multiple profiles. Any assistance would be great.
2020-11-13 16:05:38 OPTIONS ERROR: failed to negotiate cipher with server. Configure —data-ciphers-fallback if you want to connect to this server.
2020-11-13 16:05:38 ERROR: Failed to apply push options
2020-11-13 16:05:38 Failed to open tun/tap interface
2020-11-13 16:05:38 SIGUSR1[soft,process-push-msg-failed] received, process restarting
2020-11-13 16:05:38 Restart pause, 5 second(s)
This is not an openvpn-gui bug, it’s just a misconfiguration of the
client or server.
Questions like this are better suited for the openvn-users list or the
openvpn community forum (https://forums.openvpn.net). Include a log
file with «verb 3» so we can see the client version (looks like 2.5.0)
and what options the server pushed.
If connecting to a commercial VPN service, this is a question their
support needs to answer (many of those providers modify openvpn,
some in incompatible ways).
gert
…
—
«If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor.»
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering — Munich, Germany gert@greenie.muc.de
Sat Feb 27 17:04:47 2021 SENT CONTROL [ALIYUN-server]: ‘PUSH_REQUEST’ (status=1)
Sat Feb 27 17:04:47 2021 PUSH: Received control message: ‘PUSH_REPLY,route 10.19.0.0 255.255.0.0,topology net30,ping 10,ping-restart 120,ifconfig 10.19.0.30 10.19.0.29’
Sat Feb 27 17:04:47 2021 OPTIONS IMPORT: timers and/or timeouts modified
Sat Feb 27 17:04:47 2021 OPTIONS IMPORT: —ifconfig/up options modified
Sat Feb 27 17:04:47 2021 OPTIONS IMPORT: route options modified
Sat Feb 27 17:04:47 2021 OPTIONS ERROR: failed to negotiate cipher with server. Add the server’s cipher (‘BF-CBC’) to —data-ciphers (currently ‘AES-256-GCM:AES-128-GCM’) if you want to connect to this server.
Sat Feb 27 17:04:47 2021 ERROR: Failed to apply push options
Sat Feb 27 17:04:47 2021 Failed to open tun/tap interface
Sat Feb 27 17:04:47 2021 SIGUSR1[soft,process-push-msg-failed] received, process restarting
Sat Feb 27 17:04:47 2021 MANAGEMENT: >STATE:1614416687,RECONNECTING,process-push-msg-failed,,,,,
Sat Feb 27 17:04:47 2021 Restart pause, 160 second(s)
Hi,
On Sat, Feb 27, 2021 at 01:05:24AM -0800, bjhdtv wrote:
Sat Feb 27 17:04:47 2021 OPTIONS ERROR: failed to negotiate cipher with server. Add the server’s cipher (‘BF-CBC’) to —data-ciphers (currently ‘AES-256-GCM:AES-128-GCM’) if you want to connect to this server.
This. Do what it tells you.
(*Or* upgrade the server to something less ancient — with 2.4 and up on
the server, you get AES-GCM ciphers, which are more performant *and* more
secure)
gert
—
«If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor.»
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering — Munich, Germany gert@greenie.muc.de
Which file should I add ‘BF-CBC’ to?I cannot find the file which has -data-ciphers (currently ‘AES-256-GCM:AES-128-GCM’) .
Best Regard!
The option goes to the config file. The log is reporting the default values so you may not have any --data-ciphers
line present. That said, if you are managing the server, change the server config to support AES-256-GCM, if not, ask the server administrator for a proper config file that works with the server.
Continuing to use a weak cipher like BF-CBC should be avoided.
I get this same error over and over again when trying to connect with multiple profiles. Any assistance would be great.
2020-11-13 16:05:38 OPTIONS ERROR: failed to negotiate cipher with server. Configure —data-ciphers-fallback if you want to connect to this server.
2020-11-13 16:05:38 ERROR: Failed to apply push options
2020-11-13 16:05:38 Failed to open tun/tap interface
2020-11-13 16:05:38 SIGUSR1[soft,process-push-msg-failed] received, process restarting
2020-11-13 16:05:38 Restart pause, 5 second(s)
for this Error
#[(ERROR: failed to negotiate cipher with server. Add the server’s cipher (‘BF-CBC’) to —data-ciphers (currently ‘AES-256-GCM:AES-128-GCM’) if you want to connect to this server.)]
ncp-ciphers «BF-CBC»
https://www.lifechangediary.com/solve-failed-negotiate-cipher-openvpn/
Hi,
On Mon, Jun 07, 2021 at 06:39:22AM -0700, Liang wrote:
> I get this same error over and over again when trying to connect with multiple profiles. Any assistance would be great.
>
> 2020-11-13 16:05:38 OPTIONS ERROR: failed to negotiate cipher with server. Configure —data-ciphers-fallback if you want to connect to this server.
> 2020-11-13 16:05:38 ERROR: Failed to apply push options
> 2020-11-13 16:05:38 Failed to open tun/tap interface
> 2020-11-13 16:05:38 SIGUSR1[soft,process-push-msg-failed] received, process restarting
> 2020-11-13 16:05:38 Restart pause, 5 second(s)
# for this Error
#[(ERROR: failed to negotiate cipher with server. Add the server’s cipher (‘BF-CBC’) to —data-ciphers (currently ‘AES-256-GCM:AES-128-GCM’) if you want to connect to this server.)]
ncp-ciphers «BF-CBC»
OpenVPN-GUI github is not the place to handle openvpn config questions.
That said: just do what it tells you. Add «BF-CBC» to «data-ciphers», as
in «put the following into your config»:
data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC
(and then upgrade the server to something which is not 10 years old)
gert
—
«If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor.»
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering — Munich, Germany ***@***.***
add the following config to your openvpn configruation file:
rafgugi and Phobos-7 reacted with thumbs down emoji
pengzai530 reacted with laugh emoji
I get this same error over and over again when trying to connect with multiple profiles. Any assistance would be great.
2020-11-13 16:05:38 OPTIONS ERROR: failed to negotiate cipher with server. Configure —data-ciphers-fallback if you want to connect to this server. 2020-11-13 16:05:38 ERROR: Failed to apply push options 2020-11-13 16:05:38 Failed to open tun/tap interface 2020-11-13 16:05:38 SIGUSR1[soft,process-push-msg-failed] received, process restarting 2020-11-13 16:05:38 Restart pause, 5 second(s)
I think yo have to upgrade your openvpn server package to the latest repository.
For example: If you get an error with openvpn on your debian 8 like yours, you have to uninstall with purge option on your old openvpn. After that, insert the debian 9’s repository or latest, then update and install without change the config. So, don’t forget to copy all files inside the /etc/openvpn directory before you uninstall the old openvpn then paste it into same directory in new openvpn.
It’s work for me. Greetings from Indonesia
Note that what @yunnysunny says works with 2.5 but will also stop working with 2.6 as —cipher is deprecated.
add the following config to your openvpn configruation file:
thanks it’s useful for me , thank you very much !
if someone have this problem, pls add cipher BF-CBC to your file «xxxx.ovpn»
Hi,
On Thu, Dec 02, 2021 at 03:18:29AM -0800, huangjiayegithub wrote:
if someone have this problem, pls add cipher BF-CBC to your file «xxxx.ovpn»
This is actually bad advice, as it will stop working in 2.6
-> if you have this problem, do what was stated before
— upgrade the server to 2.4 or higher (2.3 is ANCIENT)
— if that is not possible, add BF-CBC to the list in —data-ciphers,
in your config (or add that line), as in
data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC
gert
—
«If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor.»
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering — Munich, Germany ***@***.***
Hi,
On Thu, Dec 02, 2021 at 03:18:29AM -0800, huangjiayegithub wrote: if someone have this problem, pls add cipher BF-CBC to your file «xxxx.ovpn»
This is actually bad advice, as it will stop working in 2.6 -> if you have this problem, do what was stated before — upgrade the server to 2.4 or higher (2.3 is ANCIENT) — if that is not possible, add BF-CBC to the list in —data-ciphers, in your config (or add that line), as in data-ciphers AES-256-GCM:AES-128-GCM:BF-CBC gert — «If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor.» Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering — Munich, Germany @.***
where should i finf config file in kali . /etc/openvpn ?
there are only two directories and one .conf file .. nothing much
The cipher is not added correctly or something, so I had to modify the .ovpn file manually, if you open the file you’ll see
cipher AES-256-CBC
just change it to —
data-ciphers AES-256-CBC
yincii, dbarasti, and vladsovetov reacted with hooray emoji
Thank you. It works for me.
Unfortunately, «put the following into your config» isn’t enough to resolve this, so following «Questions like this are better suited for the openvn-users list or the openvpn community forum» I’ve asked at https://forums.openvpn.net/viewtopic.php?t=35283 .
(mentioning here just to link the two issues together)
«put the following into your config» means, open the config file and add the suggested line to it.
If the config is in the user’s profile, you can do this from the GUI by clicking the menu item named Edit config
shown against each connection entry in the menu. Choose the connection for which you want to make the changes, click Edit config
and wait for the config file to open up in a notepad window. Make the change and save it (i.e overwrite the file).
If the config is in the global config directory, or if not sure, try the same as above. If saving succeeds, you are done. Otherwise you will get a permission denied error while trying to save the file. If that happens, note down the location of the file listed in the error message that pops up, and edit it directly with admin privileges.
Note: Instead of «adding» you can also replace the corresponding option line if it already exists in the file — in this case that would be the line starting data-ciphers
. If it doesn’t exist, just add the line at the bottom of the file.
The cipher is not added correctly or something, so I had to modify the .ovpn file manually, if you open the file you’ll see
cipher AES-256-CBC
just change it to —
data-ciphers AES-256-CBC
goodBoy,it’s useful
-
rahalsam
- OpenVpn Newbie
- Posts: 5
- Joined: Mon Jul 05, 2021 5:00 pm
[Solved]openvpn fedora
Hello
I encountered a problem with my openvpn connection on fedora 34, OpenVPN 2.5.3
journalctl -u NetworkManager —no-pager —since today
Jul 05 18:02:36 fedora nm-openvpn[6846]: OPTIONS ERROR: failed to negotiate cipher with server. Add the server’s cipher (‘BF-CBC’) to —data-ciphers (currently ‘AES-256-GCM:AES-128-GCM’) if you want to connect to this server.
Jul 05 18:02:36 fedora nm-openvpn[6846]: ERROR: Failed to apply push options
Jul 05 18:02:36 fedora nm-openvpn[6846]: Failed to open tun/tap interface
My config file/usr/lib/systemd/system/openvpn-server@.service
Description=OpenVPN service for %I
After=syslog.target network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/w … n24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO
[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn/server
ExecStart=/usr/sbin/openvpn —status %t/openvpn-server/status-%i.log —status-version 2 —suppress-timestamps —cipher AES-256-GCM —data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC —config %i.conf
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUDIT_WRITE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
KillMode=process
RestartSec=5s
Restart=on-failure
[Install]
WantedBy=multi-user.target
thanks for help
Last edited by rahalsam on Mon Jul 05, 2021 6:09 pm, edited 1 time in total.
-
TinCanTech
- OpenVPN Protagonist
- Posts: 11142
- Joined: Fri Jun 03, 2016 1:17 pm
Re: openvpn fedora
Post
by TinCanTech » Mon Jul 05, 2021 5:25 pm
The answer is staring you in your face ..
-
rahalsam
- OpenVpn Newbie
- Posts: 5
- Joined: Mon Jul 05, 2021 5:00 pm
Re: openvpn fedora
Post
by rahalsam » Mon Jul 05, 2021 5:39 pm
TinCanTech wrote: ↑
Mon Jul 05, 2021 5:25 pm
The answer is staring you in your face ..
Are you talking about that
Add the server’s cipher (‘BF-CBC’) to —data-ciphers
In My file configuration I have : -data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC —config %i.conf and the problem persists
-
TinCanTech
- OpenVPN Protagonist
- Posts: 11142
- Joined: Fri Jun 03, 2016 1:17 pm
Re: [Solved]openvpn fedora
Post
by TinCanTech » Mon Jul 05, 2021 6:43 pm
If the problem persists then why did you add [Solved] to your Subject ?
-
rahalsam
- OpenVpn Newbie
- Posts: 5
- Joined: Mon Jul 05, 2021 5:00 pm
Re: [Solved]openvpn fedora
Post
by rahalsam » Mon Jul 05, 2021 8:37 pm
TinCanTech wrote: ↑
Mon Jul 05, 2021 6:43 pm
If the problem persists then why did you add [Solved] to your Subject ?
I found the solution
‘sudo openvpn —data-ciphers BF-CBC —config file.ovpn or change cipher to BF-CBC in GUI mode
thanks for all
-
openvpn_inc
- OpenVPN Inc.
- Posts: 1137
- Joined: Tue Feb 16, 2021 10:41 am
Re: [Solved]openvpn fedora
Post
by openvpn_inc » Tue Jul 06, 2021 11:15 am
Note that Blowfish (BF-CBC) was once the default, but is no longer recommended.
cheers, rob0
OpenVPN Inc.
Answers provided by OpenVPN Inc. staff members here are provided on a voluntary best-effort basis, and no rights can be claimed on the basis of answers posted in this public forum. If you wish to get official support from OpenVPN Inc. please use the official support ticket system: https://openvpn.net/support
- Prev
- 1
- 2
- Next
- Page 1 of 2
Recommended Posts
Guest Roman
krisbowe
32
- Report post
Do you get the same error from a Kali VM connection via OpenVPN?
- Quote
Share this post
Link to post
Share on other sites
StefanWAustin
343
- Report post
You have to downgrade your openVPN software on Windows. Using Windows does not make much sense, you can use Windows for the first lab, that is it.
- Quote
Share this post
Link to post
Share on other sites
Guest Vitor
- Report post
I am also struggling with this problem, using Kali Linux. Tried to redownload VPN configuration file but it did not work. How can I downgrade my OpenVPN on kali to make it work?
- Quote
Share this post
Link to post
Share on other sites
StefanWAustin
343
- Report post
On kali, use:
sudo openvpn —data-ciphers BF-CBC —config yourlabfile.ovpn
Share this post
Link to post
Share on other sites
Guest Tim
- Report post
For people who connect from Windows. I found a version that works without BlowFish error. it is openvpn-install-2.4.9-I601-Win10.exe. It spent 30 minutes looking for work around, wasted my time and money because the lab deduct my time.
Link: https://build.openvpn.net/downloads/releases/openvpn-install-2.4.9-I601-Win10.exe
It is ridiculous the «Ask Support» button on member portal bring us to a forum instead of person who can help us, not even a service portal to log tickets………worst, this forum doesn’t have a section for MAP course.
- Quote
Share this post
Link to post
Share on other sites
StefanWAustin
343
- Report post
1 hour ago, Guest Tim said:
«Ask Support» button on member portal bring us to a forum instead of person who can help us,
You can use the chat on Facebook or Twitter. Alternatively you can write an email to the support support@elearnsecurity.com. If you write an email, you will get your time back.
- Quote
Share this post
Link to post
Share on other sites
skuggar
0
- Report post
I was getting ready to take a test and stumbled across this issue while trying to visit a lab to practice something. The command line Caesar posted above works fine, but if you edit the ovpn like below, you can still use it through the network manager gui.
- Quote
Share this post
Link to post
Share on other sites
Guest h8tingMS
- Report post
On 9/13/2020 at 6:56 AM, Guest Tim said:
For people who connect from Windows. I found a version that works without BlowFish error. it is openvpn-install-2.4.9-I601-Win10.exe. It spent 30 minutes looking for work around, wasted my time and money because the lab deduct my time.
Link: https://build.openvpn.net/downloads/releases/openvpn-install-2.4.9-I601-Win10.exe
It is ridiculous the «Ask Support» button on member portal bring us to a forum instead of person who can help us, not even a service portal to log tickets………worst, this forum doesn’t have a section for MAP course.
Thanks. Worked great and saved me a lot of time trouble shooting.
- Quote
Share this post
Link to post
Share on other sites
Guest Sankii99
- Report post
I had same problem in Ubuntu 21.04 and resolved by adding following line to the openvpn conf file
Quote
cipher BF-CBC
- Quote
Share this post
Link to post
Share on other sites
Guest Evg
- Report post
On 9/13/2020 at 1:56 PM, Guest Tim said:
For people who connect from Windows. I found a version that works without BlowFish error. it is openvpn-install-2.4.9-I601-Win10.exe. It spent 30 minutes looking for work around, wasted my time and money because the lab deduct my time.
Link: https://build.openvpn.net/downloads/releases/openvpn-install-2.4.9-I601-Win10.exe
It is ridiculous the «Ask Support» button on member portal bring us to a forum instead of person who can help us, not even a service portal to log tickets………worst, this forum doesn’t have a section for MAP course.
Thank you! It is work for me!
- Quote
Share this post
Link to post
Share on other sites
Guest Devin Jain
- Report post
Здравствуйте ув. Boss!
Предложу поднятие на 10-20 пунктов позиций в поисковиках.
Цена всего 400 ру. Качественный ИкС. Отчётность.
Прогоны сайтов от Профессионалов!
Хваленые БаЗы.
Контакты:
Telgrm: @exrumer
Skype: XRumer.pro
WhatsApp: +7(977)536-08-36
mail: support@xrumer.cc
- Quote
Share this post
Link to post
Share on other sites
Guest Davidsworp
- Report post
Share this post
Link to post
Share on other sites
Guest Rubenliz
Guest MichaelPep
Guest Juliusunono
Guest Willardfer
Guest Willardfer
Guest Rubenliz
Guest DonaldHok
- Report post
https://vk.com/rabota_kemer_ovo
- Quote
Share this post
Link to post
Share on other sites
Guest DonaldHok
- Report post
https://vk.com/rabota_kemer_ovo
- Quote
Share this post
Link to post
Share on other sites
Guest DonaldHok
- Report post
https://vk.com/rabota_kemer_ovo
- Quote
Share this post
Link to post
Share on other sites
Guest DonaldHok
- Report post
https://vk.com/rabota_kemer_ovo
- Quote
Share this post
Link to post
Share on other sites
Guest RonaldGlife
Guest RonaldGlife
- Prev
- 1
- 2
- Next
- Page 1 of 2
This topic has been deleted. Only users with topic management privileges can see it.
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.
08.01.21 — 19:49
Прошу помочь советом.
Стояло 6 лет win 8.1, но решил перейти на Win10 по ряду причин.
Все нормально, НО!
ОДНО из соединений OpenVPN перестало работать.
Итак.
Есть несколько настроенных соединений OpenVPN с расширением ovpn и последняя версия OpenVPN 64 битная.
Но из 3 соединений на разные сервера одно не работает. Причем не работает то, которое самое нужное.
Остальные 2 соединения на другие сервера — работают и на старой и на новой винде.
Ставил старый винт с win8.1, вычищал OpenVPN и все заново переставлял — все работает, как и работало.
А на новой,- что только не делал — и запуск под Администратором, и установку предыдущих версий и проч.
2 соединения работают, а это самое главное — нет.
Системные администраторы на работе из дома под собой проверили (у них win10) — работает нормально.
Прошу помочь советом — что делать и куда смотреть.
1 — 08.01.21 — 19:50
вот запись куска нормального журнала
Wed Jan 06 12:40:47 2021 OPTIONS IMPORT: timers and/or timeouts modified
Wed Jan 06 12:40:47 2021 OPTIONS IMPORT: —sndbuf/—rcvbuf options modified
Wed Jan 06 12:40:47 2021 Socket Buffers: R=[65536->524288] S=[65536->524288]
Wed Jan 06 12:40:47 2021 OPTIONS IMPORT: —ifconfig/up options modified
Wed Jan 06 12:40:47 2021 OPTIONS IMPORT: route options modified
Wed Jan 06 12:40:47 2021 OPTIONS IMPORT: —ip-win32 and/or —dhcp-option options modified
Wed Jan 06 12:40:47 2021 Outgoing Data Channel: Cipher ‘BF-CBC’ initialized with 128 bit key
Wed Jan 06 12:40:47 2021 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a —cipher with a larger block size (e.g. AES-256-CBC).
Wed Jan 06 12:40:47 2021 Outgoing Data Channel: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Wed Jan 06 12:40:47 2021 Incoming Data Channel: Cipher ‘BF-CBC’ initialized with 128 bit key
Wed Jan 06 12:40:47 2021 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a —cipher with a larger block size (e.g. AES-256-CBC).
Wed Jan 06 12:40:47 2021 Incoming Data Channel: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Wed Jan 06 12:40:47 2021 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Wed Jan 06 12:40:47 2021 interactive service msg_channel=412
2 — 08.01.21 — 19:51
вот куска соединения с ошибкой
2021-01-08 19:19:07 OPTIONS IMPORT: timers and/or timeouts modified
2021-01-08 19:19:07 OPTIONS IMPORT: —sndbuf/—rcvbuf options modified
2021-01-08 19:19:07 Socket Buffers: R=[65536->524288] S=[65536->524288]
2021-01-08 19:19:07 OPTIONS IMPORT: —ifconfig/up options modified
2021-01-08 19:19:07 OPTIONS IMPORT: route options modified
2021-01-08 19:19:07 OPTIONS IMPORT: —ip-win32 and/or —dhcp-option options modified
2021-01-08 19:19:07 OPTIONS ERROR: failed to negotiate cipher with server. Add the server’s cipher (‘BF-CBC’) to —data-ciphers (currently ‘AES-256-GCM:AES-128-GCM’) if you want to connect to this server.
2021-01-08 19:19:07 ERROR: Failed to apply push options
2021-01-08 19:19:07 Failed to open tun/tap interface
2021-01-08 19:19:07 SIGUSR1[soft,process-push-msg-failed] received, process restarting
2021-01-08 19:19:07 MANAGEMENT: >STATE:1610122747,RECONNECTING,process-push-msg-failed,,,,,
2021-01-08 19:19:07 Restart pause, 5 second(s)
3 — 08.01.21 — 19:51
Ошибка после
OPTIONS IMPORT: —ip-win32 and/or —dhcp-option options modified
Комп один и тот же.
4 — 08.01.21 — 20:00
failed to negotiate cipher with server. Add the server’s cipher (‘BF-CBC’)
5 — 08.01.21 — 20:19
нашел причину — на англоязычном сайте.
Последний инсталятор и другой который пользовал — не работают на win10.
сказали нужна версия 2.4.9 для win10.
поставил ее и все заработало
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
(8) >> потому что серый айпи
Сомнительно
10 — 09.01.21 — 00:45
(9) я хз сомнительно или нет. но заставить подключаться по штатному ВПН — не получилось. Порезfys пакеты у провайдера видимо. купил за 150р/месяц белый айпи — все стало мгновенно хорошо. и по штатному ВПН.
11 — 09.01.21 — 08:38
(7) ее блочат некоторые провайдеры. в забайкальском крае — ТТК, а там он очень популярен.
(5) да, в ней куча глюков, пришлось искать старую.
12 — 09.01.21 — 08:40
(10) к сожалению, не могу заставить бабушек покупать домой всякие белые айпи ((
13 — 09.01.21 — 08:50
(7) Стандартная vpn с имитацией диалапа — убога до невозможности.
14 — 09.01.21 — 08:57
(11) А я давно замечаю, что как только какое-то ПО вылижут до идеального состояния — сразу делается рефакторинг с нуля на каком-то новомодном тулките или среде разработке, и всё работать перестает нормально. Неоднократно такое замечал. Эффект шила в попе у разработчиков что ли такой..
15 — 09.01.21 — 09:00
(11) WireGuard работает по своему протоколу, на произвольном порту, русифицирован и конфиг можно юзеру по почте отправить. Я еще не донастроил, но вроде перспективно)
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) «а микротиковский впн блочит все, пока не отключишься.»
маршрутизацию надо поправить может быть. такое и на стандартном ВПН бывает — подключаешься — ВПН работает, а в инет — фиг. мне сисадмин маршрутизацию подстраивал в таком случае и все ок становилось.
19 — 09.01.21 — 16:08
(16) это не VPN блочит, это на клиентской машине надо разрулить маршруты, чтобы в подключение VPN ходил только тот трафик, который относится к локальной сети предприятия, куда ты подключаешься, а все остальное — в инет. В более-менее свежих виндах можно сделать просто, например, командлетом из повершелла:
Add-VpnConnectionRoute -ConnectionName «Ваш-VPN-интерфейс» -DestinationPrefix УдаленнаяПодсетьКудаКидатьПакеты
причем, если я правильно помню, будучи раз введенной, эта команда навсегда запомнится для данного подключения.
На более старых виндах можно делать командой route add, но это придется делать каждый раз при установке соединения.
20 — 09.01.21 — 16:10
если работаете иногда на андроидном телефоне/планшете через VPN, то там все еще проще. В стандартном VPN-клиенте есть поле ввода «Маршруты пересылки». Вот туда и прописываете подсеть локалки предприятия, с которой работаете. И вуаля — после того как загорится значок VPN в прямоугольнике, доступ в инет у дрюши не пропадет.
21 — 09.01.21 — 16:27
(19) там есть route -p . Но возможно микротик не учитывает дефаулт гейтвей, они же гордые, им подавай пряморуких
22 — 09.01.21 — 17:32
(19) Чтобы задать маршрут к удаленной сети через впн, не меняя шлюза по умолчанию, нужно указывать идентификатор сетевого интерфейса, а он при каждом подключении разный. Так что route -p не катит..
23 — 09.01.21 — 17:36
(5) Вопрос чисто из любопытства. Зачем тебе OpenVPN, если тебе пофиг на «INSECURE cipher»?
24 — 09.01.21 — 17:36
Начиная с windows 8,есть возможность указывать маршруты в привязке в сетевому соединению,тогда они будут включаться только при его установке.
Но,печальна ситуация,когда какая-то подсесть организации совпадает с подсетью провайдера.
25 — 09.01.21 — 19:16
(24) «Но,печальна ситуация,когда какая-то подсесть организации совпадает с подсетью провайдера.»
Скорее не с подсетью провайдера, а с подсетью клиента. У них от роутера часто 192.168.x и в организации та же. Провайдеры же обычно используют более экзотические серые подсети, 100 или 172.
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.
Более экзотические варианты встречаются,если кто-то прописывает вручную.
29 — 10.01.21 — 08:05
(17) так вот у меня как раз PPTP-то и не работает, я был бы рад его использовать. А удаленщицам кидаю только дистриб по почте, в котором все зашито, им надо только установить, ничего настраивать не надо, все прописано в конфиге. насчет того, что это макось на инглише — к ней хотя бы мануалы есть русские. для остального софта надо штудировать все на английском. сейчас посмотрел этот WireGuard — русского не нашел.
(18) в инете есть сотня советов и все они сводятся к одному — поменять маршрут, только вот для этого должно одно условие соблюдаться — подсети должны быть разные. а у меня они одинаковые. то есть и в офисе подсетка 192.168.1.1, и у большинства юзеров дома тоже 192.168.1.1. в офисе не вариант менять подсеть — там все айпи в оборудовании зашиты, на это год надо, чтобы все заменить, так как штатного сисадмина там нет. у домохозяек дома менять тоже не вариант, они, как правило, не знают пароля от роутера, да и ехать к ним не вариант, их много и они далеко. я надеялся настроить так, чтобы только 1-2 адреса открыть из офиса, грубо говоря, объединить сетки, но роутеры мне показывают хер. даже если я пытаюсь указать шлюз офиса, интернета все равно нет. самое интересное, что на роутере ASUS впн спокойно все объединял сам и я даже не думал, что эта проблема вообще возникнет. тут вроде есть толковые сисдамины, но они говорят — единственный способ — менять подсетку в офисе на другие адреса. не буду. мне за это не платят.
30 — 10.01.21 — 08:08
(19) у меня openvpn. куда эту вашу команду вводить? и да, у опенвпн есть аналогичная команда в конфиге, поверьте, я ее вводил и сотни ее вариаций, не получается. могу даже вам конфигу подключения скинуть, чтобы вы поэкспериментировали. факт остается, пптп я не могу юзать, хотя он мне сначала нравился
31 — 10.01.21 — 08:14
(21) где-то в роутере надо прописывать, чтобы он впновских юзеров пускал в инет. но мне туда сказали не лазить, разрешили только сервер опенвпн дали поднять. поэтому я ничего не могу проверить.
32 — 10.01.21 — 08:31
(13) Не используй имитацию диалапа.
33 — 10.01.21 — 08:32
(30) это в настройках отправляемых клиенту должно быть, что то про пуш роут афаир
34 — 10.01.21 — 08:40
(30) команду вводить на той машине, которая подключается к удаленной сети.
35 — 10.01.21 — 09:26
(32) Штатные впн в винде по другому не умеют
36 — 10.01.21 — 09:31
(27) Скорее, чтобы не пересечься со стандартной подсетью бытовых роутеров. А там в 99% случаев 192.168.x, так что выбор 100 или 172 серой сети наиболее логичен, некоторые провайдеры дают 10 — но это уже есть риск наткнуться на такую подсеть у клиента..
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
Опять же,на клиенте таблица роутинга имеет приоритеты,и если адреса не пересекаются,то даже для одной сети можно маршруты разделить.
Просто,из двух машин с одним и тем же ip-адресом клиент будет всегда видеть только одну.
Если у клиента подсеть 192.168.1.х
Но в ней нет машины 192.168.1.80,которая в офисе сервер,то пишем маршрут по маске только до него,то есть маску 255.255.255.255 и метрику 1,тогда пакеты на сервер пойдут в vpn,а вся остальная сеть 192.168.1.x по стандартному маршруту с метрикой в районе 200 будет прекрасно доступна.
Конечно,выдать по vpn адрес из той же сети 192.168.1.x напрямую не получится — таблица маршрутов испортится,и ничего не будет работать.
41 — 10.01.21 — 17:20
(37) самое смешное, что адреса не совпадают (ну, кроме шлюзов, конечно). но если честно, мне вообще все это непонятно. при соединении вообще создаются адреса 10.0.0.х, для чего они тогда нужны? почему бы не выдавать адреса по DHCP? куча адресов свободна, но как их настроить, хз. в мануалах все все по одной схеме делают, шаг влево, шаг вправо — ничего не работает. я вообще хотел бы, чтобы можно было половину одной сетки объединить с половиной другой. или по маске какой-нибудь. там, до 200-х адресов пусть будут домашние адреса, после — офисные. но так низзя (
42 — 10.01.21 — 17:21
(40) вот, это у меня и не получается. надо всего пару адресов прокинуть, я писал маршруты до них.
43 — 11.01.21 — 07:30
(35) Все она умеет. Обнови винду до десятки.
Йохохо
44 — 11.01.21 — 07:34
(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
На днях заметил, что на ноуте начало глючить соединение с впн сервером. Примерно каждые 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
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
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