Thanks Trendy, sorry for slow reply I have been travelling so I am now overseas hence the high pings!
This looks OK from my perspective:
root@GL-AR750S:~# ping -I wg0 -M do -s 1500 192.168.111.1
PING 192.168.111.1 (192.168.111.1) from 192.168.113.4 wg0: 1500(1528) bytes of data.
ping: local error: Message too long, mtu=1300
ping: local error: Message too long, mtu=1300
ping: local error: Message too long, mtu=1300
ping: local error: Message too long, mtu=1300
^C
--- 192.168.111.1 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3145ms
root@GL-AR750S:~# ping -I wg0 -s 1500 192.168.111.1
PING 192.168.111.1 (192.168.111.1) from 192.168.113.4 wg0: 1500(1528) bytes of data.
1508 bytes from 192.168.111.1: icmp_req=1 ttl=64 time=201 ms
1508 bytes from 192.168.111.1: icmp_req=2 ttl=64 time=179 ms
1508 bytes from 192.168.111.1: icmp_req=3 ttl=64 time=181 ms
1508 bytes from 192.168.111.1: icmp_req=4 ttl=64 time=183 ms
1508 bytes from 192.168.111.1: icmp_req=5 ttl=64 time=180 ms
^C
--- 192.168.111.1 ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 5006ms
rtt min/avg/max/mdev = 179.309/185.211/201.423/8.242 ms
And I see the following in tcpdump when I remove the do not fragment flag which again looks good to me:
root@GL-AR750S:~# tcpdump -i wg0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
20:00:22.532179 IP 192.168.113.4 > 192.168.111.1: ICMP echo request, id 21617, seq 1, length 1280
20:00:22.532231 IP 192.168.113.4 > 192.168.111.1: icmp
20:00:22.733378 IP 192.168.111.1 > 192.168.113.4: ICMP echo reply, id 21617, seq 1, length 1280
20:00:22.733446 IP 192.168.111.1 > 192.168.113.4: icmp
20:00:23.533173 IP 192.168.113.4 > 192.168.111.1: ICMP echo request, id 21617, seq 2, length 1280
20:00:23.533221 IP 192.168.113.4 > 192.168.111.1: icmp
20:00:23.712301 IP 192.168.111.1 > 192.168.113.4: ICMP echo reply, id 21617, seq 2, length 1280
20:00:23.712352 IP 192.168.111.1 > 192.168.113.4: icmp
20:00:24.534177 IP 192.168.113.4 > 192.168.111.1: ICMP echo request, id 21617, seq 3, length 1280
20:00:24.534225 IP 192.168.113.4 > 192.168.111.1: icmp
20:00:24.713850 IP 192.168.111.1 > 192.168.113.4: ICMP echo reply, id 21617, seq 3, length 1280
20:00:24.715318 IP 192.168.111.1 > 192.168.113.4: icmp
20:00:25.535820 IP 192.168.113.4 > 192.168.111.1: ICMP echo request, id 21617, seq 4, length 1280
20:00:25.535870 IP 192.168.113.4 > 192.168.111.1: icmp
20:00:25.719407 IP 192.168.111.1 > 192.168.113.4: ICMP echo reply, id 21617, seq 4, length 1280
20:00:25.719476 IP 192.168.111.1 > 192.168.113.4: icmp
20:00:26.536930 IP 192.168.113.4 > 192.168.111.1: ICMP echo request, id 21617, seq 5, length 1280
20:00:26.536980 IP 192.168.113.4 > 192.168.111.1: icmp
20:00:26.715388 IP 192.168.111.1 > 192.168.113.4: ICMP echo reply, id 21617, seq 5, length 1280
20:00:26.717067 IP 192.168.111.1 > 192.168.113.4: icmp
20:00:27.538382 IP 192.168.113.4 > 192.168.111.1: ICMP echo request, id 21617, seq 6, length 1280
20:00:27.538432 IP 192.168.113.4 > 192.168.111.1: icmp
20:00:27.768559 IP 192.168.111.1 > 192.168.113.4: ICMP echo reply, id 21617, seq 6, length 1280
20:00:27.768636 IP 192.168.111.1 > 192.168.113.4: icmp
^C
24 packets captured
24 packets received by filter
0 packets dropped by kernel
I'll try to get wireshark traces showing exactly what happens on both sides of the tunnel and post it here.