You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remote VPN not working if site-to-site VPN exists #3654
When both site-to-site VPN and the Remote VPN are configured/enabled - Remote VPN will not work. When site-to-site VPN is removed, Remote VPN will start functioning again fine.
WORK AROUND
Create a SVM in VirtualBox and login as root.
Comment all repositories in /etc/apt/sources.list and add buster repository. The buster is the debian stable release.
> vim.tiny /etc/apt/sources.list
`deb http://http.debian.net/debian buster main`
Run apt update and install the newest strongswan:
`apt update`
`apt install libcharon-extra-plugins libstrongswan libstrongswan-extra-plugins strongswan strongswan-charon strongswan-libcharon strongswan-starter`
Shutdown the VM in VirtualBox and upload a new SVM template into ACS.
In 4.13, I have observed that when site-to-site VPN exists, the Remote VPN/User VPN doesn't work - as soon as you delete the site-to-site VPN - Remote VPN works again fine.
@msinhore Thanks for sharing. I've tested the work-around (simply modifying a single router in a test environment) in our 4.13 deployment, works well (previously configured site-to-site VPN still works and now one can remote-VPN).
Based on the latest info I have, we don't have time for proper Debian10 systemVM template testing and have agreed to move it for 4.15 - thus this ticket is also moved.
What other noticed, "libc" package gets upgraded together with StrongSwan - so users should pay attention on possible risk (theoretically none, but...)
What's the secret to getting virtualbox to boot from the existing qcow2 virtual disk? We just receive
"FATAL" Could not read from the boot medium! System halted."
Do we need to do some type of convert on the qcow2 file first?
For what it's worth, I debugged this last week and aside from updating the whole virtual router (which I support, for sure). What appears to be happening is the last preshared key is being used for the "any" instead of the one generated by cloudstack.
So if all of your site-to-site VPNs have the same preshared key, you can connect with that instead of the long one that cloudstack generates as a Remote VPN client and it will connect perfectly.
Activity
andrijapanicsb commentedon Oct 29, 2019
In 4.13, I have observed that when site-to-site VPN exists, the Remote VPN/User VPN doesn't work - as soon as you delete the site-to-site VPN - Remote VPN works again fine.
[-]Site-to-site VPN doesn't work[/-][+]Remote VPN not working if s-2-s VPN exists[/+][-]Remote VPN not working if s-2-s VPN exists[/-][+]Remote VPN not working if site-to-site VPN exists[/+]3 remaining items
DavidWMerrill commentedon Nov 27, 2019
@msinhore Thanks for sharing. I've tested the work-around (simply modifying a single router in a test environment) in our 4.13 deployment, works well (previously configured site-to-site VPN still works and now one can remote-VPN).
yadvr commentedon Jan 7, 2020
Debian 10 systemvmtemplate PR here: #3797
andrijapanicsb commentedon Jan 13, 2020
Based on the latest info I have, we don't have time for proper Debian10 systemVM template testing and have agreed to move it for 4.15 - thus this ticket is also moved.
What other noticed, "libc" package gets upgraded together with StrongSwan - so users should pay attention on possible risk (theoretically none, but...)
Slair1 commentedon Mar 13, 2020
What's the secret to getting virtualbox to boot from the existing qcow2 virtual disk? We just receive
"FATAL" Could not read from the boot medium! System halted."
Do we need to do some type of convert on the qcow2 file first?
ServiceTo commentedon May 27, 2020
For what it's worth, I debugged this last week and aside from updating the whole virtual router (which I support, for sure). What appears to be happening is the last preshared key is being used for the "any" instead of the one generated by cloudstack.
So if all of your site-to-site VPNs have the same preshared key, you can connect with that instead of the long one that cloudstack generates as a Remote VPN client and it will connect perfectly.
Looks like a strongswan bug from 5.5.. https://wiki.strongswan.org/issues/2497
andrijapanicsb commentedon May 27, 2020
Correct.
systemvmtemplate: move to using Debian10 (#4104)