OpenVPN Message Authenticate/Decrypt packet error

Virtual Private Networks
1

hello everybody,

now and then i get a about 25 messages in ipfire /var/log/messages like this:

Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #144311 ] – see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

the vpn connection (road warrior) seems to works fine and the windows 2019 host (client) can reach the ipfire as well the other windows 2019 server behind the ipfire.

i googled a lot, but honestly i do not understand whats going wrong. some says that message can be ignored, other says this might be a security issue… does anyone have a explanation or a solution tipp for me?

thanks

2

Hi @xiam

Another reason for this type of message that I have found in my searches is related to an incorrect MTU size.
Have you changed the default MTU value in the OpenVPN server?
Are you using UDP or TCP for the protocol?

3

Hi @bonnietwin

the MTU size is set to 1400 (default value). So no I do not have changed the MTU size. At client side ovpn config the MTU size is set to 1400 too.

I am using UDP as protocol.

4

Then the MTU is not the cause of the messages you are getting.

Sorry, I don’t have any other ideas.
Hopefully others will have more ideas.

5

@bonnietwin thanks anyway for your help. I hope others can give me a hint

6

Take a look at Setting correct MTU for OpenVPN | Magento Hosting by Sonassi

Mine seems to work at 1460

7

I know this is quite an old thread, but I also got a mountain of similar errors yesterday. After some internet searching, I stumbled across this thread.

Here’s a small batch of the errors:

Sun Dec 31 23:10:47 2023 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #84 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sun Dec 31 23:10:49 2023 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #106 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sun Dec 31 23:10:50 2023 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #114 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sun Dec 31 23:11:02 2023 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #425 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sun Dec 31 23:11:05 2023 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #458 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Luckily, I was able to test connecting to my VPN from a neighbour’s Wi-Fi, which produced no errors at all. After some head scratching, I rebooted my router and the errors immediately stopped!

The errors were occurring in the client side logs, so a little different to the original poster, but might be related in some way.

8

I have done some fresh searching on this issue and also read through the replay sections of the openvpn man page.

Every time a packet is sent by the tls-auth process that authenticates the openvpn control channel a unique ID is assigned to that packet.
If OpenVPN receives a packet with the same ID as one already received then it drops the new packet as it considers that that packet is being replayed and this could be due to a MITM (Man In The Middle) attack.

So the messages are indicating that those replayed packets have been dropped. So from that point of view security is maintained because if a MITM attack is being attempted then those attempts are just dropped.

Any MITM attack via the tls-auth, even if it was successful, would then need to find a way to decrypt the data channel traffic.

According to the OpenVPN man page replay warnings are also a common false alarm on wifi networks.

Apparently some router systems on the internet do not follow the requirements of not resending any packet that has been received by the next hop. so those systems can end up resending packets that have already been received and if those are openvpn tls-auth packets then the ID will be duplicated and will trigger the action to drop the packet and give you the log message.

I suspect that this was what you experienced.

When you tried with your neighbours connection then the route was a different one and not using systems that resend already received packets.

When you rebooted your IPFire then the connection with your ISP will have been re-made and any existing routing tables they had cached would have been renewed and now not using systems on the internet that resend already received packets.

I can’t be 100% certain of the above but the two reasons I found for getting those messages are

  1. MITM attack being attempted but all attempts dropped by openvpn
  2. Poorly configured Routers on the internet resending packets that have already been received.

which are covered by the above.

The positive thin g is that the messages are telling you that you have been protected because the duplicate packets have been dropped.

2 Likes