multiple clients with same cert leads to problems

[jhaar]

Hi there, Steffan Karger said to put the ticket in

I've got a corner case I've picked up during testing that makes me
wonder if there's a bug in openvpn

Our openvpn server "tests" incoming clients to ensure they comply with
our openvpn client standards - killing their session if they don't
(basically client-less NAC).

One thing we're doing is allowing "duplicate-cn", but using our NAC test
to reject clients using the same cert (get better logging of the
offenders that way). Anyway, I have a Mac and Windows box set up to use
the same cert to test this, and it causes an interesting situation...

First client connects, second client connects, NAC script notices the
same cert in use and kills the first connection. Second client later
hangs up. If I then look at the first client hours later, it still
thinks it's logged in! There is no error, it still has the tun interface
up, but no traffic flows. The server shows no connection via either
client (I use the management api to confirm that)

We use "--ping", and tcpdump confirms the first client and server are
still exchanging packets - but the server does not classify the client
as being connected. But as the openvpn pings are still working, the
client doesn't know it's actually disconnected. A simple "kill -HUP" on
the client fixes everything as it forces a full restart

So I have two questions:

1. The client uses "explicit-exit-notify" - but it looks like using the

kill management command on the server does not tell the client it is
hanging up? Wouldn't that be a good idea?

2. The fact that ping is still working makes me think that means ping

must be *separate* from session management? Isn't that a bad idea?

Hopefully I'm wrong and someone will tell me I'm doing it incorrectly

server is 2.3_git, and this is over UDP of course (I doubt this is an
issue over TCP, although I haven't tested)

[Samuli Seppänen]

Seems like a bug to me. We might want to bring this up with James in a meeting.

[Antonio Quartulli]

@samuli has this ever been discussed/checked/deepened any further?

[David Sommerseth]

It would be good to test this again on a recent 2.4 and git master. The test script should be easy enough:

• server with management interface enabled plus --ping 5
• client connects using plain certificate authentication
• observer the tcp/udp link with tcpdump/wireshark
• server sends 'kill' to the client
• client tries to send ICMP ping over the tunnel

Via tcpdump it should be possible to see the control channel pings, approx each 5th second.
What happens after the 'kill' has been sent? Both on the data and control channel.

This smells kind of like only a partial session removal; where the control channel aspect of the tunnel is still valid - while the data channel is invalidated.

This could also be tested using an OpenVPN 3 client as well, to see if that behaves differently.

[tct]

I can try to replicate this some time.