Wireguard VPN handshake successful but no traffic/ ping

linux-aarhus · 12 November 2023 07:39

As I said - my knowledge of wireguard is zero.

But - in a normal VPN scenario - if you use the same subnet on both sides you will likely be able to create a connection - handshake - but as the subnet on both sides are identical - there can be no route - where should it go?

I expect wireguard to act similarly … which is likely why you cannot get traffic to flow - there is nowhere it can flow when subnets are the same.

You need a direction one subnet to another.

Just a thought - you are completely certain you can reach your local network from outside - your ISP is allowing incoming traffic and you can open ports into your network?

I know that some ISP works like a cellular provider - they assign the mobile device an IP on a private subnet - usually the 10.x.x.x network - thus you can never reach a mobile device by simply knowing it’s ip due to provider blocking incoming connections.

The same can be done using IPv6 - so if your homebox is on IPv6 and no incoming traffic allowed - you may need a peer - e.g. vps which your homebox connects to - this will allow for a connection as the connection is made from inside your network to your peer server - and when you connect to your peer server - you have access to your home lan.

Nord VPN has something called Meshnet - I believe this is exactly what they are doing with their Nordlynx technology.

Remote access software like Teamviewer et.al. is doing much the same - they punch an outgoing hole in the firewall by connecting to a peer server - then you can get inside using that hole to access the device which initiated the connection.

Digital ocean has articles on setting up wireguard

https://sx.nix.dk/search?q=digital ocean setup wireguard peer

Also see WireGuard - ArchWiki

MajorMayer · 12 November 2023 08:01

That’s why I changed my remote network to be 192.168.1.0/24 while my home network is 192.168.0.0/24 and my hope is that Wireguard can create the route to connect both networks.

Yes I am because I used WireGuard VPN before on another PC and remote network to connect to my home network, which worked just fine.
Also, I have a couple of web services (Nextcloud etc.) running in my home network which I can reach with no problem via IPv4 or 6 (DynDNS + port forwarding to the web server).
So there should be no need for some STUN techniques (I guess that’s what TeamViewer and other services try to archive in the end).

linux-aarhus · 12 November 2023 08:03

That is good to know. At least from a troubleshooting perspective.

That is the word I was looking for …

The Arch wiki link - scroll down to 6.5 … se if it makes sense

Wireguard knowledge has been on my todo list - I have not had the time or energy (brains) to attack it.

MajorMayer · 12 November 2023 08:21

I’ve read through the troubleshooting tips from the Arch Wiki already, but no luck there unfortunately
The persistent keep alive setting was already active on my connection.
But thank you (all of you) anyway for your help
And yeah Wireguard is definitely an interesting topic to read into.

anon51566685 · 12 November 2023 08:56

I’m talking about virtual network between wireguard peers. There is no default, it’s whatever you put on wg interface. (Anyway, this isn’t the problem now, since you changed it so it differs from your lan network hopefully.)

I’m talking about this:

Last time I setup wireguard there were only 2 iptables rules. No fwmarks, no additional tables or anything fancy.

You still didn’t answer what do you want to do with this tunnel. Connect what from where to reach what?

Also can you show .conf on both sides (again). (Things like allowed ips: 192.168.0.0/24, 0.0.0.0/0 don’t make sense.)

mithrial · 12 November 2023 09:40

The generated config from the Fritzbox is setting up split tunnelling and doesn’t set the routes correctly (I think).

I’ve configured it yesterday for systemd-networkd and I had to configure additional settings. Before, I had only access to the LAN of the box but not outside via the router.

Anyway, are you testing your connection while inside your LAN?

Do you have any other VPN that might have added weird routes (like a safety block or however they call it).

MajorMayer · 12 November 2023 13:10

Ahh that’s what you mean, I see.
That’s all created by wg-quick when I activate my VPN connection based on the settings from here:

MajorMayer:

[Interface]
PrivateKey = xxxx
Address = 192.168.0.201/24
DNS = 192.168.0.1
DNS = fritz.box

[Peer]
PublicKey = xxx
PresharedKey = xxx
AllowedIPs = 192.168.0.0/24,0.0.0.0/0
Endpoint = xxx.myfritz.net:58130
PersistentKeepalive = 25

… which were automatically generated by FritzBox.
I dd not change anything of this configuration and have no idea what or why WireGuard is creating the iptables like it does.

I basically want to connect from a remote network to my LAN, because I need to access servers that are not reachable from the internet (which is intended).

The client configuration on my laptop (remote) is the one that I quoted. It has not changed.
The FritzBox configuration looks like this (at least that’s what the UI lets me know):

[Interface]
PrivateKey = XXX=
ListenPort = 58130
Address = 192.168.0.1/24
DNS = 192.168.0.1
DNS = fritz.box

[Peer]
PublicKey = 0atflG8Sas8Seiu5eyFTe0udcgDfgFvTUPnorcuZi3k=
PresharedKey = XXX=
AllowedIPs = 192.168.0.202/32
PersistentKeepalive = 25
[Peer]
PublicKey = LXfTVriqw/cNMIKyuK9B7RupZhyZk0LETiJ50HCfsHg=
PresharedKey = XXX=
AllowedIPs = 192.168.0.201/32
PersistentKeepalive = 25

I also wondered why there are two allowed IPs when 0.0.0.0/0 should already include everything, but that’s what FritzBox generated. I guess/ hope they have their reasons.

I have no idea what it means, but probably yes.

No I am testing it from a remote network. IIRC from within the LAN the connection was possible, but not 100% sure about this.

As far as I know, no I don’t. At least nothing active.

Actually my last statement wasn’t 100% true, because I finally managed to establish a working VPN tunnel to my FritzBox
But it was not with WireGuard, but instead over IPSec, the other (legacy?) option that FritzBox gives you.

For some reason, in this case the connection is successful, and I can actually send data/ ping / reach my internal websites.
This makes debugging a lot easier, because I don’t need to call my family members at home to test a setting/ get some logs .

So it’s by far not as critical anymore, but it would be nice to know why my IPSec configuration is working, but my Wireguard one isn’t.
Here is the IP configuration for IPSec:

ip addr                                                                                                                    ✔
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 34:7d:f6:8e:6e:a3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.58/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp0s20f3
       valid_lft 597447sec preferred_lft 597447sec
    inet6 fe80::55ba:ff3b:a12b:5901/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:1b:79:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
6: br-b70272889e99: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:73:32:5f:b6 brd ff:ff:ff:ff:ff:ff
    inet 172.26.1.1/24 brd 172.26.1.255 scope global br-b70272889e99
       valid_lft forever preferred_lft forever
7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:c5:fe:e3:31 brd ff:ff:ff:ff:ff:ff
    inet 172.26.0.1/24 brd 172.26.0.255 scope global docker0
       valid_lft forever preferred_lft forever
19: enp0s13f0u1u4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:e0:4c:68:05:d1 brd ff:ff:ff:ff:ff:ff
34: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none
    inet 192.168.0.203/24 brd 192.168.0.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::12be:9690:bd7c:145c/64 scope link stable-privacy proto kernel_ll
       valid_lft forever preferred_lft forever

And here for WireGuard:

ip addr                                                                                                    PIPE ✘  3m 33s 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 34:7d:f6:8e:6e:a3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.58/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp0s20f3
       valid_lft 597539sec preferred_lft 597539sec
    inet6 fe80::55ba:ff3b:a12b:5901/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:1b:79:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
6: br-b70272889e99: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:73:32:5f:b6 brd ff:ff:ff:ff:ff:ff
    inet 172.26.1.1/24 brd 172.26.1.255 scope global br-b70272889e99
       valid_lft forever preferred_lft forever
7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:c5:fe:e3:31 brd ff:ff:ff:ff:ff:ff
    inet 172.26.0.1/24 brd 172.26.0.255 scope global docker0
       valid_lft forever preferred_lft forever
19: enp0s13f0u1u4: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:e0:4c:68:05:d1 brd ff:ff:ff:ff:ff:ff
32: wg_config: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 192.168.0.201/24 brd 192.168.0.255 scope global noprefixroute wg_config
       valid_lft forever preferred_lft forever

anon51566685 · 12 November 2023 13:25

Thanks for info. Can you also include (I know, some of things you already did, but still):

sudo iptables-save # double-check for any public IPs and replace them if necessary
ip route show table all
ip rule

Another thing you can try is set AllowedIPs = 192.168.1.0/24 on your client (laptop) config:

And you said you can reach this xxx.myfritz.net from outside right?

MajorMayer · 12 November 2023 14:06

Yes, i can reach it.

Actually, WireGuard finally works as well too.
And I can in part explain it for anybody else who might stumble across this.
I think it’s a combination of multiple factors that were playing a crucial role.

So the customer service told me that I have two VPN connections in the FritzBox system, one is the IPSec based one and the other the WireGuard.
For whatever reason, FritzBox created the WireGuard connection/ configuration with the same virtual IP address (192.168.0.202) as the existing IPSec one (I think i created this one earlier).
It could be that there was a bug in the FritzBox software that decided on the IP addresses when creating a new configuration, which led let to this overlap.
I started using the at that time experimental WireGuard support as soon as it was released, so maybe there were some check missing back then (you cannot manually set the IP address in the UI).
This explains for me why the IPSec configuration was not working until I recreated it today (it got assigned a different IP address (192.168.0.203), which is unique).

WireGuard is a bit complicated, and I’m not 100% sure what went wrong.
First, I must say that the WireGuard support in the settings is really far from perfect.
For example, I noticed, that when you set MTU in the dialogue here:

…it doesn’t save the value and always resets it to 0 (which actually translated to 1420 bytes when you create the interface).
Only if you use the -/+ to enter the value, it will actually get saved and applied.

Then I noticed that when you import the WireGuard config using the settings UI and activate the VPN, the ip addr configuration looks slightly different then the one generated by wg-quick.

Gnome Settings:

54: wg_config: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 192.168.0.201/24 brd 192.168.0.255 scope global noprefixroute wg_config
       valid_lft forever preferred_lft forever

wg-quick:

55: fritzbox: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 192.168.0.201/24 scope global fritzbox
       valid_lft forever preferred_lft forever

Not related to my issue (I should probably report this upstream)
Also, I had to change the endpoint from the myfritz.net domain to my DynDNS, because otherwise the value was not accepted on the import.
You also can’t disable the VPN connection created by wg-quick using the settings UI. It disappears but stays active.
End

Furthermore, I noticed that for whatever reason the packet loss is way higher when you create the VPN with Gnome settings in comparison to wg-quick (I know doesn’t make sense, but that’s just my observations. Probably has a different cause).
It could be that I sometimes simply didn’t wait long enough when I tried pinging my LAN devices.

Gnome settings:

--- 192.168.0.1 ping-Statistik ---
118 Pakete übertragen(sent), 110 empfangen (received), 6.77966% packet loss, time 117242ms
rtt min/avg/max/mdev = 295.280/334.844/525.726/40.173 ms

wg-quick:

--- 192.168.0.1 ping-Statistik ---
54 Pakete übertragen, 54 empfangen, 0% packet loss, time 53008ms
rtt min/avg/max/mdev = 313.936/342.954/420.911/33.108 ms

I tried adding this network range this to the client config and the connection was established successfully, but in the end it worked without this addition as well, so idk…

Bottom Line:
Check your router config for any duplicated IPs in both VPN tabs, and setup WireGuard VPN with wg-quick not Gnome settings.

Edit: Yeah, the WireGuard Gnome support is really buggy…
I wonder how this could get merged at such a bad state:

MajorMayer · 12 November 2023 14:14

And here just for documentation purposes the whole iptables (when creating the WG config with wg-quick:

# Generated by iptables-save v1.8.9 on Sun Nov 12 22:11:16 2023
*mangle
:PREROUTING ACCEPT [3435600:6002132973]
:INPUT ACCEPT [3435524:6002113650]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [24199144:17224727681]
:POSTROUTING ACCEPT [24210110:17225985057]
:LIBVIRT_PRT - [0:0]
-A POSTROUTING -j LIBVIRT_PRT
-A LIBVIRT_PRT -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT
# Completed on Sun Nov 12 22:11:16 2023
# Generated by iptables-save v1.8.9 on Sun Nov 12 22:11:16 2023
*nat
:PREROUTING ACCEPT [2537:630411]
:INPUT ACCEPT [2505:616174]
:OUTPUT ACCEPT [53379:7392409]
:POSTROUTING ACCEPT [53162:7359208]
:DOCKER - [0:0]
:LIBVIRT_PRT - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.26.0.0/24 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 172.26.1.0/24 ! -o br-b70272889e99 -j MASQUERADE
-A POSTROUTING -j LIBVIRT_PRT
-A DOCKER -i docker0 -j RETURN
-A DOCKER -i br-b70272889e99 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A LIBVIRT_PRT -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT
# Completed on Sun Nov 12 22:11:16 2023
# Generated by iptables-save v1.8.9 on Sun Nov 12 22:11:16 2023
*filter
:INPUT ACCEPT [3435514:6002112653]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [24199128:17224726743]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
:LIBVIRT_FWI - [0:0]
:LIBVIRT_FWO - [0:0]
:LIBVIRT_FWX - [0:0]
:LIBVIRT_INP - [0:0]
:LIBVIRT_OUT - [0:0]
-A INPUT -j LIBVIRT_INP
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -o br-b70272889e99 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o br-b70272889e99 -j DOCKER
-A FORWARD -i br-b70272889e99 ! -o br-b70272889e99 -j ACCEPT
-A FORWARD -i br-b70272889e99 -o br-b70272889e99 -j ACCEPT
-A FORWARD -j LIBVIRT_FWX
-A FORWARD -j LIBVIRT_FWI
-A FORWARD -j LIBVIRT_FWO
-A OUTPUT -j LIBVIRT_OUT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -i br-b70272889e99 ! -o br-b70272889e99 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -o br-b70272889e99 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
-A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 68 -j ACCEPT
COMMIT
# Completed on Sun Nov 12 22:11:16 2023

ip route show table all                                                                                                   INT ✘ 
default dev fritzbox table 51820 scope link 
default via 192.168.1.1 dev wlp0s20f3 proto dhcp src 192.168.1.58 metric 600 
172.26.0.0/24 dev docker0 proto kernel scope link src 172.26.0.1 linkdown 
172.26.1.0/24 dev br-b70272889e99 proto kernel scope link src 172.26.1.1 linkdown 
192.168.0.0/24 dev fritzbox proto kernel scope link src 192.168.0.201 
192.168.1.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.1.58 metric 600 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 172.26.0.1 dev docker0 table local proto kernel scope host src 172.26.0.1 
broadcast 172.26.0.255 dev docker0 table local proto kernel scope link src 172.26.0.1 linkdown 
local 172.26.1.1 dev br-b70272889e99 table local proto kernel scope host src 172.26.1.1 
broadcast 172.26.1.255 dev br-b70272889e99 table local proto kernel scope link src 172.26.1.1 linkdown 
local 192.168.0.201 dev fritzbox table local proto kernel scope host src 192.168.0.201 
broadcast 192.168.0.255 dev fritzbox table local proto kernel scope link src 192.168.0.201 
local 192.168.1.58 dev wlp0s20f3 table local proto kernel scope host src 192.168.1.58 
broadcast 192.168.1.255 dev wlp0s20f3 table local proto kernel scope link src 192.168.1.58 
local 192.168.122.1 dev virbr0 table local proto kernel scope host src 192.168.122.1 
broadcast 192.168.122.255 dev virbr0 table local proto kernel scope link src 192.168.122.1 linkdown 
fe80::/64 dev wlp0s20f3 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::55ba:ff3b:a12b:5901 dev wlp0s20f3 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev wlp0s20f3 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev fritzbox table local proto kernel metric 256 pref medium

ip rule                                                                                                                       ✔ 
0:	from all lookup local
32764:	from all lookup main suppress_prefixlength 0
32765:	not from all fwmark 0xca6c lookup 51820
32766:	from all lookup main
32767:	from all lookup default

MajorMayer · 12 November 2023 14:18

Thank you all again for your great support!
Manjaro really has a super helpful community

anon51566685 · 12 November 2023 14:29

I imagine GNOME uses NetworkManager just like for example KDE Plasma. And I have multiple wg tunnels setup in Plasma without any problems.

Thanks. Yes I see there is no iptables rules at all and tunnel relies on policy routing.
That wording though…

32765:	not from all fwmark 0xca6c lookup 51820

…makes it hard to understand what that not actually does.
“from all not fwmark …” would make more sense. Will need to open man pages and read I guess.

Perhaps this is more elegant solution after all. Will need to test it.

MajorMayer · 12 November 2023 14:47

On Plasma, I never had this type of issues, it really seems to be about the frontend implementation in Gnome settings.
But yeah, as far as I’m concerned, it uses NetworkManager under the hood.

system · 14 November 2023 02:48

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.