im happy to take updates to the manpage. i'll even handle the mdoc markup if you only have plain text to give us.
just keep in mind that a network driver (like wg) and ifconfig are separate things. you can technically configure/operate a driver with other tools, or programming against it directly, which is why a lot of these man pages hold back from talking about operating them ifconfig until you get to the examples section. > On 30 Apr 2026, at 08:35, [email protected] wrote: > > Hi Sha'ul, > > I actually agree with you. The wireguard man page isn't super helpful for > people > trying to setup wireguard in an a-typical setup. (or "learn") > > 2 things to note: > 1) You have to pay attention the "#" prior to the command ifconfig line just > before > the EXAMPLES section. The thing that will catch many people out is that they > will run the command as their "normal" user, which actually works but doesn't > show you the full output if you had used "doas" in front, or su to root. > Can be useful for troubleshooting. the kernel filters the information it returns from the SIOCGWG based on whether the user is root or not, which in turn affects what ifconfig etc are able to show. > > 2) The whole man page doesn't touch on routing which most people will need to > get things working. s/most/all/. this is probably the biggest semantic difference between wireguard in the base openbsd install compared to the other implementations. in my experience everything else implies routing config from allowedips, while you have to do that bit yourself in openbsd. the exception is if you configure an ip with a prefix (eg, a /24) on a wireguard interface, cos the interface address config code injects routes for that subnet for you. however, if you configure a /32 or you configure allowedips outside that local prefix, you need manual route config. the frustration is that this expectation of implicit allowedips routing config comes from outside the openbsd base system. we dont say you need to configure routes in the man pages for other network drivers. > > Lots of the examples on the internet for OpenBSD (given its small user base) > are > either missing, incorrect or outdated as things change in versions. > > Anyway, I am happy to help you out as much as I can. > > You do only need the hostname.wg0 file in a normal scenario. > And presuming you are connecting to a VPN service, then these are the elements > in the config file you'll need to change: > > --- hostname.wg0 --- > wgkey <the private key you generated> > wgport 51820 > inet 10.10.10.10/32 <- change this to > the internal address > your > provider or remote gave you > wgpeer <VPN service or remote public key> = wgendpoint > 111.111.111.111 51820 wgaip > 0.0.0.0/0 wgpka 20 > (change 111.111.111.111 to the public IP address your provider gave you) > #DNS = 99.99.99.99 <- optional DNS line if you want to use > their DNS > up > > !route add -priority 2 <put the 111.111.111.111 changed address here> > -gateway 192.168.1.1 > !route add -priority 7 -inet default -iface 10.10.10.10 <- change the > 10.10.10.10 address here > --- > > That should get you up and running. > So, private key in wgkey line. > Internal address of VPN service in the inet line, and bottom routing line. > External address of VPN service in the wgpeer line, and the first route line. > Assumes your gateway is 192.168.1.1 so change that to you home gateway > address. > > Sincerely hope that helps, and you get it working. Once you do, its super > elegant being > in one file. Its just a bit tricky getting your first config going. > > Oh, if you get errors during boot, using dmesg -s (this shows console > message buffer > during boot so you can see what errors you get). > Or doas sh /etc/netstart of course to see it "live" when trying a config > out. > > Good luck! > > > On 29.04.2026 18:22, Sha'ul wrote: >> I have been trying to go through WireGuard manual to set it up and >> failed. I checked with AI which replied "To answer your question: the >> manual is accurate but dense. It assumes you already understand the >> "OpenBSD Way." For example, it tells you wgkey sets the key and wgpubkey >> shows it, but it doesn't explicitly warn you that a standard user >> (without doas) might see a truncated output, or that the driver needs a >> specific "trigger" (like netstart or an IP assignment) to initialize the >> cryptographic state." Is that a false perspective? >
