Wireguard Interface Packet Loss

Installing and Using OpenWrt Network and Wireless Configuration
1

Is there an expectation of a large amount of packet loss on Wireguard interfaces? Only on the RX end, TX seems fine.

 RX: bytes  packets  errors  dropped overrun mcast
    955301964  832333   0       598920  0       0
2

Is the other side sending too fast for your device to decrypt maybe?

1 Like
3

Doubtful. I mean Wireguard is supposed to perform up to half a gigabit on the RPi4, right?

4

Are you sending traffic thru the tunnel to the OpenWrt - for an un-allowed IP (e.g. correct keys; but sending multicast or trying to use Internet on a peer not set for such)?

1 Like
5

I'd presume not, as firewall/network should be configured correctly. Although I'm not entirely certain what you mean, so you'll have to explain farther. Also, something new: Upon disabling rx checksum offloading on the LAN interface (eth1, USB-Ethernet adapter, Realtek 8153), I started getting dropped bytes on the TX side of the wireguard client interface.

6

My remark has [almost] nothing to do with the firewall (or, it may be why you see this dropped traffic).

  • Please show your Wireguard config (with the Allowed_IP assignments I mentioned)
  • If you're the server, verify you opened the Wireguard port on OpenWrt
  • Please note what firewall zone you assigned the Wireguard Interface to

I'm asking what IPs did you assign to both ends of this tunnel; and trying to verify they are correct; as WIreguard won't pass traffic on an improperly configured tunnel.

You have yet to provide information to assist you.

2 Likes
7

Client-Only Configuration, Mullvad is the provider.

config interface 'wgclient'
        option proto 'wireguard'
        option private_key 'xx'
        option mtu '1420'
        option delegate '0'
        list addresses '10.65.58.106/32'

config wireguard_wgclient
        option public_key 'KQ5v1ucsIKy/DCkalrkdsPl3BIx88QBA+WZ0xNORBB0='
        option persistent_keepalive '25'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option endpoint_host '217.138.204.146'
        list allowed_ips '0.0.0.0/0'

Assigned to its own firewall zone

config zone
        option network 'wgclient'
        option name 'wgclient'
        option output 'ACCEPT'
        option masq '1'
        option input 'REJECT'
        option family 'ipv4'
        option forward 'REJECT'

config forwarding
        option dest 'wgclient'
        option src 'lan'

I've got MSS manually fixed in the firewall.user

8

Should not be needed.

Change to:

0.0.0.0/1 and 128.0.0.0/1

You probably want to control the firewall for IPv6, as well as IPv4.

Unless you have different rules on LAN, it may be easier to assign it there.

Should be un-needed.

To be clear...are you actually having issues with traffic?

You never actually note if your tunnel is failing to pass allowed traffic.

"If it ain't broke, don't fix it!" :wink:

1 Like
9

Thanks. I believe that delegate '0' was automatically included, I'll remove them both and retest. Is there a reasoning as to why the 0.0.0.0/1 and 128.0.0.0/1 would be better? Do they allow for passthrough of LAN-only traffic as compared to 0.0.0.0/0? I created a custom image for this build compiled without all the IPv6 packages and the CONFIG_IPV6=n and have also disabled IPv6 elsewhere (sysctl, hosts, etc.) so it shouldn't be a problem to do it like that - I figured that it would likely be beneficial to not have it looking for non-existent traffic. Interesting, I've never heard of the wireguard client interface being bonded to the LAN zone directly (only wireguard servers), but it hypothetically should be more performant since it's less parsing to do overall, right? Would it be an impediment (even just theoretically) to VPR to do this? My main considerations right now for doing this are purely for optimisation/optimality's sake; I know that it's not ideal practise considering the seemingly arcane nature of networking but I've got my mind set on it. Plus, I figure that once I've got this sorted out I shouldn't have to ever deal with it again. Because it does passthrough traffic, handshake is fine, I'm just slightly wary about there being that much dropped traffic. Even applying the fq_codel qdisc didn't seem to reduce the dropping - but I'm not sure how applicable that is on a purely virtual interface/tunnel. Thanks again for your help.

10

CORRECTION - WAN!

Because 0.0.0.0/0 is the default route on your WAN, you break it in some cases.

Lastly, you referring to a lot of compile options and things...I'm only referring to vanilla OpenWrt...thank you for finally mentioning a custom build.

1 Like
11

Ah, yes, WAN does make more sense. That is true, I'll certainly do an extensive test-run of 0.0.0.0/1 and 128.0.0.0/1 going forward. I mean, for the most part it seems a bit irrelevant. However, with that being considered since I'm running a 'Snapshot' build rather than a mainstream one I'll maybe move back to my RPi 3B+ quickly and test it with these considerations on the 19.07.2 release.

12

If you make a route for 0.0.0.0/0 and your WAN is the same...it might be. There's many threads on this problem.

Also, setting this manually or outside of the WG config (in the case of multiple tunnels) likely has a different effect then you'd see with a single tunnel.

13

I get the same if 'Software flow offloading' is enabled.

If I disable SFO, dropped RX packets are drastically reduced.

1 Like
14

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.