OpenVPN "TLS cannot locate HMAC" UDP only

Discussion in 'Tomato Firmware' started by WillyTP, Jan 12, 2018.

  1. WillyTP

    WillyTP Connected Client Member

    Hello everybody.
    I'm running Tomato since several months now, now with latest Kille72's 2017.3 version.

    Since a few days I'm experiencing a weird issue.
    With OpenVPN, 100% working configuration, all same keys / data ecc ecc (tried all from scratch too),

    when I try to connect via TCP, everything works fine

    when I try to connect via UDP, I always get the following error:
    TLS Error: cannot locate HMAC in incoming packet from [AF_INET6]

    The only thing changed in the last time is my mobile network operator
    (I connect from smartphone to my home VPN)
    Could be this? My mobile operator doing something to UDP packets?!

    Any ideas?
    Changing UDP port makes no difference.
    Only way to make UDP working is to disable "Extra HMAC authorization".

    Last edited: Jan 12, 2018
  2. pomidor1

    pomidor1 Networkin' Nut Member

    Port Forwarding / UPnP/Nat-PMP on
    etc. UPnP on
  3. eibgrad

    eibgrad Network Guru Member

    What are we talking about here? OpenVPN client, OpenVPN server? Which side is producing the error? Your description is just too vague in this regard. Just saying "OpenVPN" isn't enough.
  4. koitsu

    koitsu Network Guru Member

    The error in question has literally nothing to do with UPnP or NAT-PMP. The advice given there is 100% irrelevant.

    eibgrab's comment is spot on. Though, this is really a question for the OpenVPN folks and not Tomato.

    You need to make sure that the majority of things between client and server configuration match, barring a couple differences.

    The error in question pertains to IPv6 packets (that's what AF_INET6 refers to). You may want to try using IPv4 exclusively instead, if possible, and see if the problem goes away. ISP or someone may be rewriting IPv6 packets, or it could be a bug.

    Another thing I read was, when using tls-auth, to check key-direction in both server and client. It needs to come after your <tls-auth> ... </tls-auth> section (reference for this, and the commit that fixed it), and set to 1 on the client and 0 on the server. It CAN be reversed (1 on server, 0 on client), but AFAIK you don't want 1 on both (this would be the equivalent of bidirectional HMAC verification) or 0 on both.

    If you aren't using tls-auth, then you shouldn't be seeing this error message at all.

    Some other reading material: -- note that in this post, someone says to use tls-auth keyfile 0 on server and tls-auth keyfile 1 on client (note the appended numbers), but later in the thread this is debunked as wrong/bad syntax and that key-direction [0|1] is what dictates things.

    Welcome to what happens on the Internet when people don't post full/complete details -- everyone else having a similar problem has to make (bad) assumptions and nobody in the end concretely knows what the problem is. :/

    Good luck, I can't help past this point.
    Last edited: Jan 29, 2018
    Monk E. Boy, kille72 and Justio like this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice