Need help: Clients getting disconnected

tombodet

I've got a newly built CentOS 6 64bit server running OVPN 2.2.1. It's tied to Active Directory for authentication. We're using a single key currently, plus a tls auth key.

Right now it's only in testing with two remote users. They connect just fine and can operate for some time and then in the middle of working they'll get asked to re-authenticate.

SERVER

local x.x.x.x

port 1194

proto udp

dev tun

ca <capath>
cert <cert path>
key <keypath

dh <2048 bit key file>

server 192.168.20.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "dhcp-option DNS x.x.x.x"
push "route 192.168.55.0 255.255.255.0"

client-to-client

duplicate-cn

keepalive 10 120

tls-auth <key file> 0

cipher AES-256-CBC   # AES

comp-lzo

max-clients 100

user nobody
group nobody

persist-key
persist-tun

status openvpn-status.log

log-append  /var/log/openvpn.log

verb 6

mute 10

script-security 3

auth-user-pass-verify /etc/openvpn/auth/openvpn-super.pl via-env
client-connect /etc/openvpn/auth/openvpn-super.pl

auth-nocache
cipher AES-256-CBC
auth SHA512
opt-verify

CLIENT

proto udp

dev tun

dev-node vpn

ca <ca file>
cert <server cert>
key <shared key>

remote server.address.com 1194

tls-auth <keyfile> 1 

cipher AES-256-CBC   

comp-lzo

resolv-retry infinite

nobind

verb 3

;mute 20

--auth-user-pass

auth-nocache
auth SHA512

Did I misread a setting on something and this is expected based on my config or is something else weird going on here? I'm not seeing anything that looks like an error. From one user I did manage to find a P_CONTROL_HARD_RESET_SERVER_V2 about 30 seconds before he reconnected but searching on that gives me a phonebook of answers that I don't even know where to begin looking. The other user's reconnect looks like a plain auth.

We're stable on an older version of OVPN on an older box but we're trying to upgrade everything. This random re-auth has me hesitant to move more people in.

Thanks for looking and your time.

maikcat

hi there,

in your client config

cert <server cert>
key <shared key>

are you using the SAME cert for server & client?

ps: posting cert names is not dangerous to you in any way,posting the CONTENTS of them is a threat..

Michael.

tombodet

Sorry maikcat I guess I'm just highly paranoid.

No I'm not the file names are:

ca ca.crt
cert server.crt
key server.key

The server.crt was self generated based on the server.key.

The only files that are the same everywhere are the ones the clients are using; the same key/cert pair until I get a proper cert request system in. It's only a dev environment with limited users so it's not high on my list and I'll be cycling that pair on a yet to be determined basis.

tombodet

I can't be sure yet but I got one of the clients to give me a log file.

Looks like the TLS reneg is tripping up:

Mon Aug 06 09:50:43 2012 Initialization Sequence Completed
Mon Aug 06 10:50:31 2012 TLS: soft reset sec=0 bytes=250987949/0 pkts=263016/0
Mon Aug 06 10:52:08 2012 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Aug 06 10:52:08 2012 TLS Error: TLS handshake failed
Mon Aug 06 10:52:08 2012 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1

That's the end of the signon at 9:50, then the default TLS reneg at 10:50 which then fails. She sent me a copy of the log once she got the disconnected message and it only contained the soft reset line. When I asked for another copy you see the Error almost 2 min later.

The server log is identical (minus the timediff)

Mon Aug  6 09:58:43 2012 us=232852 <client IP>:4594 TUN WRITE [40]
Mon Aug  6 09:58:43 2012 us=285693 <client IP>:4594 NOTE: --mute triggered...
Mon Aug  6 10:47:39 2012 us=422129 <client IP>:4594 524915 variation(s) on previous 10 message(s) suppressed by --mute
Mon Aug  6 10:47:39 2012 us=422327 <client IP>:4594 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Aug  6 10:47:39 2012 us=422355 <client IP>:4594 TLS Error: TLS handshake failed
Mon Aug  6 10:47:39 2012 us=422370 <client IP>:4594 TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1

What's next on troubleshooting this? I'm not sure upping the reneg time is a good option; I'd like to figure out why it's not performing correctly.

ETA: I just tried this on a test laptop at my desk. 60 minutes later I got prompted for authentication. Is the renegotiation supposed to trigger a user pw prompt? The way the old outgoing vpn is set up, is user key password protected only. This system is a generic user key with AD authentication under it. Is this a byproduct of the reneg or should it be transparent to the user?

tombodet

OK someone confirm this for me.

I think I just realized the problem.

I have --auth-nocache set. So when the TLS reneg comes along it doesn't have any cached credentials so it prompts for the user. Yes?

If so...I need to either dump the --auth-nocache or increase the --reneg-sec to something a little less annoying than every hour.

maikcat

I have --auth-nocache set. So when the TLS reneg comes along it doesn't have any cached credentials so it prompts for the user. Yes?

yeap...

--auth-nocache
Don't cache --askpass or --auth-user-pass username/passwords in virtual memory.

If specified, this directive will cause OpenVPN to immediately forget user‐
name/password inputs after they are used. As a result, when OpenVPN needs a user‐
name/password, it will prompt for input from stdin, which may be multiple times
during the duration of an OpenVPN session.

This directive does not affect the --http-proxy username/password. It is always
cached.

If so...I need to either dump the --auth-nocache or increase the --reneg-sec to something a little less annoying than every hour.

also yes...

its very nice to watch people to answer their own questions 😃

Michael.