Need help troubleshooting: Connection to pfSense OpenVPN no longer works

[DominikHoffmann]

A while back I followed the instructions for how to set up an OpenVPN server on pfSense. I got it to work beautifully. A few months later it no longer works.

The OpenVPN log file on my pfSense box reveals nothing. Neither do the logs in Viscosity Details.

For troubleshooting I hop on my neighbor’s network and try to make a connection with Viscosity to my OpenVPN server. I checked all the firewall rules, and they check out. The firewall log file reveals no blocked connection attempt from the Viscosity client.

[viragomann]

Your OpenVPN server is running, I presume. So in the OpenVPN log on pfSense you should at least see the startup logs.

I'm not familiar with Viscosity, but I guess it should log at least connection attempts and failures.

So what do you really get?

[DominikHoffmann]

It’s as though the client can’t get through to the server at all.

This is what the client log says:

2020-10-30 17:36:51: Viscosity Mac 1.8.6 (1546)
2020-10-30 17:36:51: Viscosity OpenVPN Engine Started
2020-10-30 17:36:51: Running on macOS 10.15.7
2020-10-30 17:36:51: ---------
2020-10-30 17:36:51: State changed to Connecting
2020-10-30 17:36:51: Checking reachability status of connection...
2020-10-30 17:36:51: Connection is reachable. Starting connection attempt.
2020-10-30 17:36:51: OpenVPN 2.4.9 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Jun 13 2020
2020-10-30 17:36:51: library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
2020-10-30 17:36:51: Resolving address: ***.***.com
2020-10-30 17:36:51: Resolving address: ***.***.com
2020-10-30 17:36:51: Valid endpoint found: ***.***.***.***:1194:udp4
2020-10-30 17:36:51: TCP/UDP: Preserving recently used remote address: [AF_INET]***.***.***.***:1194
2020-10-30 17:36:51: UDPv4 link local (bound): [AF_INET][undef]:1194
2020-10-30 17:36:51: UDPv4 link remote: [AF_INET]***.***.***.***:1194

That’s it.

[viragomann]

Seems these are different settings. The server is on TCP, while the client tries to connect using UDP.

[DominikHoffmann]

@viragomann Thanks for studying my log files! I shared the log file for the wrong client. The correct log file looks like this:

2020-11-02 17:20:23: Viscosity Mac 1.8.6 (1546)
2020-11-02 17:20:23: Viscosity OpenVPN Engine Started
2020-11-02 17:20:23: Running on macOS 10.15.7
2020-11-02 17:20:23: ---------
2020-11-02 17:20:23: State changed to Connecting
2020-11-02 17:20:23: Checking reachability status of connection...
2020-11-02 17:20:23: Connection is reachable. Starting connection attempt.
2020-11-02 17:20:24: OpenVPN 2.4.9 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Jun 13 2020
2020-11-02 17:20:24: library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
2020-11-02 17:20:24: Resolving address: ***.***.com
2020-11-02 17:20:24: Valid endpoint found: ***.***.***.***:443:tcp4-client
2020-11-02 17:20:24: TCP/UDP: Preserving recently used remote address: [AF_INET]***.***.***.***:443
2020-11-02 17:20:24: Attempting to establish TCP connection with [AF_INET]***.***.***.*** [nonblock]
2020-11-02 17:20:52: State changed to Disconnecting
2020-11-02 17:20:52: SIGTERM[hard,init_instance] received, process exiting
2020-11-02 17:20:52: State changed to Disconnected

The last three log lines are from my making the client stop trying.

Here is the configuration screen of the Viscosity client:

[DominikHoffmann]

Here are my NAT and Firewall rules:


Those have not changed since I first had gotten this all to work.

[viragomann]

So on the server you cannot see any more than the screenshot above is showing, when attempting to connect?

I'd use the Diagnostic > packet capture tool on pfSense to check if packets arrive on WAN interface. Possibly it is blocked now by ISP.
Select WAN at interface and enter 443 in the port box. Start the capture and try to connect from outside.

Consider that on port 443 you may see outgoing https connections as well.
You may also use a simple web browser to initiate packets to your WAN by entering your <WAN address>:443 into the address line.

[SteveITS]

Who's your ISP? We have had a few cases in the past year with clients on Comcast where randomly one IP gets blocked or something and (usually) restarting or (rarely needed) powering off the Comcast router/modem fixes the issue.

[Gertjan]

Why redirecting to 192.168.1.1 ?
Isn't 192.168.1.1 (the LAN of) pfSense ?

OpenVPN, as it listens also on the WAN interface of pfSense, doesn't need a NAT rule, just a firewall pass rule :
Interface WAN
Port 443
Protocol TCP.

See the default firewall when you activate OpenVPN using the wizard the first time :

( you've changed UDP for TCP, and 1194 for 443).

443 port is already used by another service : the GIUI web server, if you have https GUI access activated. If so, move it to another port.

If you have a router in front of pfSense : check if a NAT rule on that device still works.

[DominikHoffmann]

@teamits: Thanks for the tip! I have restarted the router several times.

I am also not on Comcast. We have a fantastic rural carrier here, that’s also a co-op. NineStar covers most of Hancock county, the county to the immediate east of Marion County, which is essentially Indianapolis. Through them, every resident in the county has access to Gigabit internet access, which makes us the envy of many even in the city. Just had to give them a shout-out!

[DominikHoffmann]

I was at an event where I ran into NineStar’s CEO and asked him, whether there was someone who could help me, because I had increased suspicion that it was an ISP issue. The following day I got a call from NineStar’s CTO who almost immediately knew what was up. He directed his staff to provide a solution, which is working great. See also my related post.

Thank you very much to all of you for helping troubleshoot!