search

angt / glorytun

Multipath UDP tunnel
BSD 2-Clause "Simplified" License
675 stars 103 forks source link

speedtest / nperf via browser failed #64

Closed cyayon closed 4 years ago

cyayon commented 4 years ago

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 4 years ago

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

cyayon commented 4 years ago

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 4 years ago

but curl in glorytun on other destination works ?

cyayon commented 4 years ago

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 4 years ago

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 4 years ago

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.