Fix bugs in an existing cross-platform PySide6 GlobalProtect VPN client.
Budget: €30 – €50 EUR
### Introduction
The core functionality for a **PySide6-based VPN client** is in place, with the goal being to
enable a seamless connection to a company's VPN, specifically those using
Palo Alto GlobalProtect. Typically, the connection process when using a VPN
client such as **Palo Alto GlobalProtect** is straightforward:
1. **GlobalProtect software** is installed.
2. **Credentials** are stored in the system.
3. The user clicks a button to **connect to the portal**.
4. A list of available **gateways** is displayed.
5. The user selects the appropriate **gateway** and connects.
6. Once connected, the VPN is ready for use.
7. The user clicks a **disconnect** button to terminate the connection.
In this case, for this particular **PySide6** app, the connection process will
leverage the open-source **OpenConnect** tool, which supports GlobalProtect.
This task’s goal is to ensure a reliable connection process, particularly for
VPNs using **SAML-based authentication** and other advanced setups.
---
### Current Issue
When attempting to connect to real-life company, the following error would occur:
```
pyvpn.core.global_protect_service: Connecting to portal vpn.company.com...
pyvpn.core.global_protect_service:
pyvpn.core.global_protect_service: WARNING: Cannot set locale: No such file or directory
POST https://vpn.company.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Windows
Connected to 12.345.678.901:443
SSL negotiation with vpn.company.com
Connected to HTTPS on vpn.company.com with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA256)-(AES-256-GCM)
SAML REDIRECT authentication is required via https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/saml2?SAMLRequest=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%2Fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%2Bxxx%2Bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%2Fxxx%2Fxxxxxxxxxxxxxxx%2F%2Fxxxx&RelayState=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
When SAML authentication is complete, specify destination form field by appending :field_name to login URL.
Failed to parse XML server response
Failed to complete authentication
```
This error suggests that the VPN connection fails during **SAML-based
authentication**, specifically when attempting to parse the XML server
response. This highlights the need to address and troubleshoot the SAML flow to
ensure compatibility with the VPN system.
---
### Task Goals
1. **Reproduce the Issue Locally**
- Determine the best way to replicate this error in a **local environment**.
- Assess if **Docker-based VPN** simulation is a feasible approach for testing.
- Explore alternatives for simulating **SAML authentication**
and **GlobalProtect**-like connections for testing.
2. **Identify and Resolve the Issue**
- Investigate the root cause after reproducing the issue.
- Ensure that **authentication** and **connection** processes are functioning properly.
- Ensure that the user can reliably **connect** and **disconnect** from the VPN.
- Ensure **reliable connectivity** for various VPN types (GlobalProtect, SAML-based, etc.).
---
### Key Considerations
The final goal is to set up a **local testing environment** that simulates a
connection to corporate VPNs, reducing reliance on external services. This
ensures that the VPN client works seamlessly with the company’s existing VPN
setups. However, the local simulation may not cover all possible edge cases in
production environments, meaning that while this approach will serve as
a **starting point**, the vpn client must be robust enough to handle multiple
VPN configurations.
A simplified version of the VPN portal has been created using **Docker and
Nginx**, exposing a mock HTTPS portal for testing. This setup simulates the
connection process, but it does not fully replicate the company's specific VPN
environment, such as handling **SAML redirects** or other authentication
mechanisms. Right now this local setup is not fully finished
---
### Next Steps
1. **Test the Local Setup**
- Ensure the **Docker-based mock VPN portal** functions as expected. If it
simulates the connection process adequately, it can help identify issues
early on.
2. **Implement SAML Authentication**
- The mock portal does not include **full SAML authentication** yet. This
will need to be simulated or implemented to match the company’s VPN
authentication mechanism. Consider using tools like **SAML2JS** or other
mock SAML providers for testing.
3. **Support for Multiple VPN Configurations**
- The VPN client must support connecting to multiple VPN configurations. The
solution should include proper **error handling**, **automatic gateway
detection**, and **fallback mechanisms** for robustness.
4. **Verify Reliable Connection**
- Once the client is capable of connecting to multiple VPNs, verify that the
connection remains stable by monitoring **network activity**, checking
the **VPN tunnel’s status**, and ensuring the connection holds up across
various scenarios.
---
### References
- [GlobalProtect by Palo Alto Networks](https://www.paloaltonetworks.com/sase/globalprotect)
- [GlobalProtect OpenConnect Implementation](https://github.com/yuezk/GlobalProtect-openconnect)
- [OpenConnect GitHub Repository](https://github.com/openconnect)
---
### Conclusion
This task is a **starting point** to develop a reliable VPN client capable of
connecting to multiple VPN types, such as GlobalProtect. While the current
approach simulates some aspects of the connection process, it’s essential to
handle **SAML-based authentication** fully. The goal is to ensure that the VPN
client is robust enough to handle various VPN configurations and reliably
connect and disconnect from the VPN.
This setup will provide the foundation for further work, including the handling
of specific VPN environments and edge cases that might arise in real-world use.
The core functionality for a **PySide6-based VPN client** is in place, with the goal being to
enable a seamless connection to a company's VPN, specifically those using
Palo Alto GlobalProtect. Typically, the connection process when using a VPN
client such as **Palo Alto GlobalProtect** is straightforward:
1. **GlobalProtect software** is installed.
2. **Credentials** are stored in the system.
3. The user clicks a button to **connect to the portal**.
4. A list of available **gateways** is displayed.
5. The user selects the appropriate **gateway** and connects.
6. Once connected, the VPN is ready for use.
7. The user clicks a **disconnect** button to terminate the connection.
In this case, for this particular **PySide6** app, the connection process will
leverage the open-source **OpenConnect** tool, which supports GlobalProtect.
This task’s goal is to ensure a reliable connection process, particularly for
VPNs using **SAML-based authentication** and other advanced setups.
---
### Current Issue
When attempting to connect to real-life company, the following error would occur:
```
pyvpn.core.global_protect_service: Connecting to portal vpn.company.com...
pyvpn.core.global_protect_service:
pyvpn.core.global_protect_service: WARNING: Cannot set locale: No such file or directory
POST https://vpn.company.com/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Windows
Connected to 12.345.678.901:443
SSL negotiation with vpn.company.com
Connected to HTTPS on vpn.company.com with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA256)-(AES-256-GCM)
SAML REDIRECT authentication is required via https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/saml2?SAMLRequest=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%2Fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%2Bxxx%2Bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx%2Fxxx%2Fxxxxxxxxxxxxxxx%2F%2Fxxxx&RelayState=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
When SAML authentication is complete, specify destination form field by appending :field_name to login URL.
Failed to parse XML server response
Failed to complete authentication
```
This error suggests that the VPN connection fails during **SAML-based
authentication**, specifically when attempting to parse the XML server
response. This highlights the need to address and troubleshoot the SAML flow to
ensure compatibility with the VPN system.
---
### Task Goals
1. **Reproduce the Issue Locally**
- Determine the best way to replicate this error in a **local environment**.
- Assess if **Docker-based VPN** simulation is a feasible approach for testing.
- Explore alternatives for simulating **SAML authentication**
and **GlobalProtect**-like connections for testing.
2. **Identify and Resolve the Issue**
- Investigate the root cause after reproducing the issue.
- Ensure that **authentication** and **connection** processes are functioning properly.
- Ensure that the user can reliably **connect** and **disconnect** from the VPN.
- Ensure **reliable connectivity** for various VPN types (GlobalProtect, SAML-based, etc.).
---
### Key Considerations
The final goal is to set up a **local testing environment** that simulates a
connection to corporate VPNs, reducing reliance on external services. This
ensures that the VPN client works seamlessly with the company’s existing VPN
setups. However, the local simulation may not cover all possible edge cases in
production environments, meaning that while this approach will serve as
a **starting point**, the vpn client must be robust enough to handle multiple
VPN configurations.
A simplified version of the VPN portal has been created using **Docker and
Nginx**, exposing a mock HTTPS portal for testing. This setup simulates the
connection process, but it does not fully replicate the company's specific VPN
environment, such as handling **SAML redirects** or other authentication
mechanisms. Right now this local setup is not fully finished
---
### Next Steps
1. **Test the Local Setup**
- Ensure the **Docker-based mock VPN portal** functions as expected. If it
simulates the connection process adequately, it can help identify issues
early on.
2. **Implement SAML Authentication**
- The mock portal does not include **full SAML authentication** yet. This
will need to be simulated or implemented to match the company’s VPN
authentication mechanism. Consider using tools like **SAML2JS** or other
mock SAML providers for testing.
3. **Support for Multiple VPN Configurations**
- The VPN client must support connecting to multiple VPN configurations. The
solution should include proper **error handling**, **automatic gateway
detection**, and **fallback mechanisms** for robustness.
4. **Verify Reliable Connection**
- Once the client is capable of connecting to multiple VPNs, verify that the
connection remains stable by monitoring **network activity**, checking
the **VPN tunnel’s status**, and ensuring the connection holds up across
various scenarios.
---
### References
- [GlobalProtect by Palo Alto Networks](https://www.paloaltonetworks.com/sase/globalprotect)
- [GlobalProtect OpenConnect Implementation](https://github.com/yuezk/GlobalProtect-openconnect)
- [OpenConnect GitHub Repository](https://github.com/openconnect)
---
### Conclusion
This task is a **starting point** to develop a reliable VPN client capable of
connecting to multiple VPN types, such as GlobalProtect. While the current
approach simulates some aspects of the connection process, it’s essential to
handle **SAML-based authentication** fully. The goal is to ensure that the VPN
client is robust enough to handle various VPN configurations and reliably
connect and disconnect from the VPN.
This setup will provide the foundation for further work, including the handling
of specific VPN environments and edge cases that might arise in real-world use.