Hi
I am having some packet loss at my openwrt router. I suppose it could be @ _gateway an Untangle firewall? Anyway it is obvious when watching videos. Not terrible but annoying. ISP is spectrum 60 down and 5 up. Far from the best but the only option here in rural area. They may be the problem. LOL
Modem <> openwrt <> Untangle <> Switch
Openwrt is doing openvpn to 185.238.231.125 .
This is mtr result from a computer on the network via Ethernet.
Openwrt is x86 64 "OpenWrt 22.03.4 r20123-38ccc47687 / LuCI openwrt-22.03 branch git-23.119.80898-65ef406".
Untangle is 16.6.2 (current) and slightly behind debian 11. Both are vm's on proxmox on latest updates as of this morning. Both are way over provisioned.
Reading above made me think and I installed mtr on the Untangle with about the same result. (without _gateway) So i think it is openwrt causing the issue? So what logs should I be looking at? Or maybe some settings?
Going to figure out how to upgrade to 22.03.5 and keep the vpn settings etc. Lots of post so I will pick one and try on a clone. Thanks proxmox for making that so easy.
If you're getting no packet loss from any later hops then OpenWRT isn't dropping packets while routing. A router dropping ping responses isn't unusual.
I ran mtr on openwrt all night with 0% loss. Then I moved the vpn to the untangle and the dropped now show on the untangle. So I am guessing it may be something with openvpn or the vpn provider. Will try another vpn server location. And upgrading to v22.03.5 .
Still wondering if there are any logs I could be looking at?
Yes, if packet loss increases at and stays elevated beyond a specific hop, that is an indication of that specific node dropping real packets (in addition of the ICMP probe packets mtr/traceroute use by default)... "transient" loss in mtr results on any hop but the last can usually be ignored, infrastructure nodes like ISP routers try to generate ICMP responses if they have CPU cycles left, if not they simply do not generate ICMP responses which mtr reports as packet loss.
So I am not dismissing your issue, but I think the intermediate loss is not your problem...
That, or even testing a different VPN provider seems like a decent way to diagnose the issue. If you suspect OpenVPN* you might want to give wireguard a try, which generally is considered to be less resource hungry than OpenVPN and some VPNproviders support it (it does have some caveats, e.g. it will use UDP packets and you might need to use an additional TCP tunnel if your ISP has issues with UDP).
*) There is no indication of OpenVPN doing anything unbecoming in the data you posted though.
P.S.: When posting mtr results, please consider to :
"sandwich" your text between two rows of backtick characters ` (which themselves will be invisible in the preview) looking something like this in the editor:
```
Your Pasted Text as preformatted text with fixed width font
1
1111 (note with fixed-width fonts the numbers are right-aligned)
```
but looking like this in the rendered forum:
Your Pasted Text as preformatted text with fixed width font
1
1111 (note with fixed-width fonts the numbers are right-aligned)
this results in easy to read mtr results simply from copy and pasting the console output of mtr: