On 2022-03-25, Francisco Gaitan <openbsd-m...@retrocircuitos.com> wrote: > On Fri, Mar 25, 2022 at 07:56:16AM -0400, Josh Grosse wrote: >> On Fri, Mar 25, 2022 at 11:41:08AM +0100, Francisco Gaitan wrote: >> > I have setup a WireGuard VPN so I run two instances of unwind, one for >> > rdomain 0 (unwind) and another for rdomain 1 (unwind1) this way: >> > lrwxr-xr-x 1 root wheel 16 Mar 23 13:44 unwind1 -> /etc/rc.d/unwind >> > >> > $ cat /etc/rc.conf.local >> > unwind1_flags=-vvv -f /etc/unwind1.conf >> > unwind1_rtable=1 >> >> Here is where we differ. Both of my unwind(8) instances use the same >> configuration file, but they use different sockets: >> >> unwind1_flags=-s /dev/unwind1.sock >> unwind1_rtable=1 >> unwind_flags= >> > > Thank you. I updated my /etc/rc.conf.local (and rebooted): > > unwind1_flags=-s /var/run/unwind1.sock -f /etc/unwind1.conf > unwind1_rtable=1 > unwind_flags= > > But it still fails: > > iron$ route -T1 exec dig +short @127.0.0.1 iron.home.arpa > 192.168.10.10 > iron$ route -T1 exec dig +short @127.0.0.1 iron.home.arpa > > After rcctl restart unwind1: > > iron$ route -T1 exec dig +short @127.0.0.1 iron.home.arpa > 192.168.10.10
But now you have a working control socket for both, so you can provide "unwindctl status" and "unwindctl -s /var/run/unwind1.sock status", and show the configuration files, which would give a better idea of what might be wrong. (I found unwind more trouble than it's worth with rdomains though, I killed resolvd and hardcoded a public resolver in resolv.conf instead..) -- Please keep replies on the mailing list.
