Can't connect to my own OpenVPN server now

[sos]

My home network openVPN server was set up and running fine a month or so ago, able to connect from laptop and android phone no problems.

However just over the last couple of weeks, without anything apparently having changed, I can no longer connect remotely. In a terminal I see:

 TLS error: TLS handshake failed
SIGUSR1 [soft, tls-error] received, process restarting

I believe this is most commonly due to a firewall setup blocking the openVPN packets from communicating with the server. I've checked the openVPN port 34982 using grc's port probe (https://www.grc.com/x/ne.dll?bh0bkyd2) and it is listed as "stealth", as opposed to my webserver port (80) and plex port (32400), which are "open".

As far as I can see my firewall and NAT rules should be treating traffic exactly the same as port's 80 and 32400 (see attachments). The pfSense LAN address is 192.168.94.1, and I have checked the remote destination is functioning (ratiro.dynu.com).

The openVPN logs don't show anything as the packet's aren't making it through that far.

I am using DNS forwarder, with my webserver address (ratiro.dynu.com) as a local override, if that makes any difference.

I'm stumped, but it's probably something really basic!

EDIT: Added OpenVPN server log:

Dec 4 13:38:08 	openvpn 	75577 	OpenVPN 2.3.11 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Jul 19 2016
Dec 4 13:38:08 	openvpn 	75577 	library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.09
Dec 4 13:38:08 	openvpn 	75963 	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 4 13:38:08 	openvpn 	75963 	Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Dec 4 13:38:08 	openvpn 	75963 	TUN/TAP device ovpns1 exists previously, keep at program end
Dec 4 13:38:08 	openvpn 	75963 	TUN/TAP device /dev/tun1 opened
Dec 4 13:38:08 	openvpn 	75963 	do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Dec 4 13:38:08 	openvpn 	75963 	/sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.0 up
Dec 4 13:38:08 	openvpn 	75963 	/usr/local/sbin/ovpn-linkup ovpns1 1500 1570 10.0.8.1 255.255.255.0 init
Dec 4 13:38:08 	openvpn 	75963 	UDPv4 link local (bound): [AF_INET]219.88.232.203:34982
Dec 4 13:38:08 	openvpn 	75963 	UDPv4 link remote: [undef]
Dec 4 13:38:08 	openvpn 	75963 	Initialization Sequence Completed 


[Derelict]

You cannot port check UDP ports. TCP and UDP are different there.

Why are you port forwarding that port to your (presumed) LAN address? Delete the port forward and just pass to WAN address UDP/34982 with a firewall rule on WAN.

Then edit your OpenVPN server and be sure it is listening on WAN address UDP 34982.

All of this didn't just change itself and spontaneously stop working. Someone had to change it.

[sos]

Thanks, Derelict.

1. Ahem. I won't try checking UDP ports again :)

2. I've deleted that port forward rule, and now my NAT rules are as shown

3. I have rejigged my server to WAN, UDP 1194.

4. Can confirm I am trying to connect from outside of my LAN i.e. using a 3G hotspot.

Still no dice.

And yes, I must have changed something else somewhere else, which I appreciate makes it rather difficult to help further. Will keep looking & thanks again.


[Derelict]

Set the Destination address on the firewall rule to WAN address there. Probably will not matter but dest any is improper.

What is in the OpenVPN server logs when you try to connect.

If you have changed the server to listen on WAN address UDP 1194 and have a firewall rule on WAN passing traffic from any to dest WAN address UDP 1194 then either the packets aren't arriving or the OpenVPN server should be logging something.

Be sure you run another client export and reconfigure the client after you have all that set.

[sos]

Thanks again.

Followed those steps & re-exported the client config (now port 1194).

I checked the open VPN logs (log level 3) - no sign of any client connection attempts, so it looks as though the packets aren't getting through for some reason. Client is a linux laptop, using network manager and importing the ovpn config file. Also tried from the terminal as per the error message in my first post.

FWIW I can readily access my webserver on the same web address (ratiro.dynu.com) served from a machine connected to the router through Port 80, so I know my pfSense router is connected and able to serve at least port 80.

[Derelict]

You can prove the packets are or are not arriving with a packet capture on WAN on UDP 1194 with an address of the client's public egress IP address.

[maverick_slo]

Had the same thing.
Left all untouched, rebooted and all was working again…

[sos]

@maverick_slo:

Had the same thing.
Left all untouched, rebooted and all was working again…

Heh - if only!

I've set up a static IP address, which I've been meaning to do for a while, but was prompted to do so now just in case it was some funny business with my dyn DNS provider. Still not working with the static IP address.

Interestingly I can connect to the VPN from within the LAN, which I never used to be able to do, but still cannot do so from the WAN, which rather defeats the purpose. I jsut cannot work out what rule(s) or network setup has changed to ellicit this behaviour.

[johnpoz]

"Interestingly I can connect to the VPN from within the LAN, which I never used to be able to do, but still cannot do so from the WAN"

Not sure how that is interesting.. If the packets are not getting there, then there is no way to connect..  Your saying openvpn is not logging any connection attempt.. What is your client saying?  As derelict suggested sniff on your want for the traffic.. Do you see any when you try to connect?

Are you using IP or some dynamic dns name?  Is it resolving to your current public IP?

[sos]

Thanks, johnpoz.

It's perhaps not so much interesting, as at least confirming that my VPN server and client can connect with each other, just not from the WAN.

My server is on a static IP now, and my webserver is accessible and resolving through the same public IP as the VPN server.

The client is failing silently, as per the terminal message in my first post - but I will dig deeper into some logs and sniff some packets as suggested when I get a chance.

[sos]

Ahem. Have now learnt all about the 'Packet Capture' feature under 'diagnostics'. It's always good to learn more about pfSense and take another step on the path to enlightenment :)

Here is the result when I try to connect from my Android phone over 3G. It indicates that the packets are at least getting to pfSense:

08:20:05.123926 AF IPv4 (2), length 86: (tos 0x0, ttl 54, id 23168, offset 0, flags [DF], proto UDP (17), length 82)
    xxx.xxx.xxx.xx.xxxx > 219.88.232.203.1194: [udp sum ok] UDP, length 54

[johnpoz]

So that is a good thing.  But if your server is not showing a connection attempt then either your firewall rules are not allowing it to get to the openvpn server, or openvpn server is not running on the wan, or 1194 udp, etc.

[Derelict]

Again, why are you listening on LAN address and forwarding to LAN address?

You do not need a port forward to run OpenVPN. All you need to to is tell the server to listen on WAN address and pass UDP 1194 from any to WAN address. Delete the port forward.

[sos]

@Derelict:

Again, why are you listening on LAN address and forwarding to LAN address?

You do not need a port forward to run OpenVPN. All you need to to is tell the server to listen on WAN address and pass UDP 1194 from any to WAN address. Delete the port forward.

Thanks again, guys.

1. I'm listening on the WAN, UDP protocol, port 1194 - that was how I'd set up the packet capture, while trying to connect to the VPN using my android phone i.e from the WAN. I don't think I'm listening on the LAN and forwarding to a LAN address  ???

2. As indicated in the 3rd post in this thread, I did follow your helpful advice and delete that port forward rule.

3. Other than that, my firewall rules seem to be in order, and those udp packets are confirmed as arriving on port 1194 of the pfSense/openVPN host @ WAN IP 219.88.232.203. But they seem to be dying there, with nothing in the openVPN logs. I am trying to work out what the firewall is doing to them now.

4. Temporarily disabling firewall/NAT allowed the client to connect.

5. But I still cannot figure out which of my firewall rules is causing the issue  :'(

[Jerod]

Any luck?

I am having the same problem as you are. My tracer shows me hitting my pfsense, but doesn't allow me to connect. It hasn't worked for a about a month.

Jerod

[sos]

No,sadly. I've put fixing it on the back burner until after Christmas, as I am probably going to have to try a fresh install.

[AndyC]

Are you guys using Android devices to connect? I had the same issue and checked everything in pfsense. It turned out to be a problem with the power-saving feature in an Android update. Turning that off or adding OpenVPN Connect as an exception in power-saving made everything work again. Just a thought.

[johnpoz]

4. Temporarily disabling firewall/NAT allowed the client to connect.

Well post up rules, both on your wan, your floating and your nats..  And your openvpn config..  You sure actually listening on your wan??  Just removing a nat that sent to your lan IP doesn't change vpn to listen on your wan address.

Do a sockstat and lets where pfsense is listening for 1194

example

[2.3.2-RELEASE][root@pfsense.local.lan]/root: sockstat -L | grep :1194
root     openvpn    25696 5  udp4   24.13.snipped:1194     *:*
[2.3.2-RELEASE][root@pfsense.local.lan]/root:

[sos]

I thought I had it cracked when I uninstalled pfBlockerNG and my android phone connected. As I had also relaxed my firewall rules (allow any from any), when I reinstituted the correct firewall rule (allow UDP:34982 on WAN address), it stopped working again. Resetting the any-from-any rule, it no longer connected again.

[2.3.2-RELEASE][admin@ratiro-net.ratiro]/root: sockstat -L | grep :34982
root     openvpn    11123 6  udp4   *:34982               *:*

I have attached my firewall rules, NAT and openVPN config pages. There are no floating rules defined.


[TechnologicalLiving]

I think that you're trying this via celluar, correct?  If so, your carrier wouldn't be T-Mobile would it?