OpenVPN without WAN VPN Provider
I have been trying for weeks now to get OpenVPN working for two clients that work remotely outside of our LAN business office.
Our ISP is AT&T they manage our fiber router which then connects to our firewall gateway then to 5 Juniper Ex 2200 switches.
However, I keep getting TLS key handshake failed error when testing the exported client package by running it after installing it on my PC from my home network. I have tried different remote connections (User Auth/TLS, both and only), I have tried different server modes for the remote connection, I have ensured CA manager, Server certificate, user certificate, user manager, firewall rule, Interface settings, and WAN static IPv4 for our firewall are all correct. I have even tried different numberings in these configurations but it is always the same error with the TLS key failing.
I have been meticulously trying different configurations when it comes to the IP addresses on the Tunnel Network fields with DNS and local network IPv4 and redirecting traffic settings ...all to no avail.
My question is: I just started watching this netgate video OpenVPN as WAN in the resource library which I am interpreting as having to have a VPN provider.
Does this mean that I cannot set up OpenVPN into our LAN from and to Internet solely from our pfsense Netgate SG-8860?
Must I contact VPN providers to make this work?
Any explanation would be appreciated as this is my first foray into VPN on pfSense.
You don't need any VPN provider to get your own OpenVPN RAS running. Check out https://www.netgate.com/resources/videos/remote-access-vpns-on-pfsense.html and https://www.netgate.com/resources/videos/remote-access-vpns-on-pfsense-part-2.html
You say your ISP is managing the fiber router...maybe they need to open/forward the OpenVPN ports for you?
Are there some public ports already open and working? e.g. e-mail server, web server, ... ?
Okay I am going to watch those instructional resources.
I already contacted the technical consultant for our fiber circuit as he can access info from the network engineers in the eastern hemisphere.
Public ports open and working? Not sure about that...we use Salesforce CRM and G Suite and VoIP cloud hosted services, so I infer data streams from their data centers is being transmitted through our router public ports then to our firewall private ports, yes? Just to be clear, do not know if this matters, but we actually do not have an on-prem server machine, no domain controller. We use the cloud to share files among user workstations. This LAN has no VLANs as well. They are real estate and needs network improvement which I am slowly working on. Hence, starting with vpn.
I do not know exactly how but the at&t IP migration of our LAN and getting a new circuit a couple of months ago messed up any Internet -to-LAN connections we had (e.g. MS RDP). Not sure if this could also be impacting the VPN connection but any info att responds with could potentially resolve to some extent.
In the pfSense WebGUI go to Diagnostics -> Packet Capture
Address Family <IPv4 only>
Port <your OpenVPN RAS Port>
all other options leave default.
Hit the Start Button.
Try to connect the OpenVPN Client, then hit Stop Button.
You should then see Packets in the 'Packets Captured' field, or you can download the capture and open in Wireshark.
A successful OpenVPN RAS connection established would look like this in Wireshark:
If you don't see any traffic in this capture, the problem is upstream to pfSense.
@rico Got it. Will test this thoroughly.
I am thinking when att put us on this new circuit they failed to ensure that what we had on our prior network scheme regarding public port settings for remote network upstream data access to our fw-gw remained loaded. Maybe during initial set up, the pfSense admin at the time had to explicitly request that network layer permission with att network engineering team for the old circuit and I have not been able to get through to them yet, thus this could explain why ms rdp just stopped working once we moved into new office.
Yes this could be the problem.
Years ago we had some SHDSL line as spare with cisco router from the ISP. The cisco was totally managed by the ISP with no access for us. For any changes like port forwadings we need to open a ticket...