OpenVPN connection on unmapped port, UNDEF user, persistent respawning?

Porter · Sep 19, 2011, 9:01 PM

I'm having a very odd issue with OpenVPN, I have an OpenVPN server instance set up on pfSense for some external contractors to get through to an internal dev server here, using a combination of SSL/TLS and User auth. I have a rule set up to pass traffic specifically to and from the box they need to access. Normally I see them when connected, the dashboard shows their user account and the connection on the correct OpenVPN port. This has been working fine for ~2 months.

Now, suddenly today I have a persistent connection on that OpenVPN server instance, on a very high port (in the 15000 range) connecting as user "UNDEF" which I suppose means undefined. Now, I've tested this thing myself and it doesn't allow connection without the user auth even if the keys are there. So, I killed the client connection… and it immediately respawned. I killed it again, it respawned again. So of course I stopped the OpenVPN service.

What gives? Has anyone else had this or similar issue with OpenVPN on pfSense 2.0?

Porter · Sep 20, 2011, 2:01 PM

Well, it turns out it was a valid connection from one of the external contractors, but the OpenVPN dashboard wasn't reporting it as his account, and it wasn't on the port that's assigned for OpenVPN.

Is the OpenVPN daemon able to autonegotiate reconnect to a client using a non-assigned port? If so, why?

jimp · Sep 26, 2011, 2:41 PM

If it tries to connect to that port, then that port is in the client config.

If it shows "undef" generally that means it's connected but not fully authenticated. (e.g. sitting there waiting on a username/password prompt.)

Porter · Sep 26, 2011, 2:56 PM

@jimp:

If it tries to connect to that port, then that port is in the client config.

If it shows "undef" generally that means it's connected but not fully authenticated. (e.g. sitting there waiting on a username/password prompt.)

Gotcha. That makes more sense, though it's not completely clear why it does this on a high random port rather than the designated connection port.

jimp · Sep 26, 2011, 3:21 PM

You may be seeing the clients randomized source port, not the server's listening port.