Wireguard with NetworkManager - eviltoast

Hello guys,

I am losing my mind over this issue:

I am running Endeavour OS on my laptop and I need to connect to my OPNSense through wireguard, but the performance has been terrible, DNS resolution to be precise. I think this is related to a specific configuration to either NetworkManager or openresolv, because the same configuration file works fine on Android or Windows devices.

My suspicions are that because I am using two piholes that are on the same network of the OPNSense router (and I have a few firewall rules redirecting every DNS traffic to them), there is a conflict somewhere. I have also tried to mess around with the MTU size, but to no avail.

Here is my config file:

[Interface]
PrivateKey = ****************************************
Address = 10.10.10.5/32
DNS = 192.168.0.11, 192.168.0.12
MTU = 1420

[Peer]
PublicKey = ****************************************
AllowedIPs = 0.0.0.0/0, ::/0, 192.168.0.0/24
Endpoint = ******************:51825

Any ideas? Thank you.

  • mintyfrog@lemmy.ml
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    Just checking: this is using a different PrivateKey and Address than the Windows and Android devices?

    • utubas@lemm.eeOP
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Well I use the exact same config file for troubleshooting, but yes I am aware that each device needs its own private/pubkey and address.

  • Zadeis@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    I was dealing with wire guard dns issues recently. What is the interface set to in settings > DNS? I had to set mine to permit all origins for pihole to play nice with wireguard.

    • utubas@lemm.eeOP
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      Oh I think that can be an issue! It was only allowing local requests, one hop away. Perhaps I should configure for eth0

      EDIT: I think it worked! Only the secondary DNS server was set to listen to eth0, so perhaps the delay was caused by that. Many thanks!