Todo #14816
closed
Feedback on pfSense® software Configuration Recipes — OpenVPN Site-to-Site Configuration Example with SSL/TLS
100%
Description
Page: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html
Feedback:
I tried to follow the instructions to post on the forums first,
here: https://forum.netgate.com/topic/182936/issues-with-openvpn-site-to-site-documentation
But after more than a week no one has responded to my post.
Copying the content of that post here:
I'm posting this here to confirm that it is actually an issue with the documentation and not an issue with my brain, before I post to the pfSense Bugtracker.
Note: I am using pfSense 2.7,0, which seems to be the latest version, and I assume that the documentation is updated to match the latest version (bottom left of the window shows "v: latest" in green text).
Issue 1 (Minor): Under Documentation: Configuring SSL/TLS Client Side -> Enable authentication of TLS packets , no such named setting exists. I assume it is referencing the setting WebConfig Setting: TLS Configuration -> Use a TLS Key , which is correctly described in the earlier documentation step Documentation: * Configure the OpenVPN Server Instance* -> TLS Configuration
Issue 2 (Major): Under Documentation: Configuring SSL/TLS Client Side there is no reference to the WebConfig Setting: IPv4 Remote network(s) . I found it necessary to input the CIDR of the Server site for data to successfully route between sites. Before inputting this information, the OpenVPN connection was successful, but the routing tables on the client side (WebConfig: Diagnostics -> Routes ) had no entry for the server site.
Updated by Kris Phillips over 1 year ago
- Status changed from New to Confirmed
Reviewing, the option for "Enable authentication of TLS packets" is indeed missing in the UI. It looks like it was replaced by the "TLS Key Usage Mode" dropdown.
You shouldn't need to define a Remote subnet unless you're doing a /30 S2S, but I believe you need to add the OpenVPN Client and Server as interfaces on both sides.
This entire doc is a bit outdated and could use some serious revisions. Generally speaking multi-site with OpenVPN is a bad idea and a single client and server should be configured for every S2S connection utilizing a /30. There is special code in pfSense for this operation that guarantees functionality.
Updated by Jim Pingle over 1 year ago
Kris Phillips wrote in #note-1:
You shouldn't need to define a Remote subnet unless you're doing a /30 S2S, but I believe you need to add the OpenVPN Client and Server as interfaces on both sides.
This entire doc is a bit outdated and could use some serious revisions. Generally speaking multi-site with OpenVPN is a bad idea and a single client and server should be configured for every S2S connection utilizing a /30. There is special code in pfSense for this operation that guarantees functionality.
Using a /30 Site-to-Site style point-to-point setup is being deprecated by OpenVPN, the code path is very neglected as we found when developing DCO support. Using a mutli-site OpenVPN with SSL/TLS is absolutely the correct thing people should be doing. The only quirk is using iroutes/overrides, which is covered in the docs already.
Updated by Daniel Castellanos over 1 year ago
Kris Phillips wrote in #note-1:
You shouldn't need to define a Remote subnet unless you're doing a /30 S2S, but I believe you need to add the OpenVPN Client and Server as interfaces on both sides.
This is getting off-topic a bit but I think that it's always good to document experiences or "bugs" somewhere, and since I started this conversation I might as well provide a bit more info.
You're right. I'm wrong about the Remote subnet on the client side. I removed the entry from my two clients and the OpenVPN connection continued to function normally.
Today I added a third client to the same site-to-site VPN configuration and I had the same symptoms. The OpenVPN Status page showed that the connection was successfully established, but I couldn't ping across the networks. I waited for a bit and the correct routes did show up in Diagnostics -> Routes - again, contrary to my earlier claim - and yet I still couldn't ping across the connection. Everything seemed to be configured fine and connected but it wasn't working.
I was very tempted to try adding the Remote subnet to the client side to see if that would fix the problem, but I decided to try something else instead - an extremely elementary tool of troubleshooting: I rebooted the pfSense box (on the new client side).
After it came back up, everything started working immediately.
I'm running the latest version of pfSense 2.7.0 community (all updates installed) on both ends, so this still somehow points to a bug to me. The interface shouldn't report that everything is connected and working when in fact it is not working. It seems that some service probably needs to restart after a new configuration and new connection is established, and restarting the server accomplished that. It's also possible, maybe likely, that I had the same problem with the other two clients, and that adding the Remote line to the configuration caused that service to restart, accomplishing the same "solution" and making me think that the Remote line was necessary.
Updated by Jim Pingle over 1 year ago
- Status changed from Confirmed to Closed
- Assignee set to Jim Pingle
- % Done changed from 0 to 100
I just pushed an update that corrects some of the menu/option names and clarifies a couple other points. I followed along exactly with the recipe from two factory fresh VMs (just changed their LANs and hostnames) and ended up with a working site-to-site setup with full LAN to LAN connectivity.
If something still isn't working as you expect after following the updated recipe exactly, then post on the forum for assistance. Odds are, some other options you are choosing (or omitting) are not quite right for your environment.