Todo #15259
closed
Feedback on pfSense® software Configuration Recipes — OpenVPN Site-to-Site Configuration Example with SSL/TLS
0%
Description
Page: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html
Text:
Select the server instance configured previously.
IPv4 Remote Network/s
The clientB LAN subnet, 10.5.0.0/24.
Note
This field sets up the internal route (iroute) for OpenVPN.
Feedback:
With the server running: 2.7.2-RELEASE (amd64)
built on Fri Dec 8 12:55:00 PST 2023
FreeBSD 14.0-CURRENT
And client running: 23.09.1-RELEASE (arm64)
built on Sat Dec 9 9:57:00 PST 2023
FreeBSD 14.0-CURRENT
Observing: GET INST BY VIRT: 10.1.4.9 [failed]
in the Status -> System Logs -> OpenVPN
Then the issue is that
The client specific override specification of
IPv4 Remote Networks : 10.1.4.0/24
is NOT SUFFICIENT to create an iroute on the server.
It is also required to add an Advance rule in the client specific override as below :
iroute 10.1.4.0 255.255.255.0;
Updated by Jim Pingle over 1 year ago
- Status changed from New to Rejected
I'm not sure what you did wrong, but it is absolutely sufficient. I just re-tested that entire set of instructions in the last couple weeks and it works perfectly assuming the entire setup is followed as stated.
Post on the forum for assistance if it doesn't work for you.
Updated by Michael McNamara over 1 year ago
I don't need assistance, instead I am reporting that it fails if I just follow the guidelines on the base page.
If I also follow the recommendations on your debug page:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/openvpn-iroute.html
to add an iroute, then everything works beautifully.
And note that our server is a Community Edition running in a VM, whereas the client is an NETGATE 1100; perhaps you testing did not include this scenario?
Updated by Jim Pingle over 1 year ago
I tested both Plus and CE. If it didn't work, you must have configured it improperly.
Updated by Michael McNamara over 1 year ago
Thanks for accepting my feedback on how I made your system work despite the documents leading me astray!
Updated by Michael McNamara over 1 year ago
One strategy to consider - In the future I humbly suggest you state that "I close this report pending additional information, as I could not reproduce the issue"
rather than stating "I'm not sure what you did wrong, but it is absolutely sufficient..." Tone helps a lot!
Then the original poster might respond (as I will now) Our systems are deployed with existing star VPN connections, with pre shared keys, one per remote site, and these sites are in three different states; and so when following the guideline for the new multi-site set up, we disabled but did not delete the existing direct connections between the client A, client B and client C and the server so that if the new set up did not work we could quickly re-establish the working configuration.
Perhaps this is what is different between the testing scenario and what might more typically occur in the field.
I can assure you that in this mode, it is the case that specifying the IPv4 remote networks on the client set up was not sufficient to get an iroute command issued automatically; perhaps because there is already a (disabled) iroute for the same lan in the system for the disabled link? I leave it to your team to determine the root cause, but state again that the work around in this case of explicitly including the iroute command as suggested in the Troubleshooting guide fixes everything and it all works beautifully.