OpenVPN client unable to connect

dbennett

Greetings,

Start by saying I've been configuring and using OpenVPN now for almost 2.5 years now and REALLY like it! SOO… I'm thrown by this one.

A while back, I created a config using port 1198. Worked Great! Then about 3 weeks later the firewall ran into some issues and eventually crashed and when it came up the OpenVPN didn't work. Worked on it a bit then decided to scrap the config and start over. When I rebooted the firewall, the OpenVPN Dashboard shows 1198 in error; Unable to contact daemon. is the service running? Checked the service and sure enough it won't start. The kicker is that after I restarted the firewall again, It started to work, BUT the same errors occur on the dashboard and the service shows that it won't start.

I created another port, one that hasn't been used before (1194) and it worked fine. Just today though I am trying to create another OpenVPN server on the same firewall using port 1195 and it just won't work. I've checked the settings, firewall rules, and even the OUTBOUND rules and they all look fine. But, when I clear the OpenVPN log and tried to connect via the OpenVPN 1199, this is what I get.

Feb 2 16:17:00 openvpn 14767 Exiting due to fatal error
Feb 2 16:17:00 openvpn 14767 TCP/UDP: Socket bind failed on local address [AF_INET]XX.XX.XX.04:1198: Address already in use
Feb 2 16:17:00 openvpn 14767 Control Channel Authentication: using '/var/etc/openvpn/server3.tls-auth' as a OpenVPN static key file
Feb 2 16:17:00 openvpn 14767 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
Feb 2 16:17:00 openvpn 14743 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09
Feb 2 16:17:00 openvpn 14743 OpenVPN 2.3.11 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jul 19 2016

As you can see, for some reason, the firewall thinks that I'm trying to connect using port 1198 and I'm not. Here is my config:

persist-tun
persist-key
cipher AES-256-CBC
auth SHA256
tls-client
client
remote XX.XX.XX.04 1199 udp
lport 0
verify-x509-name "INV_CRT_1199" name
auth-user-pass
ns-cert-type server
comp-lzo adaptive

 <ca>-----BEGIN CERTIFICATE-----

***KEY***

-----END CERTIFICATE-----</ca> 
 <cert>-----BEGIN CERTIFICATE-----

***KEY***

-----END CERTIFICATE-----</cert> 
 <key>-----BEGIN PRIVATE KEY-----

***KEY***

-----END PRIVATE KEY-----</key> 
 <tls-auth>#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----

***KEY***

-----END OpenVPN Static key V1-----</tls-auth> 
key-direction 1

Any help will be definitely appreciated. Oh, and the firewalls are set up utilizing CARP.

Dino

dbennett

Anyone?

jgwinner

No idea, I'd obviously double check everything.

I had a similar problem though - I setup two OpenVPNs, one on 1194 and one on 1195. If I connected on 1195, it would persist in trying to reply to 1194.

So, I setup an L2TP VPN instead … I was messing around with TAP Bridging, and I was remote :) So I didn't want to lock myself out.

It's almost as if the client download still has the old setting. Maybe it's something in pfSense? Not sure. Like you, I checked the client config, and it's not there, so I'm guessing there's a setting on the server; some response packet gives it the 'wrong' IP to respond back to.

In my case I did the same thing, I even deleted the entire OpenVPN setup and recreated it.

Do we know for sure you can have two OpenVPN's setup on teh same pfSense box? I would assume so.

== John ==

dbennett

Thanks for the reply!

Actually in the Client Export list there shows 3.

I'm in agreement that blowing away ALL of the OpenVPN configuration and starting over is probably the way I'm going to go. This is a production box and my concern with not being able to see who is connected when is that 1) the box is compromised and or 2) someone tried to compromise the box and just screwed it up.

Thanks again. IF there are any other thoughts I will appreciate the response.

Dino

viragomann

As I remember I got also a "Socket bind failed …. Address already in use" error after upgrading pfSense.
I got it solved by change the address the vpn server listens to to an internal one and forwarded the packets from WAN to this internal IP.

dbennett

Thanks for the suggestion. But I take that as more of a workaround then solving the problem. It also doesn't resolve the issue where the port the client is connecting with is not what the server is responding too.