Tls crypt unwrap error bad packet id may be a replay

OpenVPN Support Forum

Community Support Forum

tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — see th

tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — see th

Post by mbelchin » Wed Jan 08, 2020 4:05 pm

I just recently installed a new vpn server using openvpn 2.4.7-1 on a debian 10.2 machine.

My problem is that I have server configured to use

This is my server config.

and this is my client config:

Can someone help me out with that ? I’m not sure if the mute-reply-warnings isn’t working or it’s just appearing because of some misconfiguration.

Thanks in advance.

Re: tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — se

Post by TinCanTech » Wed Jan 08, 2020 5:02 pm

Note: —tls-crypt does not require a direction parameter.

You should probably report that as a bug to which ever script you used (pivpn?)

Set —verb 4 and remove —mute-replay-warnings and then post your complete log as per this:
viewtopic.php?f=30&t=22603#p68963

Re: tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — se

Post by mbelchin » Thu Jan 09, 2020 9:23 pm

Thanks for answering. Will follow your instructions

Can you or any other administrator remove this threat ?

Forgot to remove remote ip from config

Re: tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1578390112) Tue Jan 7 09:41:52 2020 ] — se

Post by TinCanTech » Fri Jan 10, 2020 12:22 am

Источник

tls-crypt unwrap error: bad packet ID #737

Recently I have installed openvpn using nyr/openvpn-install and works great, easy to isntall and configure on a Debian 10!

I have detected two issues:
1.- on /var/log/syslog when openvpn is connected with for example openvpn client windows (3.1.3 713) we receive this error during vpn session:
Apr 5 19:09:58 vpn openvpn[453]: uservpn/80.58.0.99:62533 tls-crypt unwrap error: bad packet ID (may be a replay): [ #9 / time = (1586103816) Sun Apr 5 18:23:36 2020 ] — see the man page entry for —no-replay and —replay-window for more info or silence this warning with —mute-replay-warnings
Apr 5 19:09:58 vpn openvpn[453]: uservpn/80.58.0.99:62533 tls-crypt unwrap error: packet replay
Apr 5 19:09:58 vpn openvpn[453]: uservpn/80.58.0.99:62533 TLS Error: tls-crypt unwrapping failed from [AF_INET]80.58.0.99:62533

2.- also detected low performance during winscp copy , max speed 300kb/s when server supports 30mb/s

Any suggestion if both issues are related and how can I solve this?

The text was updated successfully, but these errors were encountered:

I’d suggest to try the OpenVPN Community client, not the OpenVPN Connect client, which is part of the commercial OpenVPN Connect product. But that is unlikely to help with your issue, just wanted to clarify that.

It is possible that both issues are related, but you should consider that nowadays international transit is congested due to the COVID-19 situation and there is no easy way around that.

Like you, I am a Movistar customer myself and serious congestion in the international transit is happening every day during the evenings and nights. Not much you can do about it, other than setting up a VPN server in a well connected network.

Источник

OpenVPN Support Forum

Community Support Forum

OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Mon Jan 09, 2017 11:32 pm

Tue Jan 10 00:31:14 2017 tls-crypt unwrap error: packet too short
Tue Jan 10 00:31:14 2017 TLS Error: tls-crypt unwrapping failed from [AF_INET6]::ffff:93.245.255.104:55912

How to fix this error?

OpenVPN 2.4.0 windows (server)
and
OpenVPN 2.4.0 Linux (openWRT/DD-wrt/LEDE they all have the same message) as client

windows — windows client I don’t see this error
linux — linux I don’t see it either.

windows server — linux client = error message..

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Mon Jan 09, 2017 11:38 pm

ehm.. I know reverting back to tls-auth solves this error message, but that’s not what I’m asking really although it fixes the error..

I do want to use the tls-crypt but working LOL

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Mon Jan 09, 2017 11:58 pm

never mind.. although I ./scripts/feeds update -a
and ./scripts/feeds install -a

then I did make and it did show 2.4.0 in the GUI interface but in command openvpn shows version 2.3.13

so I guess I have to do make dirclean

or even make distclean which I hope to avoid so my menuconfig remains..

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Tue Jan 10, 2017 2:16 am

well. I now have definately 2.4.0 running and still the error.

tls-crypt with the ta.key under linux can’t connect to a windows 2.4.0 with tls-crypt.

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Tue Jan 10, 2017 12:27 pm

than everything is working out of the box and all verifications result in OK and no errors whatsoever!

So it’s really the tls-crypt on the linux side as other windows clients with tls-crypt just work fine!

Re: TLS Error: tls-crypt unwrapping failed from

Post by TinCanTech » Tue Jan 10, 2017 5:06 pm

I have a W10 Server and a Linux client both running openvpn-2.4.0 with — tls-crypt enabled correctly and it works perfectly for me. You must restart your server & client if you change a configuration option.

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Wed Jan 11, 2017 9:09 pm

Thank you for your reply.
I did already restart the whole system. Shutdown. No power.
So I’m pretty sure it’s not a restart issue.

If it works on your end, then I presume it’s working and thus something
is wrong on my end.

I’ll build the firmware from scratch. Maybe some old 2.3 objects still somewhere
in the firmware, although it says 2.4.0 when I openvpn —version.

But thank you anyway, now I know it’s working for someone, it means it should be working
for me as well.

Re: TLS Error: tls-crypt unwrapping failed from

Post by chuckler » Sun Jan 15, 2017 6:06 pm

I’m having the same problem with a LEDE build in a router. I’m using OpenVPN 2.4.0 but still it looks like the

is not applied to the LEDE code, because if you enabled it you can still connect to the server if you disable the tls-auth option in the server config.

Maybe it’s something to do with LEDE/OpenWRT, I’ll open a new post in their forums.

Re: TLS Error: tls-crypt unwrapping failed from

Post by chuckler » Sun Jan 15, 2017 6:13 pm

this is the post on the LEDE forums.

Maybe we could help them.

Re: TLS Error: tls-crypt unwrapping failed from

Post by TinCanTech » Sun Jan 15, 2017 8:25 pm

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Tue Jan 24, 2017 8:46 pm

I found out the error comes from AES-256-GCM

or any other encryption method.

The only thing that tls-crypt is compatible with is AES-256-CTR

All other encryption options are now just useless if you want to use tls-crypt.

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Wed Jan 25, 2017 7:43 am

Ok, so it should work with AES-256-GCM as it applies CTR

Must be LEDE/OpenWRT specific then.

Back to LEDE forums

Re: TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Wed Jan 25, 2017 9:05 am

Solution to the problem I wrote in the last comment:

will be applied to the standard git some time in future. Maybe even today, maybe next month.
But there’s a manual fix for those who are interested.

Re: OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by TinCanTech » Wed Jan 25, 2017 2:51 pm

Openvpn was not involved in that.

With regard to this:

AES-256-CTR has been initially selected for use with — tls-crypt because it is » a nonce misuse-resistant authenticated encryption scheme«.

— tls-crypt only effects the control channel not the data channel. Ciphers available to the data channel are as they always have been and can be configured with — cipher and/or negotiated internally by openvpn with — ncp-ciphers, which is enabled by default in 2.4

It is complicated but well documented .. worth your time to read.

Re: OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by mrgenie » Fri Apr 07, 2017 7:52 pm

Re: OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by xioxify » Sun Jan 21, 2018 7:47 am

Thanks mrgenie for sharing your experience.
I have this problem too.
You said «The only thing that tls-crypt is compatible with is AES-256-CTR», by this you mean I change GCM in the config line » cipher AES-256-GCM» to AES-256-CTR or change the GCM in this line: «tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384» .

Another question:
you used the tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM- SHA384 and the «auth SHA384». They have to be the same SHA384 or can I use the «auth SHA512»??

Re: OpenWRT LEDE — TLS Error: tls-crypt unwrapping failed from

Post by TinCanTech » Sun Jan 21, 2018 3:28 pm

This is simply wrong .. you are mixing up different options that are not linked.

Источник

OpenVPN Support Forum

Community Support Forum

tls-crypt and DPI bypass?

tls-crypt and DPI bypass?

Post by godaddy » Mon Apr 13, 2020 2:56 pm

I live in a highly censored regime. I’ve heard TLS-Crypt can bypass the DPI on the ISP side. Is it true? I just setup openvpnas and the config contains tls-auth, not tls-crypt.

Is it possible to enable this? any other points that might help?

i’ve been looking at obfsproxy and xor patch — are they the only real solution here?

Re: tls-crypt and DPI bypass?

Post by kelleci » Tue Apr 21, 2020 7:12 pm

Re: tls-crypt and DPI bypass?

Post by houmie75 » Thu Aug 20, 2020 6:35 pm

Re: tls-crypt and DPI bypass?

Post by TinCanTech » Thu Aug 20, 2020 7:54 pm

Re: tls-crypt and DPI bypass?

Post by houmie75 » Thu Aug 20, 2020 9:31 pm

Re: tls-crypt and DPI bypass?

Post by TinCanTech » Thu Aug 20, 2020 9:47 pm

Re: tls-crypt and DPI bypass?

Post by houmie75 » Thu Aug 20, 2020 10:10 pm

I was looking for a way to obfusticate the VPN connection. The user Kelleci mentioned that he had established working configs for XOR or for tls-crypt that could hide the footprint. I was curious what these configs looked like. I’m using tls-crypt, but the DPI in Emirates can still see through it and block it.

Especially when he said:

Re: tls-crypt and DPI bypass?

Post by TinCanTech » Thu Aug 20, 2020 10:29 pm

If you want to try out TLS Crypt V2 then there are some advantages.

As for XOR, it is required on both client and server and you have to patch/build openvpn yourself.

XOR is also completely ineffective ..

Keep in mind, who ever owns the network makes the rules.

Re: tls-crypt and DPI bypass?

Post by houmie75 » Fri Aug 21, 2020 7:28 am

Thank you. I have been reading up on your repo this morning. Is there a step by step tutorial by any chance?

This is what I have done so far.
1) I have a prepared OpenVPN server already installed via Angritan script.
2) sudo cp

or do I run this

Re: tls-crypt and DPI bypass?

Post by TinCanTech » Fri Aug 21, 2020 10:06 am

Download https://github.com/TinCanTech/easy-tls/ . er/easytls
Save it into the same directory where you have easyrsa

That will create TLS-Crypt-V2 keys.

Now you can try:

Re: tls-crypt and DPI bypass?

Post by TinCanTech » Fri Aug 21, 2020 11:12 am

You need that on both server and client.

Re: tls-crypt and DPI bypass?

Post by houmie75 » Fri Aug 21, 2020 5:24 pm

You’re welcome.

Thank you so much for the excellent step by step commands.

Yeah when I ran this it complains about the version:

Ah you mean I need the beta version 2.5?
So I have to compile it.

No problem, let see what I can do. Have to create my own script out of Angristan script.

Re: tls-crypt and DPI bypass?

Post by TinCanTech » Fri Aug 21, 2020 5:38 pm

Re: tls-crypt and DPI bypass?

Post by houmie75 » Fri Aug 21, 2020 8:34 pm

Brilliant idea. With the repo I was able to add it first and then run the Angristan script, which ended up with the latest openVPN 2.5 to be installed.

I also managed to run your easy-tls, it is really easy once I followed your instructions. I recommend adding that to the main README on your github.

Now comes the best news. Not only it works, it also works in Emirates. So I like to understand this better. How comes their DPI was able to see through openVPN 2.4.7 and tls-crypt but not with openVPN 2.5 and tls-crypt-v2?

Is this only a matter of time until they catch up?

Thank you so much for you help

Re: tls-crypt and DPI bypass?

Post by TinCanTech » Fri Aug 21, 2020 9:12 pm

I don’t know how they scan the packets but i do know that —tls-auth and —tls-crypt are public keys.

—tls-crypt-v2 has completely private and unique keys.

Re: tls-crypt and DPI bypass?

Post by Pippin » Fri Aug 21, 2020 9:37 pm

Re: tls-crypt and DPI bypass?

Post by TinCanTech » Fri Aug 21, 2020 10:04 pm

Re: tls-crypt and DPI bypass?

Post by houmie75 » Sat Aug 22, 2020 9:37 am

That’s amazing. Let’s the cross the fingers that it remains undetected.

I have another question:
The client cert begins usually with

But Angristan script skips everything above BEGIN CERTIFICATE. Is it recommended to keep it for the client or doesn’t it matter?

Re: tls-crypt and DPI bypass?

Post by TinCanTech » Sat Aug 22, 2020 11:31 am

Источник

In raising this issue, I confirm the following:

{please fill the checkboxes, e.g: [X]}

• I have read and understood the contributors guide.
• The issue I am reporting can be replicated.
• The issue I am reporting can be is directly related to the pivpn installer script.
• The issue I am reporting isn’t a duplicate (see FAQs, closed issues, and open issues).

Upon attempting to connect to openvpn after installing using pivpn, I get the following error:

Aug 17 23:38:45 omv ovpn-server[1016]: REDACTED:1028 TLS: Initial packet from [AF_INET]REDACTED:1028, sid=07e232f8 735e23e4
Aug 17 23:38:46 omv ovpn-server[1016]: REDACTED:1028 tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1597703924) Mon Aug 17 23:38:44 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Aug 17 23:38:46 omv ovpn-server[1016]: REDACTED:1028 tls-crypt unwrap error: packet replay
Aug 17 23:38:46 omv ovpn-server[1016]: REDACTED:1028 TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:1028
Aug 17 23:38:47 omv ovpn-server[1016]: REDACTED:1028 tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1597703924) Mon Aug 17 23:38:44 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Aug 17 23:38:47 omv ovpn-server[1016]: REDACTED:1028 tls-crypt unwrap error: packet replay
Aug 17 23:38:47 omv ovpn-server[1016]: REDACTED:1028 TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:1028
Aug 17 23:38:48 omv ovpn-server[1016]: REDACTED:1028 tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1597703924) Mon Aug 17 23:38:44 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Aug 17 23:38:48 omv ovpn-server[1016]: REDACTED:1028 tls-crypt unwrap error: packet replay
Aug 17 23:38:48 omv ovpn-server[1016]: REDACTED:1028 TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:1028
Aug 17 23:39:15 omv ovpn-server[1016]: REDACTED:1025 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug 17 23:39:15 omv ovpn-server[1016]: REDACTED:1025 TLS Error: TLS handshake failed
Aug 17 23:39:15 omv ovpn-server[1016]: REDACTED:1025 SIGUSR1[soft,tls-error] received, client-instance restarting
Aug 17 23:39:24 omv ovpn-server[1016]: REDACTED:1024 TLS: Initial packet from [AF_INET]REDACTED:1024, sid=5dacab12 3b4909aa
Aug 17 23:39:25 omv ovpn-server[1016]: REDACTED:1026 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug 17 23:39:25 omv ovpn-server[1016]: REDACTED:1026 TLS Error: TLS handshake failed
Aug 17 23:39:25 omv ovpn-server[1016]: REDACTED:1026 SIGUSR1[soft,tls-error] received, client-instance restarting
Aug 17 23:39:35 omv ovpn-server[1016]: REDACTED:1027 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug 17 23:39:35 omv ovpn-server[1016]: REDACTED:1027 TLS Error: TLS handshake failed
Aug 17 23:39:35 omv ovpn-server[1016]: REDACTED:1027 SIGUSR1[soft,tls-error] received, client-instance restarting
=============================================
::::		Debug complete		 ::::
::: 
::: Debug output completed above.
::: Copy saved to /tmp/debug.txt

Have you searched for similar issues and solutions?

Yes

Console output of pivpn debug

::: Generating Debug Output
::::		PiVPN debug		 ::::
=============================================
::::		Latest commit		 ::::
commit 32bd1c628af9e1926f3f4471c0bf49c74deff7c7
Author: Orazio <orazioedoardo@users.noreply.github.com>
Date:   Fri Jul 24 18:52:57 2020 +0200

    Update LatestUpdate.md
=============================================
::::	    Installation settings    	 ::::
PLAT=Raspbian
OSCN=buster
USING_UFW=0
IPv4dev=enxb827eb4ad778
IPv4addr=192.168.1.111/24
IPv4gw=192.168.1.254
install_user=pi
install_home=/home/pi
VPN=openvpn
pivpnPROTO=udp
pivpnPORT=1194
pivpnDNS1=8.8.8.8
pivpnDNS2=8.8.4.4
pivpnSEARCHDOMAIN=
pivpnHOST=REDACTED
TWO_POINT_FOUR=1
pivpnENCRYPT=256
USE_PREDEFINED_DH_PARAM=
INPUT_CHAIN_EDITED=0
FORWARD_CHAIN_EDITED=1
pivpnDEV=tun0
pivpnNET=10.8.0.0
subnetClass=24
UNATTUPG=1
INSTALLED_PACKAGES=()
HELP_SHOWN=1
=============================================
::::  Server configuration shown below   ::::
dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/omv_7785372f-4d3c-43cc-81cd-0730a0119963.crt
key /etc/openvpn/easy-rsa/pki/private/omv_7785372f-4d3c-43cc-81cd-0730a0119963.key
dh none
ecdh-curve prime256v1
topology subnet
server 10.8.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
# Prevent DNS leaks on Windows
push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device. 
#duplicate-cn
# Generated for use by PiVPN.io
=============================================
::::  Client template file shown below   ::::
client
dev tun
proto udp
remote REDACTED 1194
resolv-retry infinite
nobind
remote-cert-tls server
tls-version-min 1.2
verify-x509-name omv_7785372f-4d3c-43cc-81cd-0730a0119963 name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
=============================================
:::: 	Recursive list of files in	 ::::
::: /etc/openvpn/easy-rsa/pki shows below :::
/etc/openvpn/easy-rsa/pki/:
Default.txt
ca.crt
crl.pem
ecparams
index.txt
index.txt.attr
index.txt.attr.old
index.txt.old
issued
james.ovpn
openssl-easyrsa.cnf
private
renewed
revoked
safessl-easyrsa.cnf
serial
serial.old
ta.key

/etc/openvpn/easy-rsa/pki/ecparams:
prime256v1.pem

/etc/openvpn/easy-rsa/pki/issued:
james.crt
omv_7785372f-4d3c-43cc-81cd-0730a0119963.crt

/etc/openvpn/easy-rsa/pki/private:
ca.key
james.key
omv_7785372f-4d3c-43cc-81cd-0730a0119963.key

/etc/openvpn/easy-rsa/pki/renewed:
private_by_serial
reqs_by_serial

/etc/openvpn/easy-rsa/pki/renewed/private_by_serial:

/etc/openvpn/easy-rsa/pki/renewed/reqs_by_serial:

/etc/openvpn/easy-rsa/pki/revoked:
private_by_serial
reqs_by_serial

/etc/openvpn/easy-rsa/pki/revoked/private_by_serial:

/etc/openvpn/easy-rsa/pki/revoked/reqs_by_serial:
=============================================
::::		Self check		 ::::
:: [OK] IP forwarding is enabled
:: [OK] Iptables MASQUERADE rule set
:: [OK] Iptables FORWARD rule set
:: [OK] OpenVPN is running
:: [OK] OpenVPN is enabled (it will automatically start on reboot)
:: [OK] OpenVPN is listening on port 1194/udp
=============================================
:::: Having trouble connecting? Take a look at the FAQ:
:::: https://github.com/pivpn/pivpn/wiki/FAQ
=============================================
::::      Snippet of the server log      ::::
Aug 17 23:50:12 omv ovpn-server[5616]: Initialization Sequence Completed
Aug 17 23:51:54 omv ovpn-server[5616]: REDACTED:1024 TLS: Initial packet from [AF_INET]REDACTED:1024, sid=1932e07e 1bb6e9b4
Aug 17 23:51:55 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1597704713) Mon Aug 17 23:51:53 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Aug 17 23:51:55 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: packet replay
Aug 17 23:51:55 omv ovpn-server[5616]: REDACTED:1024 TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:1024
Aug 17 23:51:56 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1597704713) Mon Aug 17 23:51:53 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Aug 17 23:51:56 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: packet replay
Aug 17 23:51:56 omv ovpn-server[5616]: REDACTED:1024 TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:1024
Aug 17 23:51:57 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1597704713) Mon Aug 17 23:51:53 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Aug 17 23:51:57 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: packet replay
Aug 17 23:51:57 omv ovpn-server[5616]: REDACTED:1024 TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:1024
Aug 17 23:51:58 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1597704713) Mon Aug 17 23:51:53 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Aug 17 23:51:58 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: packet replay
Aug 17 23:51:58 omv ovpn-server[5616]: REDACTED:1024 TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:1024
Aug 17 23:51:59 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1597704713) Mon Aug 17 23:51:53 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Aug 17 23:51:59 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: packet replay
Aug 17 23:51:59 omv ovpn-server[5616]: REDACTED:1024 TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:1024
Aug 17 23:52:00 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: bad packet ID (may be a replay): [ #1 / time = (1597704713) Mon Aug 17 23:51:53 2020 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Aug 17 23:52:00 omv ovpn-server[5616]: REDACTED:1024 tls-crypt unwrap error: packet replay
Aug 17 23:52:00 omv ovpn-server[5616]: REDACTED:1024 TLS Error: tls-crypt unwrapping failed from [AF_INET]REDACTED:1024
=============================================
::::		Debug complete		 ::::
::: 
::: Debug output completed above.
::: Copy saved to /tmp/debug.txt

Have you taken any steps towards solving your issue?

Tried reinstalling multiple times but get the same error

This topic has been deleted. Only users with topic management privileges can see it.

• I am not sure exactly which snapshot started this, but the remote client VPNs wont pass traffic with DCO enabled anymore. It did work on a previous snapshot.

  We’re on 22.05.r.20220609.1919.

  If I disable DCO- traffic flows fine as it always has. Just to remove all doubt — the hashes are all SHA256.

  Our S-S using TLS works fine with DCO.

  Any ideas?

• That enabling DCO on the server end?

  Clients still connect OK, just can’t pass traffic?

  Any errors logged?

• @stephenw10
  Just repeated it and looked at the OVPN logs. No errors that I can see with DCO on.
  Clients connect OK — just no traffic.
  Enabling DCO on server end yes.

• Hmm, what clients are you using?

• @stephenw10 Using the OpenVPN Client for IOS this AM. The Viscosity client on MacOS has the same issue.

• Hmm, do you see:

  [22.05-RC][admin@fw1.stevew.lan]/root: pkg info -s openvpn
  openvpn-2.6.0_8                805KiB
  

  Steve

• @stephenw10

  # pkg info -s openvpn
  openvpn-2.6.0_8                836KiB
  

  looks good. (Except file size)

• Filesize…..

• I have exact same filesize and version as @swixo
  And if I turn ON DCO, traffic stops flowing on my android device.
  Turn DCO OFF all is fine again…

• @pippin Yep — I see that — disregarded initially.

• @swixo Just reinstalled 22.01. Upgraded to 22.05RC.

  pkg info -s openvpn
  openvpn-2.6.0_8 836KiB

  Client VPN behaved same — DCO=no data flow, no DCO, all ok.

• Mmm, I was looking on a 3100 there though. On an amd64 machine it looks good:

  [22.05-RC][admin@4100-2.stevew.lan]/root: pkg info -s openvpn
  openvpn-2.6.0_8                836KiB
  

  I assume the IOS client is still OpenVPN 2.5 based?

• @stephenw10 Yeah — for me all iOS and MacOS have issue.
  My platform for pf is all Netgate 1537 appliances.

• I have seen an occasional glitch on OSX but I’m not sure if it’s specific to OSX. The first start after a reboot sometimes it won’t ping, but if I restart the server and reconnect the client it can. But since it’s so intermittent and doesn’t happen every time (and didn’t log anything different that I recall), I hadn’t been able to nail down anything solid enough to call a problem yet.

  If you can reproduce it reliably, check the ifconfig output for the interface, the contents of the routing table, and the OpenVPN logs for when it doesn’t work, then restart the server and see if you can reconnect the client and pass traffic. If you can, then compare the logs and other output and see if you notice any differences.

• @jimp said in 22.05 — DCO and OpenVPN issue:

  If you can reproduce it reliably, check the ifconfig output for the interface, the contents of the routing table, and the OpenVPN logs for when it doesn’t work, then restart the server and see if you can reconnect the client and pass traffic. If you can, then compare the logs and other output and see if you notice any differences.

  Ok! I tested and I was able to get traffic to flow ONCE after I closed the tunnel, restarted the server and restarted the tunnel. But subsequent initiations of the tunnel resulted in no data flow.

  This is the ifconfig for the interface — and it was the same in the fail and non fail condition:

  utun10: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
  	inet 192.168.41.2 --> 192.168.41.2 netmask 0xffffff00
  

  I didn’t see anything error like in the logs. Just the usual stuff.

  s

• That looks like the client side, what about differences on the server side when it works vs when it doesn’t?

• @jimp I have not been able to ‘jiggle’ it into working by disconnecting/restarting and reconnecting again. It just fails:

  This is ifconfig from Server side for each state

  tunnel disconnected:

  ovpns2: flags=8011<UP,POINTOPOINT,MULTICAST> metric 0 mtu 1500
  	options=80000<LINKSTATE>
  	inet6 fe80::3eec:efff:fe79:f1f2%ovpns2 prefixlen 64 tentative scopeid 0x19
  	inet 192.168.41.1 --> 192.168.41.2 netmask 0xffffff00
  	groups: openvpn
  	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
  

  Connected/Failing (No data pass)

  ovpns2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
  	options=80000<LINKSTATE>
  	inet6 fe80::3eec:efff:fe79:f1f2%ovpns2 prefixlen 64 scopeid 0x19
  	inet 192.168.41.1 --> 192.168.41.2 netmask 0xffffff00
  	groups: openvpn
  	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
  

  Hope this helps.

• I think this is what I hit yesterday with multiple clients failing (only the first client, e.g. .2 worked). We got a fix in yesterday afternoon and made a new build. You should be able to update to that and try it.

• This post is deleted!

• @jimp I may have spoken too soon — It worked once — but shortly after — same problem returned.

  Did a server restart — and its blocking data again w/DCO. Sorry for any false start — just reporting what I’m seeing.

• Odd. I can’t reproduce any problem now, and I could before. I’ve restarted the server and clients multiple times. Not just reboots but daemon restarts.

• @jimp So I tried again with MacOS — working with DCO. No erros in logs. Connected with iOS — nothing. And as soon as I connected with iOS, the MacOS connection stopped working too.

  Log errors at time of failure:

  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 TLS Error: tls-crypt unwrapping failed from [AF_INET]192.168.1.212:54428 (via [AF_INET]192.168.1.1%)
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: packet replay
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: bad packet ID (may be a replay): [ #9 / time = (1655315314) 2022-06-15 10:48:34 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 TLS Error: tls-crypt unwrapping failed from [AF_INET]192.168.1.212:54428 (via [AF_INET]192.168.1.1%)
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: packet replay
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: bad packet ID (may be a replay): [ #8 / time = (1655315314) 2022-06-15 10:48:34 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
  

• For me, Android now works OK.
  But I had to disable DCO, because it`s like 40% slower than without it…

• @maverick_slo said in 22.05 — DCO and OpenVPN issue:

  For me, Android now works OK.
  But I had to disable DCO, because it`s like 40% slower than without it…

  If your hardware supports AES-NI, make sure the AES-NI kernel module is loaded (System > Advanced, Misc tab).

  The only time we’ve seen DCO be slower is when the hardware supports crypto acceleration but it’s not enabled in the kernel/modules. DCO is in the kernel so it can’t just latch onto AES-NI via OpenSSL like non-DCO OpenVPN can.

• @swixo said in 22.05 — DCO and OpenVPN issue:

  @jimp So I tried again with MacOS — working with DCO. No erros in logs. Connected with iOS — nothing. And as soon as I connected with iOS, the MacOS connection stopped working too.

  Log errors at time of failure:

  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 TLS Error: tls-crypt unwrapping failed from [AF_INET]192.168.1.212:54428 (via [AF_INET]192.168.1.1%)
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: packet replay
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: bad packet ID (may be a replay): [ #9 / time = (1655315314) 2022-06-15 10:48:34 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 TLS Error: tls-crypt unwrapping failed from [AF_INET]192.168.1.212:54428 (via [AF_INET]192.168.1.1%)
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: packet replay
  Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: bad packet ID (may be a replay): [ #8 / time = (1655315314) 2022-06-15 10:48:34 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
  

  I still can’t reproduce any problems here. Replay errors suggest it’s a network-level problem with packets arriving out of order, though.

• @jimp Updated to 22.05.r.20220617.0613 this AM.

  Similar situation — First client to connect — its good. Second client to connect — Both lose data flow.

• It7s loaded…
  AES-NI CPU Crypto: Yes (active)

  But still it is really slower…

• Hi @jimp — just upgraded my 22.01 system to 22.05 RC and seeing the same issues that @swixo and @maverick_slo have described when DCO is enabled on OpenVPN.

  In my case I’m using two clients:

  1. iPhone with iOS 15.5 and version 3.2.3 of the OpenVPN Connect client for iOS
  2. Macbook Pro with macOS 12.4 and latest version of Tunnelblick VPN client (3.8.7a)

  Each client will work fine when connected individually. If I connect both then both will lose data flow as soon as the second client is connected (the order in which they are connected doesn’t seem to matter). I’ve increased the verbosity on the OpenVPN logs but can’t really see anything that looks to the a problem. Are there any settings on the client or server side I should doublecheck? I basically just enabled DCO on the server and tried things out. As a sanity check, I did disable DCO and then connected both clients — everything worked fine (i.e. data flow was not interrupted).

  EDIT: Just tried with a non Apple client as well (Debian 11.3 Linux system). As soon as second client connects both lose data flow.

  Regarding speed:

  1. On the iPhone (WiFi) having DCO enabled is slower for me also (especially download) compared to no DCO with Fast I/O and 512KB buffer sizes.
  2. On the Macbook Pro (wired) it is just as fast if not a tad faster, which I thought was interesting.

  Thanks in advance for your help.

• One additional thing I thought of: I did create an OpenVPN interface ovpns1 when I originally set things up. Are there any configuration settings I should be checking with respect to that interface (e.g. MTU, MSS, etc.)? Thanks again.

• I’m curious if you guys had any idea on how to troubleshoot this further? The only thing I have not tried yet is creating a brand new OpenVPN server (tunnel) from scratch to see if that resolves the data flow issues. @swixo and @maverick_slo — have you guys tried this yet? Thanks in advance.

• @tman222 I have not tried deleting the tunnel and starting over — although I may create a new one and see if it is ok.

  We have a bug in either case and I want to preserve the failure condition so I can verify a proper fix if offered.

• @swixo This issue has been reliably reproduced (and still failing) on 22.05-RELEASE (amd64).

• There must be something different about your setup. I still can’t reproduce a problem here. I have three clients connected (pfSense, Windows, and OSX) and they all have working connectivity across the VPN.

• @jimp I must have a setting aggravating it — user tman seems to have same issue.
  Just in case — here are my settings:

  DCO=on
  Mode: TUN
  Proto: UDP/v4
  interface: Any 
  Use Tls Key: Checked
  TLS Usage: Enc and Auth
  TLS KeyDir: Both
  No Cert Rev List
  No OCSP Check
  DH: 4096
  ECDH: secp384r1
  Algorithms: AES-256-GCM
  Fallback: AES-256-GCM
  Auth Digest: SHA256 (256)
  HW Crypto: Intel RDRAND
  Cert Depth (Client+Server)
  Client Certificate Key Usage: Enforce Checked
  Tunnel Network /24
  no IPV6
  Redirect: Force all IPv4 Thru tunnel: Checked
  No Redirect IPv6 checked
  Concurrent connections: blank
  Compression: Refuse non stub
  Inter Client Comm: Checked
  Duplicate Conn: Checked
  Dup Conn Limit: Blank
  Client Dynamic IP: Checked
  Topology: One IP address per client common subnet
  Ping: Inactive: 0
  Method: Keepalive
  interval: 10
  Timeout: 60
  DNS Default Domain: Checked
  DNS Server Enable: Checked
  Block Outside DNS: Unchecked
  Force DNS Update: Unchecked
  NTP Server: Checked
  Custom Options: push "route 1.2.3.4 255.255.255.0"
  UDP Fast I/O: Unchecked
  Exit Notify: Disabled
  Send/Receive Buffer: Default
  Gateway Creation ipv4 only

• I’m using RA SSL/TLS but that shouldn’t matter.

  TLS Usage: Enc and Auth

  Mine: Auth only

  TLS KeyDir: Both

  Mine: Default

  DH: 4096

  Mine: 2048

  ECDH: secp384r1

  Mine: Default

  HW Crypto: Intel RDRAND

  Set that to «No», you aren’t going to gain anything from that one, especailly with DCO.

  Redirect: Force all IPv4 Thru tunnel: Checked

  I don’t have this set but it’s probably not going to change anything.

  Inter Client Comm: Checked

  Mine: Unchecked

  Duplicate Conn: Checked

  Mine: Unchecked (each client has a unique cert)

  Client Dynamic IP: Checked

  Mine: Unchecked

  DNS Default Domain: Checked

  Mine: Unchecked

  DNS Server Enable: Checked

  Mine: Unchecked

  NTP Server: Checked

  Mine: Unchecked

  Custom Options: push «route 1.2.3.4 255.255.255.0»

  Mine: Blank (but that one route alone should be fine)

  A lot of those, like the pushed DNS options, shouldn’t make a difference. I’d focus on trying to change one thing at a time to see if it helps and if it doesn’t, change it back and try the next one. That way you can isolate the potential problem there.

  I’d try changing TLS auth first to auth only, I’m not sure if anyone has tried TLS enc+auth with DCO yet.

  Also you listed several options that should be hidden when you have DCO on (like inactive and UDP fast i/o), are those really showing in your GUI with DCO checked or did you transcribe those from somewhere else?

• @jimp said in 22.05 — DCO and OpenVPN issue:

  HW Crypto: Intel RDRAND

  Set that to «No», you aren’t going to gain anything from that one, especailly with DCO.

  I’d try changing TLS auth first to auth only, I’m not sure if anyone has tried TLS enc+auth with DCO yet.

  Also you listed several options that should be hidden when you have DCO on (like inactive and UDP fast i/o), are those really showing in your GUI with DCO checked or did you transcribe those from somewhere else?

  My bad on that — I had flipped DCO off just to get the VPN going again and hadn’t thought the UX would change the options.

  I will test the changes you suggest and report.

• @swixo Tried a bunch of these changes and made things worse.

  Intel Hardware accel had no effect. But the Key Dir and Auth Only/Auth+Encry setting made a lot of difference. Had to export new profiles after every change to make sure clients were in sync.

  Most of the time — I couldn’t connect at all — or data never flowed, until turning DCO off — then it usually worked fine after that.

• @jimp Just to chime in:

  we were rolling out 2 new boxes 6100/4100 to a customer and I set up OpenVPN RAS pretty default with new DCO setting.

  Exactly same problem: .2 client can connect and route/transfer data, all other client IPs don’t get ANY data at all sent through the connection. Switching off DCO immediatly works again. No spiffy or special stuff configured, just plain dead simple RAS setup with a single LAN network that gets pushed to the clients.

  Clients are 2x windows boxes with win10, newest OVPN Client 2.5.9/x64 and have no problems whatsoever. Routes are just fine, traffic simply refuses to flow through the server if you’re not client #.2

  System is on 22.05 stable

  Cheers
  jens

• Hmm, were those supplied with 22.05 or upgraded from 22.01?

  Does that include traffic between IPs in the tunnel subnet directly?

• @stephenw10 Those were freshly installed with 22.01 and clean upgraded to 22.05 — at least there were no errors or other hiccups in the logs or anywhere to see.

  Besides that it’s a simple straightforward RAS style setup:

  • SSL/TLS + User Auth
  • DCO
  • tun L3
  • UDP/1194
  • TLS Key with TLS Auth (not auth+enc), default direction
  • VPN CA, VPN Cert, VPN CRL created
  • ECDH only
  • prime256v1
  • SHA256
  • no HW crypt (but AES-NI enabled kernel module)
  • cert depth 1 (C+S)
  • Strict User-CN Matching
  • Enforce Key usage
  • IP4 tunnel network 192.168.45.0/26 (to leave space to add another VPNs server later with .45.64/26, .45.128/26, etc.)
  • IP4 local network 192.168.40.0/24 (LAN)
  • compression: refuse any non stub (most secure)
  • dynamic IP selected
  • subnet
  • keepalive 5 30
  • DNS default domain set up to the locally used domain
  • DNS server set up to the local MS AD server
  • Gateway v4 only
  • Verb 3

  nothing else set. The RAS clients aren’t supposed to talk with each other so no, inter-client comm isn’t a thing here

  Cheers
  jens