just started to use a vpn. tried Airvpn and was pretty nice but speeds were not as good as PIA is giving me.
being that PIA uses Openvpn, (as well as airvpn) i have been getting large log files with the line being spammed
Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #245700 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
this happen's only when using a BitTorrent client. Right now i use BitTorrent but i've also happens with deluge. i have a 35 down 5 up connection and i live in the middle of know where so it stays at this speed 99% of the time. was testing out the speeds of the vpn with a ubuntu ISO torrent. speeds were hitting 3.2 megabytes down but with the vpn off i can hit the 35 down my isp provides easy. (which is around 4.3 megabytes ps. not sure if that speed that im loosing is because of that error im getting or if its just the overhead i have to accept from using a vpn?
my settings for the vpn are udp, remote port is auto data encryption is aes-128, data auth is SHA1, and handshake is RSA-2048.
if i use tcp instead of udp, i dont get this error in the log file anymore but my connection keeps dropping. if i disable data encrytion and data auth while using tcp, i have no connection issues and my log file is not being spammed.
Are you running this on openvpn or the PIA client? If it's openvpn you could try playing around with the replay-window option and see if increasing it helps.
This is from the man page:
--replay-window n [t]
Use a replay protection sliding-window of size n and a time window of t seconds.
By default n is 64 (the IPSec default) and t is 15 seconds.
This option is only relevant in UDP mode, i.e. when either --proto udp is specified, or no --proto option is specified.
When OpenVPN tunnels IP packets over UDP, there is the possibility that packets might be dropped or delivered out of order. Because OpenVPN, like IPSec, is emulating the physical network layer, it will accept an out-
of-order packet sequence, and will deliver such packets in the same order they were received to the TCP/IP protocol stack, provided they satisfy several constraints.
(a) The packet cannot be a replay (unless --no-replay is specified, which disables replay protection altogether).
(b) If a packet arrives out of order, it will only be accepted if the difference between its sequence number and the highest sequence number received so far is less than n.
(c) If a packet arrives out of order, it will only be accepted if it arrives no later than t seconds after any packet containing a higher sequence number.
If you are using a network link with a large pipeline (meaning that the product of bandwidth and latency is high), you may want to use a larger value for n. Satellite links in particular often require this.
If you run OpenVPN at --verb 4, you will see the message "Replay-window backtrack occurred [x]" every time the maximum sequence number backtrack seen thus far increases. This can be used to calibrate n.
There is some controversy on the appropriate method of handling packet reordering at the security layer.
Namely, to what extent should the security layer protect the encapsulated protocol from attacks which masquerade as the kinds of normal packet loss and reordering that occur over IP networks?
The IPSec and OpenVPN approach is to allow packet reordering within a certain fixed sequence number window.
OpenVPN adds to the IPSec model by limiting the window size in time as well as sequence space.
OpenVPN also adds TCP transport as an option (not offered by IPSec) in which case OpenVPN can adopt a very strict attitude towards message deletion and reordering: Don't allow it. Since TCP guarantees reliability,
any packet loss or reordering event can be assumed to be an attack.
In this sense, it could be argued that TCP tunnel transport is preferred when tunneling non-IP or UDP application protocols which might be vulnerable to a message deletion or reordering attack which falls within the
normal operational parameters of IP networks.
So I would make the statement that one should never tunnel a non-IP protocol or UDP application protocol over UDP, if the protocol might be vulnerable to a message deletion or reordering attack that falls within the
normal operating parameters of what is to be expected from the physical IP layer. The problem is easily fixed by simply using TCP as the VPN transport layer.
--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.
Add replay-window 64 20 (or something like that, not sure the exact syntax) to your config file. Or add mute-replay-warnings if you just want it to stop logging the errors.
Seems the problem is an issue with sending UDP traffic (torrents) over a UDP tunnel with possibly high latency (being in the middle of nowhere) which is causing packets to arrive out of order and late which triggers the warning.
Increasing the time used in the replay window should fix the problem or you could disable it completely by adding no-replay to the config.
If you're using a gui and not just a config file then add any options to the advanced options section. Separated by a semi colon.