TLS Error: incoming packet authentication failed from



  • Sorry to bother you guys with this old issue, I have read through everything I could find in Google and I am having trouble figuring out how to implement the solution:
    I am getting the errors in the OPENVPN log of:
    07:11 openvpn[31232]: 192.168.1.197:60461 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #38 / time = (1373728027) Sat Jul 13 08:07:07 2013 ] – see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
    Jul 13 08:07:11 openvpn[31232]: 192.168.1.197:60461 TLS Error: incoming packet authentication failed from 192.168.1.197:60461
    Jul 13 08:07:11 openvpn[31232]: 192.168.1.197:60461 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #37 / time = (1373728027) Sat Jul 13 08:07:07 2013 ] – see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

    In my client I have:
    dev tun
    persist-tun
    persist-key
    proto udp
    cipher AES-256-CBC
    tls-client
    client
    resolv-retry infinite
    remote 161.4.7.3 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 www.mysite.com
    comp-lzo
    pull
    verb 3
    key-direction 1
    ping 10
    nobind

    On the server, I've tried:
    push "redirect-gateway def0
    and/or tls-auth nehwon-upd-1194-tls key 0
    and even: key-direction 1

    I've been at this for day and just can't figure out what I am doing wrong, a clue please? What am I missing to get rid of this error?

    Thanks very much!



  • 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
    nobind

    I 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.



  • @kejianshi:

    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?



  • @kejianshi:

    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.  ::)


  • Banned

    @kejianshi:

    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.