angt/glorytun

speedtest / nperf via browser failed

cyayon opened this issue · 6 comments

cyayon commented

Hi,

When using firefox/chromium-like browser, https://www.speedtest.net (or nperf) failed through
glorytun tunnel (failed to connect).
With Curl (instead of firefox/chromium), no issue, i manage to download through glorytun tunnel.

When i put a proxy (squid with tcp_outgoing_address option) in front of tunnel, i have no issue with any browser.

Do you have an idea please ?

angt commented

Hello,
Maybe the IP of your server is blacklisted by speedtest/nperf ?
This is, sadly, a common practice..

cyayon commented

No, i don't think so because :

  1. when using curl on the same client to same destination (speedtest/nperf), i have no issue
  2. when using curl on the glorytun server to speedtest/nperf, no issue too
angt commented

but curl in glorytun on other destination works ?

cyayon commented

Curl work to everywhere
Firefox/Chromium direct (without proxy) failed to some destination (speedtest/nperf)
Firefox/Chromium through proxy (squid) work to everywhere

cyayon commented

is there some sysctl to tune ?

I missed to say that i am using glorytun on a firewall/router which NAT. Is there something to configure for doing it properly ?
I think the issue is here, because from the router/firewall itself it seems to work properly. But on LAN client there are random issues.

here are mine sysctl on my firewall/router (archlinux) :

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
#net.core.default_qdisc = fq_codel
#net.ipv4.tcp_congestion_control = cubic

net.ipv4.tcp_reordering = 32
#net.netfilter.nf_conntrack_acct = 1

net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.core.rmem_default = 33554432
net.core.wmem_default = 33554432
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 87380 33554432
net.ipv4.tcp_mem = 4096 87380 33554432
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 32768
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_rfc1337 = 1
net.ipv4.ip_no_pmtu_disc = 1
net.ipv4.route.gc_timeout = 30

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
#net.ipv4.conf.all.log_martians = 1

thanks

angt commented

Hi,
I've never seen this kind of issue..
If I were you, I would start digging with tcpdump, checking both sides to see were packets are lost.