TLS Error: incoming packet authentication failed from
-
try mysite.com in tls remote site. Try dropping the www.
And put the same thing behind remote, instead of the IP. (This part shouldn't matter so much or break anything unless your DNS resolver is broken). -
Thanks for the reply, same thing.
So now I have on the client:
dev tun
persist-tun
persist-key
proto udp
cipher AES-256-CBC
tls-client
client
resolv-retry infinite
remote mywebsite.no-ip.info 1194
auth-user-pass
auth-nocache
ca RoadWarrior-CA.crt
pkcs12 servername-udp-1194.p12
tls-auth servername-udp-1194-tls.key 1
tls-remote mysite.com
comp-lzo
pull
verb 3
key-direction 1
ping 10
nobindI am not sure what to put in the server. BTW the no-ip.info is a dynamic DNS like DyDNS, it finds my DHCP addressed IP from my IPS.
Thanks again!
-
Hmmmmm. This is all setup from the pfsense openvpn panel right?
I assume you are exporting a client using client export? Which type of client?
Can you post a screen grab directly from the openvpn setup menu?
-
and, my appologies. I didn't know you were using a free DNS service.
You will need to make it mywebsite.no-ip.info in tls remote also.
-
Did as you asked, same issue.
I am using the OpenVPN android app.
-
Hmmmmm. This is all setup from the pfsense openvpn panel right?
I assume you are exporting a client using client export? Which type of client?
Can you post a screen grab directly from the openvpn setup menu?
Yes, I used the PFSense OPENVpn system.
I am able to connect, it just throws these errors.
-
Ahhhhh - "The" Android app…
Whats the name of your particular android app?Check in your "my apps" and give the exact name pls.
And what is your android version? -
I was using VEAT and that was working fine.
I decided to use the openvpn connect client from openvpn.org, https://play.google.com/store/apps/details?id=net.openvpn.openvpn&hl=en
I am running 4.1.2 android.
-
I use openvpn connect on the same version of android. Works.
If your config was working on VEAT with the export client built into pfsense, and you used the client export utility built into pfsense, it should work. Don't forget at the top to either type in or click/select correct IP address before you press the export button.
I click "other" and type in the mysite.no-ip.info for me.
I have exported the Android and OpenVPN Connect (iOS/Android) and they both seem to work well for me, but try both.But, before you do that, check your installed packages
system > packages >installed packages in pfsense.
If there is an update to the client export utility, then click the reinstall button "pkg" first. Then try.
There have been a couple changes in the last day or so. -
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.