Why wireguard lies about being up?

[gcbwrt]

I have two openwrt modems that sit behind the ISP modems. They have a wg tunnel.

more than a month ago, one of the ISP modems decided to not do any port forwards anymore. At all.

Yet, when I log into the other (behind the working ISP modem) openwrt modem:

~# wg show
interface: wg1
  public key: asdf=
  private key: (hidden)
  listening port: 1234

peer: asdf=
  preshared key: (hidden)
  endpoint: 123.123.123.123:1234
  allowed ips: 10.55.130.0/24, 10.55.131.0/24, 10.99.99.2/32
  latest handshake: 3 days, 19 hours, 58 minutes, 12 seconds ago
  transfer: 8.73 MiB received, 5.59 MiB sent

~# ip a
12: wg1: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN qlen 1000
    link/[65534] 
    inet 10.99.99.1/24 brd 10.99.99.255 scope global wg1
       valid_lft forever preferred_lft forever

Why it shows it is sending and receiving data, and that the interface is up, if I known for a fact nothing is listening on that peer port?

[Dante]

This seems to be working as expected. wg1 is up because a Wireguard instance is using it. And the peer is showing latest handshake received 3 days ago (so looks like there's no connection between peers).

Wireguard is not a chatty protocol and only sends data when needed: actual data, initial handshakes and rekeys, and optional keepalive messages.

If you're curious you can get more insights from the whitepaper.

[gcbwrt]

the 3 days is the uptime. it claims to have opened up a tunnel on startup, when that peer is gone for over a month.

The interface up makes sense... But what data is it receiving makes no sense?

[Dante]

@gcbwrt

the 3 days is the uptime

Unless the clock on the device is off, according to the output of wg show, since the device has booted, latest handshake: 3 days, 19 hours, 58 minutes, 12 seconds ago is the last time the peers "shook hands". So before the last handshake (plus some Rekey-Timeout), they exchanged transfer: 8.73 MiB received, 5.59 MiB sent of data.

@gcbwrt

But what data is it receiving makes no sense?

You need to examine your setup to answer that question.

[gcbwrt]

hum... maybe the peer is connecting? i think i set them up both ways. and now since it is not "listening" only it can resume the tunnel?

[mk24]

A Wireguard interface is always "up" in the sense that it is ready to encrypt a packet and send it UDP toward the peer. That does not mean the tunnel is working.

If there have been attempts to send a packet, or persistent_keepalive is configued, the latest handshake should be less than 2 minutes ago. There has been no contact for 3 days.

[gcbwrt]

I see.

Would the latest handshake update if it is tried but fail?

If not, I think the remote peer is initiating the connection, then some other services used the tunnel when saw it available. And unless the peer have something connecting to this host the tunnel will stay "down" as this host cannot reach the peer.

I will try to ping from the remote peer into this one when i can get a hold of someone on that site to test this idea.

[Dante]

@gcbwrt

Would the latest handshake update if it is tried but fail?

No, it's the latest successful handshake.