Raspberry Pi 4 expected Wireguard Speed

Set both sides to have the same MTU on the WG interface usually that is 1420 (1412).

Okay so I will set both sides to 1412. TY EGC.

1 Like

Why should that not even be considered after everything is sorted?

eth0, by default, is assigned to the lan via br-lan. There is rarely a reason to assign it differently.

The built in ethernet has a chip before it that handles scheduling then goes directly to the CPU.

As opposed to software handeling then the USB controller then the CPU.

But that is of little relevance -- one interface will always need to deal with the USB controller.

Regarding your above recommendation to avoid using the USB ethernet adapter, I have a RP3B just sitting around. Would the setup be the same as your mentioned?

@llFawkes17ll - this is off topic for the current thread, but the point is not about avoiding a USB Ethernet adapter, it's just an argument to state that when one is in use, there is likely little to no difference between using it as a lan vs a wan for the Pi4 specifically.

So get this, I spoke with the ISP provider and they said that the ISP router is getting the appropriate speed. However, since the wifi name and password was changed in the router, it is creating a non glitch that is slowing down the connection to devices. I cannot believe that change the wifi name and password would somehow slow down the speed but it seems like BS to me. I could be wrong as networking is not my field of expertise. Please tell me if that makes sense. Anyway they couldn't tell why a ethernet connected device is having the same issue.

Can you disable the radios on the isp router?

Their rhetoric makes no sense to me but disabling the radios should shut them up.

Me too, and probably everybody here. However for the sake of troubleshooting and for ensuring that they don't have any excuses, ask them if resetting the ISP router device to defaults will put it into the state that they prefer/guarantee... then if the results of the tests don't live up to the service tier bandwidth promises, they will have no reason to deny a service call.

Don't forget that the reset of the device will clear your port-forward. So be sure that at least one of the people in the NJ location can add that back after the reset.

Ideally, the configuration of the ISP device can be backed up so that it can be easily restored when it (predictably) doesn't change the speed test results.

Also, you could actually create a tunnel from the Pi at the NJ location to your home -- this way you don't rely on a port forward to gain access to the network (the NJ location will connect to your home location, there by establishing a tunnel that doesn't require any open ports on the NJ side). From there, you can help with the process of administering/configuring the ISP router.

1 Like

I will be resetting the router tomorrow morning after they recommended just that.

Can you point me to the right direction of how to do this? I have never done this. Do you mean something like tailscale?

Not tailscale... just WG.

Create a new peer in the WG config on your own home OpenWrt Pi4. Then, create a new interface on the NJ Pi4 that is essentially a remote peer that will connect back to your own home (just like your phone does). This way, the NJ side will make the connection to your home, and then you can connect back through to their network.

So I would have two separate WG interfaces in the NJ Pi4? One for getting the IP address of of NJ and one to remote into it? How would I activate the tunnel from the home network if I am not pressent in NJ to active the remote peer? that is where I am getting lost.

So I would have the WG network I currently have in the NJ Pi4 and just add another WG interface for the tunnel?

This is an excerpt from your WG config on your home router:

Add another peer to it like this:

config wireguard_Wireguard
        option description 'NJ OpenWrt Pi '
        option public_key '<Pub_Key_of_NJ_Side>'
        option private_key ‘<Priv_Key_of_NJ_Side>'
        option preshared_key '<PSK>'
        list allowed_ips '192.168.87.4/32'
        list allowed_ips '192.168.1.0/24'
        option route_allowed_ips '1'

Then, create a new WG interface on the NJ side:

config interface 'WGConnectHome'
        option proto 'wireguard'
        option private_key '<Priv_Key_of_NJ_Side>'
        list addresses '192.168.87.4/24'

config wireguard_WGConnectHome
        option description 'Connect to home'
        option public_key '<Pub_Key_of_Home_Side>'
        option preshared_key '<PSK>'
        option route_allowed_ips '1'
        option endpoint_host '<IP.or.domainname.of.home.router>'
        option endpoint_port '51810'
        list allowed_ips '192.168.87.0/24'
        list allowed_ips '192.168.86.0/24'

Add network WGConnectHome to the lan firewall zone on the NJ Pi.

Then restart both sides and you should have a tunnel from NJ > your home, and you should be able to route from your home lan to the lan in NJ.

Will try it in the morning. However, I am still confused as to how I would start the connection for the tunnel on the NJ Pi4. Would it alway be on?

Yes... it'll always be on. It will auto-start (you may need to start it the first time, though) upon boot.

got it. I will try to follow the instruction on the CLI.

Just so I get this straight, there will be two separate WG intefaces in the NJ Pi4, right? 1 the current WG interface and 2. the WG for the tunnel.

I have an RPi5 acting as a router on VLAN switch, running Debian12 + Docker for WireGuard (linuxserver .io container)
My ISP uses PPPoE (MTU is 1492).
Had lots of issues with WigreGuard MTU.
Used ping with no-fragment flag to find the correct MTU
MTU=1392 worked for me on an Arch Linux QEMU VM.
I notice that the Android WireGuard client has tun0 with MTU of 1280.
You can set the MTU to 1500 then use ping with no-fragment flag to find the correct MTU
.
EDIT: I get ~500Mbps on iperf3 - probably limited by only using eth0+vlans for all traffic.
top shows quite high wg-crypt-wg0 cpu usage - 25% i.e. 1 of 4 cores

.25 is across all cores in Linux.
.25 divided by 4= 0.015625 for the true system load.
4.0 would = 100% load.