wg show segmentation fault

spltngheadache

I have 4 wireguard tunnels configured. Using "# wg show" in an ssh shell prints results for wg0 and wg1, but then indicates a Segmentation fault (core dumped).

I assume this isn't expected. Are there a location for logs or something I can submit to netgate?

jimp

The only way I've seen that happen so far is from a broken configuration -- namely, if you have attempted to set two peers on the same tunnel to use Allowed IPs of 0.0.0.0/0 and/or ::/0, or equivalent (one has 0.0.0.0/0, the other is empty).

Since you can't have two peers both be the default, the wg binary flips out. We added input validation to prevent the broken configuration in the next release.

spltngheadache

@jimp thanks for the reply. I’ve rechecked my 4 tunnels. I only have one that is set with a 0.0.0.0/0 and ::/0. the others are specific subnets. anything else this might be?

jimp

Not that I've seen yet. Compare the contents of /etc/wg/wg<number>.conf and what you do see in the wg output and see what isn't showing.

spltngheadache

Ok so wg show wg0 through wg show wg3 works fine. Its just wg show that throws a segmentation fault:

[2.5.0-RELEASE][root@raptor.[domain]]/var/unbound: wg show
interface: wg0
  public key: [key]
  private key: (hidden)
  listening port: 3183

peer: [key]
  endpoint: [ip]:3123
  allowed ips: ::/0, 0.0.0.0/0

interface: wg1
  public key: [key]
  private key: (hidden)
  listening port: 51822

peer: [key]
  endpoint: [endpoint]:51820
  allowed ips: fd86:ea04:1717::2/128, 192.168.31.0/24, 172.27.17.2/32, 192.168.17.0/24, 192.168.69.0/24

Segmentation fault (core dumped)
[2.5.0-RELEASE][root@raptor.[domain]]/var/unbound:

[2.5.0-RELEASE][root@raptor.[domain]]/var/unbound: wg show wg0
interface: wg0
  public key: [key]
  private key: (hidden)
  listening port: 3183

peer: [key]
  endpoint: [endpoint]:3123
  allowed ips: ::/0, 0.0.0.0/0

[2.5.0-RELEASE][root@raptor.[domain]]/var/unbound: wg show wg1
interface: wg1
  public key: [key]
  private key: (hidden)
  listening port: 51822

peer: [key]
  endpoint: [endpoint]:51820
  allowed ips: fd86:ea04:1717::2/128, 192.168.31.0/24, 172.27.17.2/32, 192.168.17.0/24, 192.168.69.0/24

[2.5.0-RELEASE][root@raptor.[domain]]/var/unbound: wg show wg2
interface: wg2
  public key: [key]
  private key: (hidden)
  listening port: 51820

peer: [key]
  allowed ips: fd86:ea04:1115::2/128, 172.27.80.2/32

peer: [key]
  allowed ips: fd86:ea04:1115::9/128, 172.27.80.9/32

peer: [key]
  allowed ips: fd86:ea04:1115::8/128, 172.27.80.8/32

peer: [key]
  allowed ips: fd86:ea04:1115::7/128, 172.27.80.7/32

peer: [key]
  allowed ips: fd86:ea04:1115::6/128, 172.27.80.6/32

peer: [key]
  allowed ips: fd86:ea04:1115::5/128, 172.27.80.5/32

peer: [key]
  allowed ips: fd86:ea04:1115::3/128, 172.27.80.3/32

peer: [key]
  allowed ips: fd86:ea04:1115::10/128, 172.27.80.10/32

[2.5.0-RELEASE][root@raptor.[domain]]/var/unbound: wg show wg3
interface: wg3
  public key: [key]
  private key: (hidden)
  listening port: 443

peer: [key]
  allowed ips: fd86:ea04:1116::10/128, 172.27.81.10/32

peer: [key]
  allowed ips: fd86:ea04:1116::6/128, 172.27.81.6/32

peer: [key]
  allowed ips: fd86:ea04:1116::3/128, 172.27.81.3/32

peer: [key]
  allowed ips: fd86:ea04:1116::2/128, 172.27.81.2/32

jimp

Nothing in that really stands out, unfortunately.

Is there anything in the wgX.conf files that isn't displayed in the output of the other wg commands?

spltngheadache

@jimp it looks exactly the same to me, minus the redaction of the keys. I thought maybe reusing a public key for a peer would do it but I deleted it and it did the same thing. The reason for the duplicate public key is just ease of key management. There's two instances running on two different ports but the peer list is the same using a different subnet. I don't connect to both at the same time, its just a port fallback.

I noticed wg.core in /root but I think that may contain my private keys?

jimp

Resuing a public key for a peer could be a problem but mostly if it's the same tunnel. But I'm not 100% certain if that is a problem in the other cases, but it's still not something I'd recommend.

If you want to run one instance on multiple ports you can port forward from one port to the other,

spltngheadache

@jimp ah ok fair enough. Thanks for the replies and looking at this. There doesn't seem to be any functional issue with the tunnels or wireguard. Traffic is all passing as expected, I've run leak tests, and watched different interfaces with tcpdump. All is what I expect - the seg fault just concerned me. I'll keep an eye for the next release and see if there's any change there. I may also try rebooting the system at the next opportunity.

spltngheadache

@jimp said in wg show segmentation fault:

If you want to run one instance on multiple ports you can port forward from one port to the other,

this works perfectly. thanks again!