Upgraded to 2.4.3, OpenVPN tunnel cannot be established anymore
-
Hi there,
Previous to upgrade (from 2.3 to 2.4.3) I had a successful TUN OpenVPN connection between two pfSense computers: one running as server, the other as client.
Since the 2.4.3 upgrade (both computers), that is no longer the case.
The client pfsense box has the following under Status->OpenVPNStatus: "reconnecting; init_instance"
Local address "pending"
Remote host "pending"I restarted both pfSense boxes, VPN services, no go.
Also, System Logs -> OpenVPN shows nothing on either the Server or the Client so I have no idea what is going on.Can you anyone please lend a helping hand?
One thing to mention, if relevant: The Server computer was upgraded to 2.4.3 from the dashboard successfully but I had to rebuild the client computer from scratch and load the previous settings from a backed up XML.
-
How is your openvpn set up? Certs or shared key ect..
Are you on static IP on the WAN for the server side? Did that address change?
-
@chpalmer Thanks for your response
Here is how it is setup:
Server mode: Peer to Peer (Shared Key)
Device mode: tun - Layer 3 Tunnel ModeI believe I have the self generated certs that I use as well which are still valid.
Both server and client are behind a dynamic IP. However, server keeps no-ip domain name updated to which the client connects in the OpenVPN client settings.
I have the ports on which the connection happens (internal ip range) appear in the NAT as well as the Rules lists the Wan rule to allow that port to be reached through.Again, i've been using this configuration for a few years until I decided to upgrade to 2.4.
The fact that I dont see anything in the logs is alarming.
-
UPDATE: Changed the time via FreeBSD shell but that made no difference, unless I need to reboot the whole box.
I just realize that my client clock is set to 2012. Would that be a problem? Obviously I will have that changed, just need to figure out how to do it in either pfsense shell or freebsd shell via ssh
-
At least I am getting something the client logs now.
RESOLVE: Cannot resolve host address: mydomainname:12222 (hostname nor servname provided, or not known)
I can only deduct from this that my server pfsense box is not accepting connections from the client on port 12222? I say that because I am able to access other services on this very domain name/IP. Strange because I havent done anything and I believe there is a rule (WAN) on the server pfsense to accept connections on that port.
-
and another update. I now see that I cannot seem to resolve anything via the Diagnostics->DNS Lookup because.
127.0.0.1 appears to be the only DNS server on the dashboard. -
Alright, this topic can be archived and I feel very silly.It ended up being a DNS issue. Obviously 127.0.0.1 being the only DNS server for pfSense internally couldn't resolve the external domain name so after I gave it another DNS server, the tunnel automatically took on.
I suppose that perhaps the DNS settings did not get carried over from backup XML when I restored the client.
Thanks
-
No that is not the reason - the loopback listing for dns is the correct out of the box default configuration of pfsense - since out of the box pfsense resolves via unbound. So pfsense wanting to "resolve" something yes it should just ask itself via loopback.
mydomainname:12222
Is not a valid FQDN- that would never resolve.
-
@johnpoz hey there,
that is not the full domain name, more of an example. I changed it for obvious reasons.
However, I couldn't even resolve something like microsoft.com so perhaps I have things setup incorrectly? -
If you go to pfsense diag, dns lookup and you can not resolve microsoft.com then sure you have a problem. Maybe your isp is blocing dns resolving, maybe your on a horrible connection for latency like sat or something and resolving timesout, etc.
Anything with :1234 on the end of il wil never resolve since its not a valid fqdn no matter if you changed the mydoamin part or not
If you PM me the actual fqdn your wanting to resolve I will validate it resolves on the public internet. Via unbound - unbound out the box will also not return something that fails dnssec, etc.
-
@johnpoz said in Upgraded to 2.4.3, OpenVPN tunnel cannot be established anymore:
dns re
Thank you John,
I do not think we are on the same page here. While I appreciate what you are saying, that is not what I did (try resolving something with a port number). You must be confusing my post with an OpenVPN LOG entry:RESOLVE: Cannot resolve host address: mydomainname:12222 (hostname nor servname provided, or not known)
which has nothing to do with me using Diagnostics-> DNS Resolve.
-
Can you resolve the FQDN or not?
-
Yes I can now, after adding 2 additional DNS servers under General setting.
I couldn't do so otherwise with only 127.0.0.1 -
Is your Unbound service actually running- /status_services.php