[Solved] TLS Error

eleanor

Hi,

I've configured my OpenVPN server and I'm connecting to it with the following config:

dev tun
persist-tun
persist-key
cipher AES-256-CBC
tls-client
client
resolv-retry infinite
remote <IP>1194 udp
ns-cert-type server
auth-retry interact
pkcs12 user.p12
tls-auth user-tls.key 1
comp-lzo
script-security 2
up /etc/openvpn/up.sh
down /etc/openvpn/down.sh

Where the <IP> has to be replaced with an actual WAN IP. Everything works ok, but sometimes the connected VPN client justs starts to produce these warning messages:

Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2 / time = (1386173047) -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
TLS Error: incoming packet authentication failed from [AF_INET]<IP>:1194

I cannot reach the services over the VPN tunnel, because obviously the VPN client cannot reconnect for whatever reason.

Can somebody tell me what happens? I have normal internet connection, but VPN just wouldn't work and the error messages above are reprinted until I manually disconnect and reconnect the VPN tunnel? But this is annoying to do every couple of hours, so I would like a solution where it can reconnect without problems and errors.

Any thoughts?

eleanor

I'm asked to reenter the password when I try to reconnect, not when this starts happening. I'm using gnome keyring, which remembers the password:

/usr/bin/gnome-keyring-daemon --start --components=secrets

Is it possible that it simply deleted the password from memory and I have to reenter it, but it never pops-up an input box to actually do that. Instead what I'm left with is no password in memory and no popup asking me for password an therefore the daemon cannot reconnect until I manually disconnect/reconnect?

eleanor

After I manually reconnect the following things are the same as before the re-connections (when the vpn tunnel doesn't work):

routing table
/etc/resolv.conf
opevpn process

But when doing dig, I get the following packets when tunnel is not working:

# dig @10.1.1.1 git
17:31:22.336393 IP 10.1.1.6.56185 > 10.1.1.1.domain: 44727+ A? git.mydomain.local. (41)
17:31:22.336408 IP 10.1.1.6.56185 > 10.1.1.1.domain: 17958+ AAAA? git.mydomain.local. (41)
> nslookup: couldn't get address for 'git': not found

You can see that the dig retries the DNS requests without getting the response; this happens because the 10.1.1.1 is not even reachable. And after I re-connect when the tunnel is working:

# dig @10.1.1.1 git
17:35:21.007813 IP 10.1.1.6.36690 > 10.1.1.1.domain: 4985+ [1au] A? git. (35)
17:35:21.010586 IP 10.1.1.1.domain > 10.1.1.6.36690: 4985*$ 2/0/0 A 10.1.1.2 (56)
> ;; ANSWER SECTION:
> git. 1 IN A 10.1.1.2

As you can see the DNS request works now. This means that the tunnel is presented as established, but isn't actually working, so there must be problem with reconnecting right?

Any more thoughts on what to change, so that the VPN is automatically reestablished?

eleanor

Hi, I administer both the client and the server.

eleanor

Hi,

It seems that it works now, which means that client tries to reauthenticate without prompting for username/password; and since it already has the password in memory, it is able to do that right?