You are not logged in.
So, my company uses AWS VPN for connection. I am using the `awsvpnclient` package on AUR (which interfaces with `systemd-resolve`), everything works correctly so far.
However, recently, the DNS resolution starts failing. After some investigation, I found that the reason is because our company's domain is visible both publicly and privately. When I request the private URL, a request is sent to both domains, and if the public domain comes back with a "does not exist" response first, then the DNS resolution will report failure without waiting for the private domain to respond. This is because DNS resolution reports the first "success" response, and a "does not exist" response is technically a "success" (a failure would be timing out, or other errors).
After some more investigation, I found out that by running the command `sudo resolvectl domain tun0 ~.` after the VPN interface starts up, I can make the VPN the preferred interface for domain resolution, and the problem is solved.
However, running this command every time I start up VPN is a little tedious (and sometimes I forgot). So I wish that this can be done automatically. My questions are:
- Is there a way to modify/edit the `.ovpn` profile (which awsvpnclient supports), so that this domain setup is configured by awsvpnclient automatically?
- If not, is there a way to patch awsvpnclient to perform this configuration?
- Finally, is this something that has to be done on the VPN server side, instead of client side? If I were to give my sysadmin instructions, what should he look into?
Thanks for all the help.
Last edited by pkerichang (2024-10-25 16:14:20)
Offline
I don't know the direct answers to your questions, but it seems an easy solution would be to create a system service that you start when you want to connect and stop when you want to disconnect. A service file and a simple script could do the trick.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
After some investigation, I found that the reason is because our company's domain is visible both publicly and privately. When I request the private URL, a request is sent to both domains, and if the public domain comes back with a "does not exist" response first, then the DNS resolution will report failure without waiting for the private domain to respond. This is because DNS resolution reports the first "success" response, and a "does not exist" response is technically a "success" (a failure would be timing out, or other errors).
Can you give an example of this behavior to clarify the scope?
Offline
So the way I debug this is:
- on one terminal, run "sudo resolvectl monitor" to monitor all "systemd-resolve" requests in real time.
- on another terminal, start running "resolvectl query foo.bar.company.com" to query the internal URL (names obviously swapped out).
- 99% of the time, the result of the query is:
foo.bar.company.com: resolve call failed: 'foo.bar.company.com' does not have any RR of the requested type
and on the monitor query terminal, the message will look like:
→ Q: foo.bar.company.com IN A
→ Q: foo.bar.company.com IN AAAA
← S: success
← A: company.com IN <blah blah blah>
- 1% of the time, the result of the query is:
foo.bar.company.com: <IP address> -- link: tun0
(<some internal AWS URL>)
-- Information acquired via protocol DNS in 144.0ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: cache
and the monitoring terminal output shows some successful traces that goes through AWS DNS lookup.
since "company.com" is a public URL, these log messages (and inconsistency) convinces me that it is a DNS lookup race condition issue, where usually the wifi interface `wlp1s0` wins. Indeed, after setting the VPN interface to be the preferred domain (via `systemd-resolve` documentation), all the queries goes through the tun0 interface as expected.
Offline
To clarify things: You want "*.bar.company.com" (1 subdomain) only resolved via VPN tunnel and don't mind resolving "*.other.company.com" via public DNS?
Or should "*.company.com" (all subdomains) only resolved via VPN tunnel?
Last edited by -thc (2024-10-25 15:39:43)
Offline
I don't mind resolving ALL URLs through the VPN interface. The reason is because the internal company subdomain URL actually gets resolved to an AWS URL first, which no longer lives in our companies domain, and I am not even sure our internal URL maps to a consistent AWS domain/subdomain name.
our company VPN is configured to fallback to a public DNS resolver anyways, so this setup is fine.
Offline
Have you tried the link from the comment section of awsvpnclient's AUR page?
https://docs.aws.amazon.com/vpn/latest/ … nameserver
Offline
Somehow I completely missed that. Adding
dhcp-option DOMAIN-ROUTE .
to the .ovpn profile indeed does this exact configuration. Thanks!.
Offline