-
Notifications
You must be signed in to change notification settings - Fork 171
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
[bug:admin] Wireguard: CA must not be used when using this VPN backend #543
Comments
nemesifier
added this to Backlog
in OpenWISP Priorities for next releases
via automation
Sep 22, 2021
pandafy
added a commit
that referenced
this issue
Sep 23, 2021
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to None - Made VPN server private_key and public_key nullable - Cert and IPAdress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None - Subnet division only works for WireGuard and WireGuard VPN backend Closes #543
pandafy
added a commit
that referenced
this issue
Sep 24, 2021
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to None - Made VPN server private_key and public_key nullable - Cert and IPAdress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None - Subnet division only works for WireGuard and WireGuard VPN backend Closes #543
pandafy
added a commit
that referenced
this issue
Sep 27, 2021
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to blank - Cert and IPAddress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None/blank. - Subnet division only works for WireGuard and WireGuard VXLAN VPN backend Closes #543
nemesifier
pushed a commit
that referenced
this issue
Sep 28, 2021
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to blank - Cert and IPAddress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None/blank. - Subnet division only works for WireGuard and WireGuard VXLAN VPN backend Closes #543
Closed in #549 |
pandafy
added a commit
that referenced
this issue
Oct 12, 2021
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to blank - Cert and IPAddress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None/blank. - Subnet division only works for WireGuard and WireGuard VXLAN VPN backend Closes #543
pandafy
added a commit
that referenced
this issue
Nov 26, 2021
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to blank - Cert and IPAddress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None/blank. - Subnet division only works for WireGuard and WireGuard VXLAN VPN backend Closes #543
pandafy
added a commit
that referenced
this issue
Nov 29, 2021
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to blank - Cert and IPAddress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None/blank. - Subnet division only works for WireGuard and WireGuard VXLAN VPN backend Closes #543
pandafy
added a commit
that referenced
this issue
Jan 12, 2022
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to blank - Cert and IPAddress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None/blank. - Subnet division only works for WireGuard and WireGuard VXLAN VPN backend Closes #543
pandafy
added a commit
that referenced
this issue
Jan 12, 2022
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to blank - Cert and IPAddress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None/blank. - Subnet division only works for WireGuard and WireGuard VXLAN VPN backend Closes #543
pandafy
added a commit
that referenced
this issue
Jan 19, 2022
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to blank - Cert and IPAddress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None/blank. - Subnet division only works for WireGuard and WireGuard VXLAN VPN backend Closes #543
codesankalp
pushed a commit
that referenced
this issue
Apr 21, 2022
- Automatically set subnet and ip of OpenVPN server to None - Automatically set private_key and public key for WireGuard/VXLAN server to blank - Cert and IPAddress previously assigned to the VPN server are not deleted from the database after VPN backend is changed. Only field values are set to None/blank. - Subnet division only works for WireGuard and WireGuard VXLAN VPN backend Closes #543
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When creating a VPN Server, If one sets the CA/cert fields on OpenVPN and then switches to Wireguard, the validation error "CA must not be used when using this VPN backend" is hidden because the cert fields are not shown.
We could either fix the admin or change the model code so that any cert/ca is removed.
The text was updated successfully, but these errors were encountered: