Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decapsulate error InvalidCounter (not a huge problem, just curious why it happens and whether I should worry) #357

Open
LindaFerum opened this issue Aug 12, 2023 · 2 comments

Comments

@LindaFerum
Copy link

I run boringtun-cli based configuration.
It works and works very good so far.

However, the stdout from boringtun-cli running in foreground (default verbosity, just keeping eye on it) shows

Decapsulate error InvalidCounter

About 10-20 new errors per hour.

It does not appear to degrade connection or anything.

What is this error and should I be concerned?

@Noah-Kennedy
Copy link
Collaborator

CC @jeff-hiner

@jeff-hiner
Copy link
Contributor

The Wireguard implementation relies on packets being sequentially numbered. These packets should fall within a "window" in order to avoid replay attacks. The window is adjusted as new packets arrive, allowing for packets to arrive out of order, within some given errormargin. If the decapsulation engine sees a packet with a number outside the expected window it refuses to decapsulate it, and returns InvalidCounter. Assuming the packet was valid in its original context, this essentially drops the packet.

If this happens occasionally it's not fatal, as IP is designed with packet drops in mind. The transmitting end will likely re-send the packet as a DUP if it's part of a TCP flow or otherwise issue some sort of retry. If you're worried about it, you can try expanding the window size to see if it decreases the number of errors. This has a minor effect on memory consumption, but it should be negligible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants