2016-10-28 14:57 GMT+08:00 Jan Just Keijser <janj...@nikhef.nl>: > Hi, > > [snipped] > > without a routing table, it is very hard to tell what is happening. > As for your tests: > - I find it odd that you can actually ping the VPN server public IP address > via the tunnel i/f ; it's possible, just not "default" behavior > - what *is* normal is that you can ping the VPN server IP address via the > network i/f ; however, your VPN provider may have blocked this > - you should be able to ping the 10.211.1.1 address (no need to specify '-I > tun1') but your VPN provider may have blocked that as well. > - as Gert pointed out, this VPN is set up to use 'net30' mode, in which you > can *never* ping the P-t-P endpoint (10.211.1.10) > > A more useful test would be to ping an anycast address such as 8.8.8.8 or > 4.4.4.4 - do that via the tunnel vs outside the tunnel. It will only give > you a limited understanding of the VPN's performance,
I tried it as follows: $ ping -c 10 -I eth0 8.8.8.8 PING 8.8.8.8 (8.8.8.8) from 192.168.0.2 eth0: 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=128 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=124 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=124 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=124 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=127 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=53 time=133 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=53 time=122 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=53 time=125 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=53 time=131 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=53 time=123 ms --- 8.8.8.8 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 122.963/126.756/133.225/3.199 ms $ ping -c 10 -I tun104 8.8.8.8 PING 8.8.8.8 (8.8.8.8) from 10.211.1.49 tun104: 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=209 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=206 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=435 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=351 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=202 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=203 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=206 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=210 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=56 time=204 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=56 time=208 ms --- 8.8.8.8 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9008ms rtt min/avg/max/mdev = 202.260/243.852/435.330/77.155 ms It seems that the vpn tunnel is slower than the eth0 i/f for the above case. > however. I'd use > something like speedtest.net to do a more useful measurement. I want to use some commands to do this job in a script, so the speedtest.net is not appropriate for my case. Regards > > HTH, > > JJK > -- Hongyi Zhao <hongyi.z...@gmail.com> Xinjiang Technical Institute of Physics and Chemistry Chinese Academy of Sciences GnuPG DSA: 0xD108493 ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
