VPN clients suddenly won't connect to server

[jcarrra]

Server is the built-in in Firmware:378.56_2 in an AC-68U.
Clients are OpenVPN Connect app in android phone and a tablet.

--These formerly worked (connected). Had not used for awhile.
--Tried, now won't connect.
--Saw that home WAN IP shown in the UI of AC68 for the modem had changed. (This has happened several times before.)
--Simple fix always has been to put the new server IP (remote) in the client ovpn's--everything starts working.
--Does not restore working this time--seems to be a TLS issue of some sort.

Anyone see the fix?
-----------------------------
logs and config
Server log

Nov 22 20:24:09 openvpn[787]: MULTI: multi_create_instance called
Nov 22 20:24:09 openvpn[787]: 192.168.1.227:36393 Re-using SSL/TLS context
Nov 22 20:24:09 openvpn[787]: 192.168.1.227:36393 LZO compression initialized
Nov 22 20:24:09 openvpn[787]: 192.168.1.227:36393 Control Channel MTU parms [ L:1558 D:166 EF:66 EB:0 ET:0 EL:3 ]
Nov 22 20:24:09 openvpn[787]: 192.168.1.227:36393 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:143 ET:0 EL:3 AF:3/1 ]
Nov 22 20:24:09 openvpn[787]: 192.168.1.227:36393 Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Nov 22 20:24:09 openvpn[787]: 192.168.1.227:36393 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Nov 22 20:24:09 openvpn[787]: 192.168.1.227:36393 Local Options hash (VER=V4): '0b024030'
Nov 22 20:24:09 openvpn[787]: 192.168.1.227:36393 Expected Remote Options hash (VER=V4): '5b243d85'
Nov 22 20:24:09 openvpn[787]: 192.168.1.227:36393 TLS: Initial packet from [AF_INET]192.168.1.227:36393, sid=2a25259c e6fca2ca
Nov 22 20:24:11 openvpn[787]: 192.168.1.227:36393 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1479864187) Tue Nov 22 20:23:07 2016 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Nov 22 20:24:11 openvpn[787]: 192.168.1.227:36393 TLS Error: incoming packet authentication failed from [AF_INET]192.168.1.227:36393
Nov 22 20:24:13 openvpn[787]: 192.168.1.227:36393 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1479864187) Tue Nov 22 20:23:07 2016 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Nov 22 20:24:13 openvpn[787]: 192.168.1.227:36393 TLS Error: incoming packet authentication failed from [AF_INET]192.168.1.227:36393
Nov 22 20:25:09 openvpn[787]: 192.168.1.227:36393 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Nov 22 20:25:09 openvpn[787]: 192.168.1.227:36393 TLS Error: TLS handshake failed
===================
client log hard to get copy--in phone and tablet...no bytes ever received from server
basically it shows try, waiting and retry

===================
client ovpn

client
dev tun
proto udp
remote xxxxxx 1194
float
cipher AES-256-CBC
comp-lzo adaptive
keepalive 15 60
auth-user-pass
ns-cert-type server
<ca>
-----BEGIN CERTIFICATE-----
deleted
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
deleted
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
deleted
-----END PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
deleted
-----END OpenVPN Static key V1-----
</tls-auth>
resolv-retry infinite
nobind

 

[jcarrra]

Did I leave something out I should have posted?
No help.

 

[martinr]

To narrow it down, I'd go into the advanced settings for the OpenVPN server on your router and I'd set username/password auth only to Yes, thereby bypasing the public key infrastructure (certs and keys) authentication and just prove you can then connect remotely.


One thing I don't understand - and it's probably me rather than your explanation:

"-Saw that home WAN IP shown in the UI of AC68 for the modem had changed. (This has happenedseveral times before.)"

You mean your public IP address changed? But unless your ISP has given you a fixed IP address, will it not be constantly (eg daily) changing? Hence dynamic DNS? Could you clarify this bit please?

 

[jcarrra]

To narrow it down, I'd go into the advanced settings for the OpenVPN server on your router and I'd set username/password auth only to Yes, thereby bypassing the public key infrastructure (certs and keys) authentication and just prove you can then connect remotely.

One thing I don't understand - and it's probably me rather than your explanation:

"-Saw that home WAN IP shown in the UI of AC68 for the modem had changed. (This has happenedseveral times before.)"

You mean your public IP address changed? But unless your ISP has given you a fixed IP address, will it not be constantly (eg daily) changing? Hence dynamic DNS? Could you clarify this bit please?

Thanks.. I will try what you suggest in a bit, but I have to drive to a foreign wifi point with the client to test..cannot be "ON" the same router as the server when testing--doesn't ever work that way.

And yes, public IP (WAN IP) changed. I am on dynamic public, but with our ISP, it rarely changes. They charge an arm and a leg to give us a static address. Had a recent service update and that apparently kicked in an IP change.

ADDED: remembered I can tether on of the clients and make it a hotspot then use the other one (tablet) to test. Changed to name/pass only and tried, but even though 1st try passed bytes, never achieved a connected state. All subsequent tries are as before...no bytes coming to client from server.

What's the easiest way to create a new "Static Key" (that IS what TLS uses isn't it?) and just put that into server side and the clients, and try that?

 

[jcarrra]

continuing...
I looked in web search articles and found how to create a ta.key file..
openvpn --genkey --secret ta.key
and text to server "Static key" block and to the client ovpn
<tls-auth>
key-here
</tls-auth> section.

...and it CONNECTS!

Weird that key got 'bad' somehow as I had done NO editing of server side at all, and in client one, only changed the IP at the top of the text.

 

[martinr]

I can't pretend I understand it, but I'm glad you got there in the end.

Just one thing worth double checking with you, though I can't see how you can have got this far without being aware of it: the file you are editing must be edited in Unix/Limux format, which ensures no carriage returns (CR) get added at the end of the line as would happen with a Windows text editor. So you can't use Notepad (not without causing problems), if you are editing in Windows, but you could use a text editor such as Notepad++ set to Unix formatting.

 

[jcarrra]

Problem solved, but this new angle is interesting...
work is done on Windows machine. Editor is Notetab Lite--sometimes paste into notepad for temp storage. Clients are android devices.

This has worked for 3 years with no problems I could ever detect from files created in those editors

Just found this on another forum..."The editor i always use with client.cfg is notetab lite - www.noteab.com.
It displays the file in a readable way and respects the unix linefeed format." Maybe I just lucked out with editor choice.