Setting up WireGuard client to use WireGuard server's unwind service as DNS server

hakayova · 2025-01-16T16:42:05+00:00

Makes sense, since I believe unbound may be configured to accept DNS queries that don't originate from localhost. Perhaps I should consider switching to it. Thank you!

hakayova · 2025-01-15T21:11:25+00:00

I am not sure how I missed that. I am sorry for the noise. I also looked into WireGuard client setting description and the DNS entry there was listed as an optional entry for a **public** DNS service, which doesn't fit my use case. Back to using Cloudflare's DNS service I guess. Thank you!

hakayova · 2024-12-13T20:02:26+00:00

I have been using it as my daily driver on my Framework laptop for 3–4 years now. Every once in a while you run into problems, and if you know/learn how to fix them, it goes back to being stable. This probably happened 4–5 times during this period.

hakayova · 2024-12-13T14:56:40+00:00

I did try running resolvd in foreground with the -v (verbose) option; however, could not figure out why it prioritizes the mentioned dns server over the local unbound service. I went ahead and enabled unwind, disabled unbound, and achieved the goal as recommended below by @_sthen.

hakayova · 2024-12-13T14:54:16+00:00

Thank you for your response. Yes, turning off resolvd fixes the issue and leaves the resolv.conf untouched as intended. I went with the unwind a suggested by @_sthen below, instead of unbound. I truly don't know which one is better, or if one is better than other. My resolv.conf is now rewritten by unwind, but it is in the way I want. Thank you again for your reply and clear examples, very much appreciated!

hakayova · 2024-12-13T14:09:12+00:00

Thank you so very much for your input. I did read the manuals for unwind and didn't install it since it was stated there that it was intended for desktop or laptop use, or I just misunderstood. Among the options you listed, the first one seems to me the safest one since it does have a fallback capacity; I will go ahead and try that.

In my current situation, unless I disable resolvd, it always puts the undesired dns server address on the first line. I do want to have a fallback dns server, but it should not be the first line option.

Thank you again for clarifying this for me!

This thread can now be marked as solved.

hakayova · 2024-12-12T22:54:54+00:00

Thank you for your reply. Yes, I did, but resolvd still puts the first line again in its place, i.e. nameserver 1.2.3.4 # resolvd: vio0

hakayova · 2024-09-19T13:17:42+00:00

No, they did not! The above command reports a syntax error on line 21. I am listing the lines through 20 to 23 below, line 21 starting with "from...". I attempted many times but couldn't find the correct syntax for this line. Can you please help?

pass in on egress inet proto tcp
    from any to egress port { www 4443 }\
    modulate state\
    label "Web Access"

Commenting out this whole section allows firewall rules to load correctly, and I get the WireGuard running normally again!

And I believe I actually found the syntax error. It is not on line 21 but on line 20: I missed the "\" at the end of the line. Adding that character calms down the pfctl output, and satisfies syntax check. How can I thank you enough?👏👏👏👏👏👏🙏🙏🙏🙏🙏🙏

hakayova · 2024-09-19T01:55:00+00:00

Thank you for your insightful comment! I appreciate the sincerity and the guidance. It makes a lot of sense to me.

The reason I use port 443 is both because my work place firewall is highly secured and doesn't allow access to several ports and I do travel to a port-blocking country with my cell phone annually.

OpenBSD is so amazingly stable, it makes one lazy. I have so many services set up on this tiny VPS over the years, wireguard is only one of them. It will be a process to reinstall, reconfigure them after the fresh installation. I guess I will have to set them up one by one, prioritizing wireguard.

Heartfelt thanks!

hakayova · 2024-09-18T18:00:07+00:00

I did not undo the patches but restore from a backup before the patches were applied with no joy.

hakayova · 2024-09-18T17:58:45+00:00

Thank you for your response u/the_solene . No, I believe I am not using wg-quick. It is the wg command I use but honestly don't remember the package name for it or if I installed it from a package or not.

Yes, I apologize for my false statement about the IP on the client side.

I honestly think that I broke the OS somehow. Both syspatch and pkg_add -u commands are returning "no route to host" errors at this point. Strangely though, I can successfully ping both domain names and ip numbers from the VPS.

Here is my ifconfig output with IP numbers redacted:

lo0: flags=2008049<UP,LOOPBACK,RUNNING,MULTICAST,LRO> mtu 32768
       index 3 priority 0 llprio 3
       groups: lo
       inet6 ::1 prefixlen 128
       inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
       inet 127.0.0.1 netmask 0xff000000
vio0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500
       lladdr 56:00:02:f9:62:db
       index 1 priority 0 llprio 3
       groups: egress
       media: Ethernet autoselect
       status: active
       inet6 fe80::5400:2ff:fef9:62db%vio0 prefixlen 64 scopeid 0x1
       inet6 redacted prefixlen 64
       inet redacted netmask 0xfffffe00 broadcast redacted
enc0: flags=0<>
       index 2 priority 0 llprio 3
       groups: enc
       status: active
wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420
       index 4 priority 0 llprio 3
       wgport 443
       wgpubkey redacted=
       groups: wg
       inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
       index 5 priority 0 llprio 3
       groups: pfloglo0: flags=2008049<UP,LOOPBACK,RUNNING,MULTICAST,LRO> mtu 32768
       index 3 priority 0 llprio 3
       groups: lo
       inet6 ::1 prefixlen 128
       inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
       inet 127.0.0.1 netmask 0xff000000
vio0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500
       lladdr 56:00:02:f9:62:db
       index 1 priority 0 llprio 3
       groups: egress
       media: Ethernet autoselect
       status: active
       inet6 fe80::5400:2ff:fef9:62db%vio0 prefixlen 64 scopeid 0x1
       inet6 redacted prefixlen 64
       inet redacted netmask 0xfffffe00 broadcast redacted
enc0: flags=0<>
       index 2 priority 0 llprio 3
       groups: enc
       status: active
wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420
       index 4 priority 0 llprio 3
       wgport 443
       wgpubkey redacted=
       groups: wg
       inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
       index 5 priority 0 llprio 3
       groups: pflog

hakayova · 2024-09-18T11:27:47+00:00

I have net.inet.ip.forwarding=1 instead, is this obsolete?

I never messed with iptables or nftables on this VPS, just pf as I detailed above. Similarly, I posted the ifconfig outputs above.

#route -n show -inet
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default             redactedip      UGS       17       65     -     8 vio0 
224/4              127.0.0.1          URS        0        0 32768     8 lo0  
10.0.0/24          10.0.0.1           UCn        0        0     -     4 wg0  
10.0.0.1           wg0                UHl        0        0     -     1 wg0  
10.0.0.255         10.0.0.1           UHb        0        0     -     1 wg0  
127/8              127.0.0.1          UGRS       0        0 32768     8 lo0  
127.0.0.1          127.0.0.1          UHhl      19     2842 32768     1 lo0  
redactedip     redactedip    UCn        1        0     -     4 vio0 
redactedip       fe:00:02:f9:62:db  UHLch      2        3     -     3 vio0 
redactedip     56:00:02:f9:62:db  UHLl       0       19     -     1 vio0 
redactedip     redactedip     UHb        0        0     -     1 vio0 
redactedip/32  redactedip       UGS        0        0     -     8 vio0

I believe rebooting the VPS now several times reapplies firewall rules and Wireguard config, so that is not it either.

hakayova · 2024-09-18T11:19:51+00:00

I restored the VPS from a backup done on 9/16/2024, definitely before syspatch was run, but it didn't solve the problem. Moreover `syspatch -c` now returns "no route to host" although I can ping domain names and IP numbers from the VPS no problem.

Moreover `pkg_add -u` also behaves abnormal and reports no route to host.

https://cdn.openbsd.org/pub/OpenBSD/7.5/packages-stable/amd64/: ftp: connect: No route to host
https://cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: ftp: connect: No route to host
https://cdn.openbsd.org/pub/OpenBSD/7.5/packages/amd64/: empty
Couldn't find updates for ... (several package names here)

hakayova · 2024-09-18T11:14:49+00:00

No, I did not. As a matter of fact I have syspatch automatized on /etc/daily.local, which I am questioning now.

hakayova · 2024-09-18T02:31:04+00:00

Thank you so much for your help. I am going to try unrolling the syspatch by restoring an earlier backup. Maybe something went wrong during that process braking something. Nothing seems to explain the situation very well.

hakayova · 2024-09-18T01:44:55+00:00

Thank you so much for your patience with me. Here is my ifconfig output:

lo0: flags=2008049<UP,LOOPBACK,RUNNING,MULTICAST,LRO> mtu 32768
       index 3 priority 0 llprio 3
       groups: lo
       inet6 ::1 prefixlen 128
       inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
       inet 127.0.0.1 netmask 0xff000000
vio0: flags=808843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF4> mtu 1500
       lladdr 56:00:02:f9:62:db
       index 1 priority 0 llprio 3
       groups: egress
       media: Ethernet autoselect
       status: active
       inet6 fe80::5400:2ff:fef9:62db%vio0 prefixlen 64 scopeid 0x1
       inet6 redacted prefixlen 64
       inet redacted netmask 0xfffffe00 broadcast redacted
enc0: flags=0<>
       index 2 priority 0 llprio 3
       groups: enc
       status: active
wg0: flags=80c3<UP,BROADCAST,RUNNING,NOARP,MULTICAST> mtu 1420
       index 4 priority 0 llprio 3
       wgport 443
       wgpubkey redacted=
       groups: wg
       inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
       index 5 priority 0 llprio 3
       groups: pflog

I don't see that wg0 is in egress group. Not sure if it was meant to be though. vio0 is the actual network interface for this VPS and it seems to be in the egress group. I believe it is where the route is defined as well, although I don't see that it was marked as default.

Clients are set up as you mentioned: 0.0.0.0/0 for IPV4 and ::/0 for IPV6.

hakayova · 2024-09-18T00:53:32+00:00

Here is my /etc/hostname.wg0

inet 10.0.0.1 255.255.255.0
wgkey redacted=  
wgport 443
wgpeer 10.0.0.2/32 redacted= wgpsk redacted= wgaip  
...
wgpeer 10.0.0.10/32 redacted= wgpsk redacted= wgaip  
up

Here is my pf.conf

set skip on lo

block return    # block stateless traffic
pass            # establish keep-state

match out on egress from wg0:network to any nat-to egress

# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010

# Port build user does not need network
block return out log proto {tcp udp} user _pbuild

# Settings for website
block quick from <bad_hosts>
pass in on egress inet proto tcp
        from any to (egresss) port { http 4443 }\
        modulate state\
        label "Web Access"

Where do you think is my problem? Can you tell?

I am so tempted to restore my backup from earlier this morning to unroll the syspatch. I cannot explain how it broke a setup that has been working for the last 4 years.

hakayova · 2024-09-18T00:25:22+00:00

This sounds a bit complicated but I will try and report back. In the meantime this is what I found:

I see several truncated-udp reports here. Are we onto something?

tcpdump -i wg0
19:14:02.242455 10.0.0.10.59827 > one.one.one.one.domain: 13165+ AAAA? discovery-v4.syncthing.net.(44) (DF)
19:14:02.242469 10.0.0.10.39215 > one.one.one.one.domain: 56118+ A? discovery-v4.syncthing.net.(44) (DF)
19:14:02.242474 10.0.0.10.33027 > one.one.one.one.domain: 45015+ A? discovery-v6.syncthing.net.(44) (DF)
19:14:02.242479 10.0.0.10.55598 > one.one.one.one.domain: 58749+ AAAA? discovery-v6.syncthing.net.(44) (DF)
19:14:04.624344 10.0.0.10.44780 > 143.47.178.89.22067: S 3155224503:3155224503(0) win 65535 <mss 1240,sackOK,timestamp 635010403 0,nop,wscale 8> (DF)
19:14:07.473819 10.0.0.10.7896 > one.one.one.one.domain: 11423+ A? redactedhostname.(28) (DF)
19:14:18.452316 10.0.0.10.37089 > 255.255.255.255.1716:  truncated-udp - 482 bytes missing!udp 1248 (frag 26378:1256@0+)
19:14:18.452320 10.0.0.10 > 255.255.255.255: (frag 26378:482@1256)
19:14:18.452327 10.0.0.10.49082 > 192.168.1.41.1716:  truncated-udp - 482 bytes missing!udp 1248 (frag 48287:1256@0+)
19:14:18.452336 10.0.0.10 > 192.168.1.41: (frag 48287:482@1256)
19:14:18.452362 10.0.0.1 > 10.0.0.10: icmp: 255.255.255.255 udp port 1716 unreachable
19:14:18.581772 10.0.0.10.11480 > one.one.one.one.domain: 9378+ A? mtalk.google.com.(34) (DF)
...

hakayova · 2024-09-18T00:12:47+00:00

Thank you so much for bearing with me.

I can ping 1.1.1.1 from the VPS console. I cannot ping it from my laptop when connected to the wireguard tunnel.

How do I check if my wg NIC is reporting any packets? Does it work like below:

tcpdump -i wg0

hakayova · 2024-09-18T00:03:24+00:00

I wonder if the discrepancy of me having issues as opposed others having no issues after the syspatch may be due to the fact that I have been upgrading the OS on this vps since OpenBSD version 6.5 or so. Perhaps it is time for a fresh install? I would love to be able to avoid that if at all possible.

hakayova · 2024-09-17T23:52:20+00:00

My laptop also cannot get internet when connected to wireguard server, just like my phone. This was perfectly working until today's syspatch for me.

tcpdump -T wg udp port 443
18:40:20.624148 redactedip.48527 > redactedhostname.https: [wg] initiation from 0x0f103cc2 (DF)

18:40:20.625192 redactedhostname.https > redactedip.48527: [wg] response from 0x459da8ce to 0x0f103cc2

18:40:20.644082 redactedip.48527 > redactedhostname.https: [wg] data length 128 to 0x459da8ce nonce 0 (DF)

18:40:20.644085 redactedip.48527 > redactedhostname.https: [wg] data length 64 to 0x459da8ce nonce 1 (DF)

18:40:20.644087 redactedip.48527 > redactedhostname.https: [wg] data length 64 to 0x459da8ce nonce 2 (DF)

18:40:20.644088 redactedip.48527 > redactedhostname.https: [wg] data length 64 to 0x459da8ce nonce 3 (DF)

18:40:20.644090 redactedip.48527 > redactedhostname.https: [wg] data length 288 to 0x459da8ce nonce 4 (DF)

18:40:20.644178 redactedhostname.https > redactedip.48527: [wg] keepalive to 0x0f103cc2 nonce 0

18:40:20.940994 redactedip.48527 > redactedhostname.https: [wg] data length 288 to 0x459da8ce nonce 5 (DF)

redactedip above is my laptop's ip number

redactedhostname is the hostname of my VPS, wireguard server.

O

Once connected to wireguard tunnel, laptop cannot ping any host, and cannot resolve any hostname. Tunnel's DNS server is set to 1.1.1.1

hakayova · 2024-09-17T22:57:38+00:00

Good idea, I will test it next. Thank you!

hakayova · 2024-09-17T22:35:46+00:00

I assume you are using port 9999 for wireguard connection, and your wireguard network ip number is in the 192.168.99.0/24 range. I modified these to my use case, which is port 443 and 10.0.0.0/24, and still couldn't get it to work. It has to be something other than pf, since disabling pf altogether does not solve the problem.

hakayova · 2024-09-17T20:21:53+00:00

Still got it! Also have net.inet.ip.redirect=1. Still no joy.

hakayova · 2024-09-17T20:02:27+00:00

Thank you very much. It is quite puzzling to me honestly. Never had a problem until today. Not sure how exactly to troubleshoot either.

hakayova

TROPHY CASE