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
I've identified an issue with our DefGuard client on macOS regarding DNS configuration. It's causing some problems for our users, and I think we should address it soon.
Issue Description
When a user connects to our VPN on macOS, we're correctly setting the VPN's DNS. However, upon disconnection, we're not properly restoring the original DNS settings. Instead, we're clearing the DNS configuration entirely.
Current Behavior
On VPN connect:
Client replaces existing DNS with VPN's DNS.
On VPN disconnect:
Client clears all DNS settings instead of restoring the original configuration.
Expected Behavior
On VPN connect:
Client should backup current DNS settings.
Add VPN's DNS to existing configuration (not replace entirely).
On VPN disconnect:
Remove only the DNS entries added by our VPN.
Restore the original DNS settings from the backup.
Steps to Reproduce
Check and note current DNS settings on macOS.
Connect to our VPN.
Verify DNS has changed to VPN's settings.
Disconnect from VPN.
Check DNS settings - they will be empty, not reverted to original settings.
Proposed Solution
We need to modify our https://github.com/DefGuard/wireguard-rs to implement the following logic:
Connection:
Backup current DNS settings.
Add VPN's DNS entries to existing configuration.
Disconnection:
Remove only the DNS entries added by our VPN.
Restore original DNS settings from backup.
Key Suggestion:
Instead of replacing the entire DNS configuration when connecting, we should only add new entries for the VPN's DNS. Then, when disconnecting, we can simply remove these added entries. This approach should maintain the user's original DNS configuration while ensuring our VPN works correctly.
Are we correctly storing the original DNS settings during backup?
How can we keep track of the DNS entries we've added to facilitate easy removal later?
Is there a macOS-specific API we should be using for more effective DNS management?
How can we ensure that our added DNS entries take precedence without completely overriding the existing configuration?
Impact
This issue affects all macOS users of our VPN client. It's not breaking functionality, but it's definitely impacting user experience. Users are left without proper DNS configuration after disconnecting, potentially causing temporary network issues.
Let me know if you need any additional information or if you'd like to discuss this further.
Thanks for your help!
The text was updated successfully, but these errors were encountered:
Hi team,
I've identified an issue with our DefGuard client on macOS regarding DNS configuration. It's causing some problems for our users, and I think we should address it soon.
Issue Description
When a user connects to our VPN on macOS, we're correctly setting the VPN's DNS. However, upon disconnection, we're not properly restoring the original DNS settings. Instead, we're clearing the DNS configuration entirely.
Current Behavior
Expected Behavior
Steps to Reproduce
Proposed Solution
We need to modify our
https://github.com/DefGuard/wireguard-rs
to implement the following logic:Key Suggestion:
Instead of replacing the entire DNS configuration when connecting, we should only add new entries for the VPN's DNS. Then, when disconnecting, we can simply remove these added entries. This approach should maintain the user's original DNS configuration while ensuring our VPN works correctly.
Code Areas to Investigate
wgapi_userspace.rs
:configure_dns()
methodremove_interface()
method (specifically macOS sections)Questions to Consider
Impact
This issue affects all macOS users of our VPN client. It's not breaking functionality, but it's definitely impacting user experience. Users are left without proper DNS configuration after disconnecting, potentially causing temporary network issues.
Let me know if you need any additional information or if you'd like to discuss this further.
Thanks for your help!
The text was updated successfully, but these errors were encountered: