-
Notifications
You must be signed in to change notification settings - Fork 627
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Install both Wireguard and Openvpn protocols (Issue #968) #1030
Conversation
I was expecting that someone asked for this, and me too. However my idea was a bit different: unify the pivpn script as well as bash_completion. Place script inside |
I can follow your idea on that if you want. I chose the dual structure because I had a pi working at a remote site, and was scared of breaking my ovpn vpn into the remote site (lockdown!). So I tried to make the two installations as separate as possible, so either protocol could be updated/patched and the other one is still working. |
That’s dangerous, for most tests I usually run a Debian virtual machine unless the change is Raspberry Pi specific. In this case a virtual machine should be fine. |
I tested what I was doing on a pi at home, but I wanted a solution I was sure would not break a remote machine. |
I'm looking at moving/unifying the pivpn scripts. Should I just leave this here until another solution comes along, or do I delete it, or does someone else delete it? |
What is the best way to test this? I cloned the repo, and do the successful install with the --altcommand, but in the end, the pivpn_wg script has issues because it is looking for the scripts in /opt/pivpn rather than /opt/pivpn_wg . Updating them, all of the other scripts seem to need updates too, I think because of the makeRepo git to /etc/.pivpn. |
Hi, assuming you cloned the ...shelleycat485 repository, did you clone the right branch? I think the branch you want is test. Then on your local machine copy out the install.sh and do a bash install.sh This is different from the normal curl... install because of the different branch. I'll try and verify that as well. All the changes should have been in step, and it sounds like you are accessing the wrong branch. |
Whatever you want, close the pull request and open a new one when you have the changes ready or keep this open and add new commits |
Yes, I got the right branch (git clone -b test https://github.com/shelleycat485/pivpn/), and all of the scripts have the dual installation capability in the repo, but when I install with the --altcommand, they get the pivpn/pivpn version. I think in install.sh, the install clones down the pivpn/pivpn version and uses that. After install, I edited /usr/local/bin/pivpn_opv to reference the correct path, and copied the OpenVPN scripts in shelleycat485:test cloned repo the to /opt/pivpn_opv folders. Things almost seem to work now, but I think there is still some cross contamination where my OpenVPN clients are getting assigned ip ranges out of the WG pool. |
OK, thanks for that testing information. I had not noticed the cross-contamination of the addresses. I'll have a look at that - I tested it with one client of each sort, so I will try more clients I understand the install.sh issue, the...shelleycat repo is set up to run from pivpn/pivpn on github because it is a pull request, but if you are using it locally line 14 needs to point at the ...shelleycat.. repo on github AND you need to adjust the install.sh script to clone the test branch, in two places where there is a git clone -b test.... |
I can confirm no cross contamination when installed from the local repo and the install.sh is edited to use shelleycat test. Both WG & OpenVPN tested and working. |
Will close this, working on a solution that will retains pivpn as the single command. I'll leave this repo as it is, put a comment to it in the request for dual protocol in the pivpn/pivpn issues to people can find it. |
Did this ever land? |
Yes, its in the main pivpn/pivpn repository now. |
Nevermind I need to read instructions... |
Tested using RasPiW+. Because not a major use case this has changed the command for at least one of the protocols.