TLS Error: incoming packet authentication failed from
-
Like I said, it is working just fine. I am just getting these errors. I connect just fine.
-
Are you inside or outside the LAN that your pfsense is on when you get that error?
-
Are you inside or outside the LAN that your pfsense is on when you get that error?
Both.
-
I ALSO get that error inside the LAN, maybe caused by NAT reflection, but I get no error if I'm using it across my cell phones data plan. (No wifi)
-
And now the error is gone and won't reproduce again, but was there a few minutes ago.
The purpose of that is to basically let you know if someone is possibly faking your identity, which would be an issue if it were not your IP involved here. If the IP were one that you didn't recognize to not be yours or at a time when you were not online, then someone is faking your creds to login. In my case, its my IP and its me, so false alarm.
A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack by IP packet substitution (such as stream cipher attack).
-
I read through the openvpn release logs. There are several changes affecting "replay".
Seems that replay false alerts are common on wifi across the board.
Also see that in the latest version there is a reference to "Added more packet ID debug info at debug level 3 for debugging false positive packet replays."
I would check the network originating the replay and the time to verify if its true or not. -
Well, even if rerunning the package installer had fixed the problerm, I would rather find out what in my client or server scripts is causing it just so I know.
Kinda like calculators, I am not above using one as long as I know what the formulas are just for my education.
-
My thoughts on the matter are this.
One - Thanks for bringing it up.
Two - I suspect openvpn is supressing the error. Like not letting it affect anything.
Three - I do not like that if its the case because if "replay" is being allowed as default and all its doing is throwing a log entry but its still connecting, thats BAD. I would not want replayed connection being allowed at all as it seems to me that it defeats alot of the reason you would want to use a vpn for to begin with as UDP is particularly susceptible to replay attack without replay detection and protection.So, this begs the question, is the default installation of openvpn on pfsense defaulting to "no-replay" or not?
And if so, why? I'd think its a pretty big deal.I'd want it default to no-replay with maybe a radio button to enable/disable if its a problem for occasionally breaking connections.
-
I know it's some client interaction.
I had to go to a new version of FEAT and add on the server push "redirect-gateway def0
However the error came back when I went to openvpn client.
Like to know what it is causing it and how to really fix it.
-
The thing that bothers me is not that you got the error or that its caused by this or that version of client software.
The thing that bothers me is that you get a "replay attack" detected and it goes ahead and authenticates the connection and works.
I MUCH prefer that any replay detected throw a log error and break the connection immediately.I saw that "float" could be used on the client config to stop these error message in site to site VPN setups.
Perhaps if you try that? (even though yours isn't site to site)
Its been used when people have routers or switches that are messing things up a bit. -
I read about float too but it looks more like covering the symptom than fixing the issue.
I will wait with that one and see if any of the OPENVPN experts maybe stops in and has a fix for the base issue than just suppressing the issue warning.
Hopefully a OPENVPN expert shows up.
-
Still having found an answer to this one, if I figure it out I will post a solution.
If any of your have an answer, I am still looking.
I know it isn't a hard down, but I like having a clean log,
-
Supposedly it means someone is trying a replay attack on your VPN. That I'm sure you knew.
I have seen that error, but the day I saw It in my logs I was using my VPN down near the White House.
Maybe thats just nothing, or maybe its something. I don't know.
I haven't seen that error again but I haven't fired up the VPN in DC since then either.
I suppose to reproduce the error I could go stand outside the Pentagon on VPN and see if it pops up again. ::) -
I suppose to reproduce the error I could go stand outside the Pentagon on VPN and see if it pops up again. ::)
You're on the "no fly" list now, so I guess that might take some time to get back there. :P
-
I wouldn't need to fly there. I can take a walk there… Or ride a bicycle. But the Metro is quicker.
Now, the real question is why the heck would I want to spend more time there than absolutely necessary?
I do like Dupont Circle from time to time, but its hardly Gangnam. DC is boring.
(I was being FORCED to parade around museums AGAIN by yet ANOTHER visiting friend or I wouldn't have been there.)
It just hit me when I checked my logs to compare notes with Honeybadger that the only time I've seen that error I was in DC.
If someone did manage to overheat a mainframe and chew through that particular VPN they would be rewarded with a tunnel that just goes back to the internet and no where else. Quite an accomplishment. I will be turning it on again next time I go to see if it happens again though.