Docker-transmission-openvpn: Authenticate/Decrypt packet error

[RagingRandy]

I am having trouble using this container for any meaningful length of time. After a few minutes of downloading I begin to receive this error repeatedly in my log:
"Authenticate/Decrypt packet error: bad packet ID (may be a replay)".
It seems that I continue to receive this error until my machine runs out of memory and the container unexpectedly stops.
I am running on Synology DSM 6.1.
I have read that this is unlikely to be a man in the middle attack but likely a packet size problem. I just don't know where to look to fix it. Thanks for your work Haugene,

[RagingRandy]

Anyone else having issues with ram usage? I'm using 5-6GB of memory per instance.

[Fma965]

Yes i keep getting this

Sat Jun 10 03:08:08 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #235853 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat Jun 10 03:08:36 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #491688 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat Jun 10 03:08:36 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #491701 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319136 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319137 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319138 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319139 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319140 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319141 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319142 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319143 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319144 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319145 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319146 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319147 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Tue Jun 13 02:28:30 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #28319148 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Millions of entries for this in the log.

I'm running it on a dedicated server in the cloud with openmediavault, the docker is on the SSD aswell.

[Fma965]

Yeah this is actually becoming a major issue now, every like 12 hours i have to restart the docker for it to work.

[kronnnnnn]

This is starting to be an issue for me too. These logs are eating up space and not to mention memory. is there no mute option?

[Jean-Mercier]

I have the same issue

with just 1 check ip torrent it use 5.7 Go de ram

[haugene]

You need to specify to docker that you don't want logs forever. For example like this: -–log-driver json-file --log-opt max-size=10m

As for the millions of warnings, there is a mute option (as noted in every line): --mute-replay-warnings you should be able to add this to your OPENVPN_OPTS. But maybe it should be muted by default.

[Dulanic]

I've noticed this too with multiple VPN providers. I'm assuming the issue is it running through docker so openvpn sees it as a possible man in the middle attack? When it starts spamming this, the web ui tends to become unresponsive. I'm thinking this might need to be muted by default?

[theaccordance]

Curious, has anyone integrated --mute-replay-warnings into a docker-compose file? Not sure where to put it

[haugene]

It should be added to OPENVPN_OPTS. so basically like this and add it at the end I guess. I have a feeling this should be set as default, don't think anyone wants to see these warnings.

[h45rd]

Experienced this warning related OOM crash around a week ago myself.
Adding the mute parameter seemed to solve the issue without any side effects.
Making it default sounds like a good idea :+1:

[theaccordance]

@haugene thank you, I will add that to my compose file and give it a try. I agree with the idea of defaulting this setting - I don't think these log entries provide value when debugging.

[Bau250]

muting it simply doesn't solve it. if these logs are accurate and they have the wrong packet ID, that is serious concern for security.

[haugene]

Open to hear about concerns, but it seems it might be a good solution to mute them.
From OpenVPN man pages:

--mute-replay-warnings
Silence the output of replay warnings, which are a common false alarm on WiFi networks. This option preserves the security of the replay protection code without the verbosity associated with warnings about duplicate packets.

[PlqnK]

I'm not sure it's a good idea to mute it by default, there's a good reason that OpenVPN throws those warnings! If I understand correctly if my server is really getting duplicate packets then there's some overhead involved and I would like to avoid it if possible.

I did some testing with two scenarios:

1. Transmission and OpenVPN running natively on my desktop downloading this month Arch Linux ISO using my VPN provider: No warnings.
2. Using Docker and your container downloading the same Arch Linux ISO using the same VPN provider: Spam in the logs.

I'm running an up to date Arch Linux install on my desktop but I have the exact same problem on my server where I run Docker in an Ubuntu LTS 16.04.4 VM. At first I thought it might come from the virtualised network driver (I was using VirtIO) but because I have the same problem on my desktop that's not the problem.
I also tested a different VPN provider, same results.

So I'm pretty sure it either comes from docker itself or your container. I'm going to do more testing, using different containers to see if it's a problem with docker or your container and report back!

[haugene]

Interesting to hear that it doesn't happen on a native install, just in a containerised environment. And thanks for putting in the effort to find out why this happens. Are you disabling IPv6 in the container networking? Just trying to find things in the network stack that is different on the docker network drivers compared to the native approach.

The duplicates is a form of overhead and it would be nice to avoid it, but if we can't get to the bottom of it I think we'll mute them - as it doesn't impact security.

[PlqnK]

I'm not explicitly disabling IPv6 in the container but I'm not sure if it's enabled by default, I will check! If you have any other idea of what to look for I'm all ears! By the way are you affected yourself by this?

The duplicates is a form of overhead and it would be nice to avoid it, but if we can't get to the bottom of it I think we'll mute them - as it doesn't impact security.

I agree. I didn't have time to do a lot of research and testing but for example on all binhex vpn containers replay-warnings are muted by default. I don't know if it's intentional because I don't find the command in any of the docker files or scripts in his repos but the argument is passed to openvpn when starting his different containers. Maybe those warning are just some sort of side effect of how docker handle the network stack.
I will have more time to do more testing this week-end though!

[haugene]

Great, will do! And yes I get tons of those in my logs as well. I've just set up log rotation and max log size so that I don't store them forever.

[PlqnK]

After reading a bit on my VPN provider forum and what they recommend when encountering this error is playing with mssfix because it sounds like a MTU sizing issue (even though every network card, hardware, virtual and the docker bridge are correctly set to 1500 on both of my machines).
I added --mssfix 1460 to OPENVPN_OPTS and I practically don't have the warnings anymore. I still get some from time to time but I also get a little bit when using transmission and openvpn in a FreeBSD jail so I'm assuming that's normal, at least not related to docker or your container.

Other values of mssfix could work, I only tested 1460 because they recommended "MTU - 40" in one of the thread I read and it worked so I did not look any further! I didn't notice any drop in my download speed so there isn't any apparent side effect.

Could you try yourself to see if it works for you?

EDIT: I would still add --mute-replay-warnings though because even if the warnings are a lot more scarse now it's still log spam and if the root problem is really solved by modifying mssfix then we don't really need the notificaiton anymore.

[ilovett]

@PlqnK can you post a link to the thread with other values?

[PlqnK]

There's no other "fixed" values. They recommended to try in decrements of 25 starting at 1500 (the standard MTU) until you find a value that doesn't throw replay warnings.

[rcdailey]

@PlqnK: I specify your recommended environment variable in my docker-compose.yml, using decrements of 25:

environment:
  OPENVPN_OPTS: --mssfix 1450

But the start up logs still indicate MTU 1500 is used:

...
Thu Oct 25 23:25:35 2018 /sbin/ip link set dev tun0 up mtu 1500
...
Thu Oct 25 23:25:35 2018 /etc/openvpn/tunnelUp.sh tun0 1500 1558 10.11.11.6 10.11.11.5 init

What am I missing here?

[PlqnK]

This is expected. mssfix doesn't change the configured MTU, if you want to do that you can use --link-mtu or --tun-mtu but it's not the recommended way. It's best to use --mssfix which ask the server to not exceed the desired UDP packet size without changing the real connexion MTU.

[crookedmosquito]

I am seeing the error as well. It only seems to happen when I have multiple downloads going. When it is a single download I don't see anything at all. I have tried this with both PIA and IPVANISH. I have tried setting my mtu setting to the above settings, 1450, and so on to no real avail. Weird how it's only seen with the multiple downloads and what not.

[MilkmanCDN]

I'm seeing this error as well. Configured on Synology NAS. Any ideas what's going on here?

[haugene]

Summing up the discussion. These messages appear because a packet is received twice, a replay. There is replay protection because it's a possible way to attack a connection - and that protection is logging a warning every time a replay is received.

So first of all, how do we handle this the simplest way? We add --mute-replay-warnings to the openvpn options.
OpenVPN also says this is fine, and safe. From the docs:

--mute-replay-warnings
Silence the output of replay warnings, which are a common false alarm on WiFi networks. This option preserves the security of the replay protection code without the verbosity associated with warnings about duplicate packets.

But I'm not on WiFi, so where are these packet drops or bad network performance coming from?
Then we're probably talking about the transport protocol, whether it be UDP or TCP and the MSS and MTU limits. Basically it's about how much payload a packet can carry and still have room for necessary headers while moving through connections where various hops have differing MTU limits. And in addition to the encapsulation of our data in a TCP stream these packets again are encapsulated in encrypted packets with openvpn. And these packets can't be split along the way, so too large packets are dropped. Dropped packets trigger replays and generally degraded network performance, like an unreliable WiFi.

I will close this issue now. This is not a bug with either Transmission, OpenVPN or this image. It's just networking at play. If anyone plays around with MSS on TCP or UDP and finds a good solution (for them - remember that your router can be the limiting factor) then please share it. All in all I do not consider this a big issue, and I don't think the throughput is suffering enough to make it a big deal. If someone can prove otherwise - please do - and let's look at it. But for now, the official statement is to mute them.

Feel free to keep the discussion going nevertheless 😄

[MilkmanCDN]

Appreciate the response. I came to the same conclusion last night modified my OPENVPN_OPTS environment variable to: --inactive 3600 --ping 10 --ping-exit 60 --mute-replay-warnings

The warnings have predictably stopped and I'm a happy camper. THANK YOU!! Very pleased that you put this package together.

[ilovett]

Just came here to mention the issue went away for me after switching from UDP to TCP vpn connection (on a wired connection). I cannot remember for sure if I tried --mute-replay-warnings and had memory issues causing the container to crash or if it was a failed attempt at --mssfix

[rcdailey]

Any objection to making --mute-replay-warnings a default option for OpenVPN within the container itself? This would at least avoid confusion, redundant issues being filed, and make your container more of a turn-key solution. It minimizes additional environment configuration. And it doesn't hurt to always have it.

[haugene]

I think we should. Most people want the turn-key solution. Convention over configuration 👍
We should however document a section on what choices are being done for the users by default. That is like chmod and chown'ing the data directory -etc.

Been meaning to rewrite the README to be a bit more concise and "to the point" and move more stuff into a wiki and expand on some frequent caveats.