10
9
Fork
You've already forked linux-app
14

NM with dual stacked wireguard endpoint #695

Open
opened 2026年04月24日 17:09:18 +02:00 by flaruina · 2 comments
Contributor
Copy link

Hi,
we noticed that on a Debian 13 machine with eduvpn 4.71 (installed via apt) and ipv4 only connectivity when we connect via wireguard to a dual stacked endpoint, NM resolves its the name and establishes the connection.

The machine gets a IPv6 GUA in the tunnel and after a couple of seconds, when NM re-resolves the endpoint name it modifies the wireguard endpoint IP setting the v6 address (reachable via VPN). This operation breaks the connectivity since the v6 address is not reachable via the main interface.

It seems to be an issue with how NetworkManager manages wg endpoints expressed as names (they take the first result of getaddrinfo).

From https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.41.7-dev/src/core/devices/nm-device-wireguard.c#L44

/* TODO: when we get multiple IP addresses when resolving a peer endpoint. We currently
 * just take the first from GAI. We should only accept AAAA/IPv6 if we also have a suitable
 * IPv6 address. The problem is, that we have to recheck that when IP addressing on other
 * interfaces changes. This makes it almost too cumbersome to implement. */

Here (flaruina/linux-app@69f85172d4) I tried a workaround
in linux-app passing to NetworkManager the IP as reported by getaddrinfo before establishing the tunnel.

I understand this is a workaround and should be fixed upstream in NM but is there a better way in the meantime?

Hi, we noticed that on a Debian 13 machine with eduvpn 4.71 (installed via apt) and ipv4 only connectivity when we connect via wireguard to a dual stacked endpoint, NM resolves its the name and establishes the connection. The machine gets a IPv6 GUA in the tunnel and after a couple of seconds, when NM re-resolves the endpoint name it modifies the wireguard endpoint IP setting the v6 address (reachable via VPN). This operation breaks the connectivity since the v6 address is not reachable via the main interface. It seems to be an issue with how NetworkManager manages wg endpoints expressed as names (they take the first result of getaddrinfo). From https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.41.7-dev/src/core/devices/nm-device-wireguard.c#L44 ``` /* TODO: when we get multiple IP addresses when resolving a peer endpoint. We currently * just take the first from GAI. We should only accept AAAA/IPv6 if we also have a suitable * IPv6 address. The problem is, that we have to recheck that when IP addressing on other * interfaces changes. This makes it almost too cumbersome to implement. */ ``` Here (https://codeberg.org/flaruina/linux-app/commit/69f85172d4ff7c13c46f997619c06d7ae929be70) I tried a workaround in linux-app passing to NetworkManager the IP as reported by `getaddrinfo` before establishing the tunnel. I understand this is a workaround and should be fixed upstream in NM but is there a better way in the meantime?

Hi, sorry for the radio silence. I think doing a DNS request in the client is too hacky, but maybe we can guard it behind an env variable. What do you think?

Hi, sorry for the radio silence. I think doing a DNS request in the client is too hacky, but maybe we can guard it behind an env variable. What do you think?
Author
Contributor
Copy link

No worries. Could you elaborate more on your idea?

Do you mean doing the exact same thing (solving in the client) but only if an env variable is set or something else?

No worries. Could you elaborate more on your idea? Do you mean doing the exact same thing (solving in the client) but only if an env variable is set or something else?
Sign in to join this conversation.
No Branch/Tag specified
master
upstream-deb
openvpn-persistent
1.x
4.7.2
4.7.1
4.7.0
4.6.0
4.5.1
4.5.0
4.4.99.0
4.4.0
4.3.1
4.3.0
4.2.99.1
4.2.99.0
4.2.1
4.2.0
4.1.99.0
4.1.3
4.1.2
4.1.1
4.1.0
3.1.1
4.0.1
4.0.0
pr-3.3.1
pr-3.3.0
pr-3.2.0
3.1.0
3.0.0
2.2.1
2.2.0
2.1.0
2.0.0
1.1
1.0.3
1.0.2
1.0.1
1.0rc17
1.0rc16
1.0rc15
1.0rc14
1.0rc13
1.0rc12
1.0rc11
1.0rc10
1.0rc9
1.0rc8
1.0rc7
1.0rc6
1.0rc5
1.0rc4
1.0rc3
1.0rc2
1.0rc1
0.8
0.7.2
0.7.1
0.7
0.6.1
0.6
0.5.1
0.5
0.3
0.2.1
0.2
0.1.1
0.1
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
eduVPN/linux-app#695
Reference in a new issue
eduVPN/linux-app
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?