bug(headless-client): adding service actor to group only takes effect after restarting the Client about firezone HOT 10 OPEN

I was using curl the whole time, no browser involved. It's possible that there is some DNS caching in systemd that gets reset when the tunnel goes down and back up?

I've never seen that, maybe a portal bug? we should print the resources with on_update_resources and check if it's actually there.

from firezone.

Looks like I already had tracing::debug in on_update_resources and it's definitely getting called as soon as I click in the portal.

Actually, the "everyone" group has ifconfig.net as a resource, so I'm not sure why it doesn't route through Firezone all the time. I'm seeing DEBUG showing ifconfig.net as a resource both when I add and when I remove it from my personal group.

That's weird, for service account everyone shouldn't be included

from firezone.

I just repro'd this by adding/disabling my allow policy for ifconfig.

Turns out it does seem like systemd-resolved cache responses :(

Seems like queries are just sent to 127.0.0.53:53 where the cache just responds and this cache is as long as the TTL so that's why it only happens when going from disable to enable and not the other way around.

Using etc-resolv-conf "fixes" this for me. Does the same happen for you?

from firezone.

I saw Note: Users will always belong to the Everyone group. even though it's a service account so that's why I assumed.
Opened a ticket asking to clarify #5064

from firezone.

Does closing and re-opening the browser solves it?

What does curl ifconfig.net shows?

from firezone.

I was using curl the whole time, no browser involved. It's possible that there is some DNS caching in systemd that gets reset when the tunnel goes down and back up?

from firezone.

Looks like I already had tracing::debug in on_update_resources and it's definitely getting called as soon as I click in the portal.

Actually, the "everyone" group has ifconfig.net as a resource, so I'm not sure why it doesn't route through Firezone all the time. I'm seeing DEBUG showing ifconfig.net as a resource both when I add and when I remove it from my personal group.

from firezone.

Yeah I'm seeing the same thing:

• etc-resolv-conf doesn't have this issue (but I had to set 1.1.1.1 as my upstream resolver, resolv.conf and systemd-resolved didn't seem to play along)
• Removing the actor from the group applies instantly even with systemd-resolved

from firezone.

Yeah I'm seeing the same thing:

* `etc-resolv-conf` doesn't have this issue (but I had to set 1.1.1.1 as my upstream resolver, resolv.conf and systemd-resolved didn't seem to play along)

* Removing the actor from the group applies instantly even with `systemd-resolved`

Yeah, removing works instantly because our TTL is 1 but probably the real TTL is much greater and systemd-resolved caches it as long as the TTL (or at least hinted by it)

Even with #4994 this won't be solved since once the IP, but-- maybe a simple solution is mangling the DNS response to always have a low TTL (though this would only work with UDP requests), then we could even do the caching ourselves.

from firezone.

I mean here we can add something like:

message.answers_mut().iter().for_each(|a| a.set_ttl(1));

from firezone.