BolehVPN Support

Community: Hang out with the Boleh family => General Discussion => Topic started by: Indingo on October 28, 2013, 07:58:19 PM

Title: Netherlands Server Time-Outs.
Post by: Indingo on October 28, 2013, 07:58:19 PM
Hey.

Anyone else been noticing over the past few weeks every now and then the Netherlands based server will time-out for 30 seconds or so and after a few refreshes comes back to normal? I only mention as I doubt its a configuration error as the other servers are fine for me. I was simply wondering if anyone else experienced the same thing?

Thanks.
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on October 29, 2013, 02:52:25 PM
FullyRouted Netherlands? Please post your logs.

When was the last time you updated your configs though?
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on October 30, 2013, 12:44:13 PM
I can post my logs later sure, you mean right after I am connected or after I have the time outs? I only seem to have problems with this one server, and my configs are updated daily on start.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on October 30, 2013, 12:48:29 PM
Version Server:  2.3.6

Version Current:  2.3.6

Run script:  0

Checking installed tap driver...

ROOT\NET\0000                                               : TAP-Windows Adapter V9
1 matching device(s) found.

Use port 44358 as management port

Wed Oct 30 04:46:15 2013 OpenVPN 2.2.2 i686-pc-mingw32 [SSL] [LZO2] [OBFUSCATION] [PKCS11] built on Mar 12 2013
Wed Oct 30 04:46:15 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

Wed Oct 30 04:46:15 2013 Control Channel Authentication: using 'C:/Users/User1/AppData/Local/BolehVPN/cfg/OpenVPN/ta.key' as a OpenVPN static key file
Wed Oct 30 04:46:15 2013 LZO compression initialized
Wed Oct 30 04:46:15 2013 UDPv4 link local: [undef]
Wed Oct 30 04:46:15 2013 UDPv4 link remote: 62.212.85.79:443

Wed Oct 30 04:46:18 2013 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)

Wed Oct 30 04:46:22 2013 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)

Wed Oct 30 04:46:25 2013 [UNDEF] Inactivity timeout (--ping-restart), restarting
Wed Oct 30 04:46:25 2013 SIGUSR1[soft,ping-restart] received, process restarting

Wed Oct 30 04:46:27 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

Wed Oct 30 04:46:27 2013 Re-using SSL/TLS context
Wed Oct 30 04:46:27 2013 LZO compression initialized
Wed Oct 30 04:46:27 2013 UDPv4 link local: [undef]
Wed Oct 30 04:46:27 2013 UDPv4 link remote: 62.212.85.79:443

Wed Oct 30 04:46:27 2013 [server] Peer Connection Initiated with 62.212.85.79:443

Wed Oct 30 04:46:30 2013 TAP-WIN32 device [TAP-Win32 Adapter V9] opened: \\.\Global\{9C7AFA12-3625-4C14-A590-18CBCF21EE1B}.tap
Wed Oct 30 04:46:30 2013 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.10.10.146/255.255.255.252 on interface {9C7AFA12-3625-4C14-A590-18CBCF21EE1B} [DHCP-serv: 10.10.10.145, lease-time: 31536000]
Wed Oct 30 04:46:30 2013 Successful ARP Flush on interface [19] {9C7AFA12-3625-4C14-A590-18CBCF21EE1B}

OK!

OK!

OK!
Wed Oct 30 04:46:40 2013 WARNING: potential route subnet conflict between local LAN [192.168.0.0/255.255.255.0] and remote VPN [0.0.0.0/0.0.0.0]

OK!

OK!
Wed Oct 30 04:46:40 2013 Initialization Sequence Completed

Run script:  1


(My On Login, Logs)

Let me know if you need anything else, I have only had the problem on this server, and non of the others.
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on October 30, 2013, 01:42:59 PM
Does your internet connection drop out? Are you on wireless? Log shows that it's your connection to the server dropping and so it times out and reconnects.

Do you require the NL server specifically for anything? If not, perhaps another server would serve you just as well?
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on October 30, 2013, 01:57:06 PM
Does your internet connection drop out? Are you on wireless? Log shows that it's your connection to the server dropping and so it times out and reconnects.

Do you require the NL server specifically for anything? If not, perhaps another server would serve you just as well?

I am on wireless yes, but don't have the same problem with any of the other servers just the NL server. My connection is fine, its just this one server that gives me drop-outs. I use the NL server because its ports are closed, the Canada and HK servers are ports closed also "Don't wish to use the UK server". I could use Canada/HK but both are far and slow the connection down. I wish to only use a server with closed ports and not open ones such as the Netherlands server which is geographically close to me and the fastest server for me.I also like that it has "Static" and not "Dynamic IP". I would like to get the issue resolved, I am not sure why supposedly this is the only server that gives me problems.
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on October 30, 2013, 09:21:43 PM
What about FullyRouted-France? Fits your requirements pretty well.

Please also do a traceroute to the NL server, and a pingtest with -n 100

Post your results here
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on October 30, 2013, 09:59:26 PM
What about FullyRouted-France? Fits your requirements pretty well.

Please also do a traceroute to the NL server, and a pingtest with -n 100

Post your results here

France exit IP and enter IP are different, I also find many open ports/stealth "not closed" ports. I require both enter and exit IP to be the same and static, and all the ports but the ones needed to be blocked. Just like the NL server, but without the drop-outs.
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on October 31, 2013, 02:49:44 PM
Alright. Could you do a pingtest and traceroute as stated in my last post?
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 01, 2013, 02:48:28 AM
Alright. Could you do a pingtest and traceroute as stated in my last post?

I would really love to man... but its driving me crazy. I have tried a few times already and it takes me so many retries to get it to work, and when it works it disconnects during testing. I seriously don't know why its only this server.. but like, its getting to a point trying to find the answer myself is just wasting my time.
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on November 01, 2013, 02:58:17 PM
Sorry, I should have been clearer. With the VPN off, please run the pingtest and traceroute.

Where is your location by the way Do you have any antivirus / firewalls installed? Any other VPN software?
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 01, 2013, 10:32:37 PM
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows>tracert 62.212.85.79

Tracing route to br3nl.bolehvpn.net [62.212.85.79]
over a maximum of 30 hops:

  1     3 ms     3 ms     3 ms  SkyRouter.Home [192.168.0.1]
  2     *        *        *     Request timed out.
  3    15 ms    17 ms    14 ms  ip-84-38-37-12.easynet.co.uk [84.38.37.12]
  4    17 ms    15 ms    15 ms  027808f3.bb.sky.com [2.120.8.243]
  5    12 ms    12 ms    12 ms  peering.thn.lon.leaseweb.net [195.66.225.56]
  6    21 ms    19 ms    19 ms  31.31.32.73
  7    19 ms    22 ms    25 ms  85.17.100.143
  8    19 ms    18 ms    20 ms  te9-3.hv15.evo.leaseweb.net [82.192.95.227]
  9    18 ms    19 ms    18 ms  br3nl.bolehvpn.net [62.212.85.79]

Trace complete.

@@

C:\Windows>ping 62.212.85.79

Pinging 62.212.85.79 with 32 bytes of data:
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57

Ping statistics for 62.212.85.79:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 18ms, Average = 18ms

UK, England. GDATA Internet Security 2014, Mullvad VPN "Not a problem, checked already."
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on November 03, 2013, 08:44:23 AM
ping 62.212.85.79 -n 100

After you run the above command, is there any packet loss? Could you also try the FullyRouted-TCP-EU server?

Will be referring this to my supervisor.
Title: Re: Netherlands Server Time-Outs.
Post by: PitBoss on November 03, 2013, 09:22:59 AM
You can use France server. The entry IP is only use by the user to connect to the server and and there are 4 entry IP for this server and one exit IP. Reason is, this server is a gigabit server with 4 redundant/load balancing static entry IPs and one exit IP.

I will check on the NL server but this is usually due to some network stack getting corrupted, either from client or server side.
Since all other servers is doing ok, then it could be server side.

In the mean time, reset your network stack by doing this:

Open command prompt and then type (make sure run as administrator):

netsh int ip reset C:\netsh.log.txt
netsh winsock reset

You may need to reboot your PC a couple of times after doing this.

Or you can just visit this http://support.microsoft.com/kb/299357 (http://support.microsoft.com/kb/299357)

See if this resolves the issue or not.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 03, 2013, 05:41:26 PM
ping 62.212.85.79 -n 100

After you run the above command, is there any packet loss? Could you also try the FullyRouted-TCP-EU server?

Will be referring this to my supervisor.

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>ping 62.212.85.79 -n 100

Pinging 62.212.85.79 with 32 bytes of data:
Reply from 62.212.85.79: bytes=32 time=21ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=21ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=42ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=21ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=34ms TTL=57
Reply from 62.212.85.79: bytes=32 time=41ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=31ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=23ms TTL=57
Reply from 62.212.85.79: bytes=32 time=20ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=76ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=20ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=20ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=38ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=23ms TTL=57
Reply from 62.212.85.79: bytes=32 time=20ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=21ms TTL=57
Reply from 62.212.85.79: bytes=32 time=38ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=20ms TTL=57
Reply from 62.212.85.79: bytes=32 time=20ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=89ms TTL=57
Reply from 62.212.85.79: bytes=32 time=18ms TTL=57
Reply from 62.212.85.79: bytes=32 time=19ms TTL=57

Ping statistics for 62.212.85.79:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 89ms, Average = 21ms

In the mean time, reset your network stack by doing this:

Open command prompt and then type (make sure run as administrator):

netsh int ip reset C:\netsh.log.txt
netsh winsock reset

You may need to reboot your PC a couple of times after doing this. See if this resolves the issue or not.

Done, I will use NL server today and see if the problem is still there. Let me know if you find anything on the server end.

Thanks Chris, PitBoss.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 03, 2013, 07:34:49 PM
Just an FYI as well, I reported it to customer support but I don't think its being looked into. I strongly believe BolehVPN is leaking on the "CLASSIC-STUN" protocol. I have been able to see BolehVPN Fully-Routed servers with DNS leak enabled leaking through CLASSIC-STUN. "Simple Traversal of UDP Through NAT" Anything we can do to fix that? I can replicated it very easy in wireshark.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 05, 2013, 08:59:16 PM
I found NL better, but still have some time-out issues, any word on the CLASSIC-STUN? as well? Also any thing found on the server?
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 06, 2013, 10:32:09 AM
I'm still having issues with NL.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 07, 2013, 02:39:03 AM
Yep.. Just logged on and getting the NL issues again, pages not loading etc etc, I had to turn it off to post.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 08, 2013, 04:56:02 AM
bump.
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on November 08, 2013, 09:52:29 AM
Could we have your latest log? I'd already mentioned your reply to my superior, think he missed it
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 09, 2013, 04:56:58 AM
Could we have your latest log? I'd already mentioned your reply to my superior, think he missed it

Just made a new one, came to post here on the NL connection, waited a few minutes and gave up, here's the log anyway.

Version Server:  2.3.6

Version Current:  2.3.6

Run script:  0

Checking installed tap driver...

ROOT\NET\0000                                               : TAP-Windows Adapter V9
1 matching device(s) found.

Use port 44358 as management port

Fri Nov 08 20:53:31 2013 OpenVPN 2.2.2 i686-pc-mingw32 [SSL] [LZO2] [OBFUSCATION] [PKCS11] built on Mar 12 2013
Fri Nov 08 20:53:31 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables

Fri Nov 08 20:53:31 2013 Control Channel Authentication: using 'C:/Users/User1/AppData/Local/BolehVPN/cfg/OpenVPN/ta.key' as a OpenVPN static key file
Fri Nov 08 20:53:31 2013 LZO compression initialized
Fri Nov 08 20:53:31 2013 UDPv4 link local: [undef]
Fri Nov 08 20:53:31 2013 UDPv4 link remote: 62.212.85.79:443

Fri Nov 08 20:53:33 2013 write UDPv4: No Route to Host (WSAEHOSTUNREACH) (code=10065)

Fri Nov 08 20:53:35 2013 [server] Peer Connection Initiated with 62.212.85.79:443

Fri Nov 08 20:53:37 2013 TAP-WIN32 device [TAP-Win32 Adapter V9] opened: \\.\Global\{9C7AFA12-3625-4C14-A590-18CBCF21EE1B}.tap
Fri Nov 08 20:53:37 2013 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.10.10.198/255.255.255.252 on interface {9C7AFA12-3625-4C14-A590-18CBCF21EE1B} [DHCP-serv: 10.10.10.197, lease-time: 31536000]
Fri Nov 08 20:53:37 2013 Successful ARP Flush on interface [19] {9C7AFA12-3625-4C14-A590-18CBCF21EE1B}

OK!

OK!

OK!
Fri Nov 08 20:53:47 2013 WARNING: potential route subnet conflict between local LAN [192.168.0.0/255.255.255.0] and remote VPN [0.0.0.0/0.0.0.0]

OK!

OK!
Fri Nov 08 20:53:47 2013 Initialization Sequence Completed

Run script:  1

I hope the CLASSIC-STUN issue gets looked into as well.
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on November 09, 2013, 06:48:37 PM
Did you try the winsock reset as pit boss posted ? It's not an issue with the server according to him.
Title: Re: Netherlands Server Time-Outs.
Post by: PitBoss on November 09, 2013, 07:13:25 PM
Please check on my previous posting to reset your winsock and see if it resolve the issue.
As for CLASSIC-STUN, please elaborate what is your concern on classic STUN as Openvpn uses its own nat transversal and not based on STUN.
Title: Re: Netherlands Server Time-Outs.
Post by: PitBoss on November 09, 2013, 07:26:48 PM
I found NL better, but still have some time-out issues, any word on the CLASSIC-STUN? as well? Also any thing found on the server?
Just an FYI as well, I reported it to customer support but I don't think its being looked into. I strongly believe BolehVPN is leaking on the "CLASSIC-STUN" protocol. I have been able to see BolehVPN Fully-Routed servers with DNS leak enabled leaking through CLASSIC-STUN. "Simple Traversal of UDP Through NAT" Anything we can do to fix that? I can replicated it very easy in wireshark.
Appreciate if you can forward wireshark report on this as wireshark can identify them as Openvpn but for DNS queries, this is something else. Openvpn only passes or push the DNS to the OS network stack. It is the OS layer that supposed to receive the DNS and add them to the tap adapters. It does not remove the pre-connected DNS from the main adapter. BUT in some cases, especially Windows, it removes them which is quite baffling to most people and when you do a lot of connect and disconnect, it will also corrupt the network registry by not removing certain network information which will cause issue like the one you are facing.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 10, 2013, 04:01:45 AM
Did you try the winsock reset as pit boss posted ? It's not an issue with the server according to him.

I did, I mentioned that I tried the winsock reset in my previous postings. I did not find it helped.

I will also attach the wire-shark CLASSIC-STUN log. I will also put a screenshot for you, Its the same on all servers and the one I was using this time was Sweden-FullyRouted.

(http://i.imgur.com/awae6UP.png)
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 10, 2013, 04:02:41 AM
In my last post changed .rar of my file to .zip as the web forum does not let me upload .rar files, so just change it if you cant open it.
Title: Re: Netherlands Server Time-Outs.
Post by: PitBoss on November 10, 2013, 01:01:53 PM
Hmm, appreciate if you can run the same wireshark without VPN connected and after connected.

Looking at your result, seems like those STUN were initiated before the VPN is connected and this connection is persistent on its pre-VPN routing. Those are applications running on UDP with point to point connection. Most probably steam UDP services.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 10, 2013, 03:01:50 PM
Hmm, appreciate if you can run the same wireshark without VPN connected and after connected.

Looking at your result, seems like those STUN were initiated before the VPN is connected and this connection is persistent on its pre-VPN routing. Those are applications running on UDP with point to point connection. Most probably steam UDP services.

Nope. I already mentioned to your staff which got ignored in a support ticket. I have tested thoroughly. I have already run tests where the VPN is already active before any steam processes are loaded into memory. I then launch a game Age of Empires 2 HD from steam, and join a multiplayer lobby. While in the lobby players who join connect to my computer directly by-passing the VPN and the same happens in reverse, my computer contacts them outside of the VPN tunnel. I know that this bug/leak happens with AOE2 HD on steam, and its probably not just AOE2 HD, I am pretty sure all CLASSIC-STUN traffic would leak in this manner, I am just not aware/wish to put time into finding other products that use the CLASSIC-STUN protocol. I'm not stupid, if it was a connection initiated before VPN connection, I would have ruled the leak out ages ago. I also wish to report the "Mullvad" VPN I used to test after finding this issue, does not leak. I do not get the same direct requests while using Mullvad VPN. I also wish to point out Mullvad use 128 Blowfish, which is what you used before changing the algorithm. I had this issue before you changed to AES 128 so its not anything to do which that, I had the issue on Blowfish 128 / AES 128 on BolehVPN on all Fully-Routed servers.

I also wish to report my problem with the NL server still persists for what ever reason.

If you want to TeamView me and see the live capture for yourself, you can be my guest.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 11, 2013, 10:04:57 AM
I also notice leaks while windows update runs of a similar manner, I think they may just be DNS, but still... should not be happening with DNS leak fix enabled.
Title: Re: Netherlands Server Time-Outs.
Post by: PitBoss on November 11, 2013, 09:10:53 PM
DNSleak fix may or may not work. Some may not even need a dns leak fix. I have no clue why some needed the dns fix or why on some windows, you don't have to fix it.
As for the Classis STUN, I need to run more tests. Using my COD MW3, BO2 etc..steam powered gaming, I did not see that in my wireshark. Send an email to support and schedule a time for teamviewer. Bad thing is that I need legit steam license to install and launch AOE2.

Also, please run a tracert to the STUN ip address while connected to the VPN. See if the traffic goes thru the VPN or direct to STUN server.

Thanks
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 12, 2013, 01:24:22 PM
DNSleak fix may or may not work. Some may not even need a dns leak fix. I have no clue why some needed the dns fix or why on some windows, you don't have to fix it.
As for the Classis STUN, I need to run more tests. Using my COD MW3, BO2 etc..steam powered gaming, I did not see that in my wireshark. Send an email to support and schedule a time for teamviewer. Bad thing is that I need legit steam license to install and launch AOE2.

Also, please run a tracert to the STUN ip address while connected to the VPN. See if the traffic goes thru the VPN or direct to STUN server.

Thanks

Can you get support to contact me with a time? I am pretty much fine with whenever.

"Or just PM me here"
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on November 15, 2013, 10:00:30 AM
Think pit boss missed your reply. Could you email support@BolehVPN.net and he'll arrange to Teamviewer you
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 16, 2013, 12:38:53 AM
Think pit boss missed your reply. Could you email support@BolehVPN.net and he'll arrange to Teamviewer you

I believe he did yes, I would like to just respond on the forum / private messages, its much more easy for me.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 16, 2013, 10:23:32 PM
lol, well.... just let me know. I checked another VPN as well "PrivateInternetAccess". PIA as well as Mullvad VPN's do not leak on the CLASSIC-STUN and Windows Update, which BolehVPN does, for some reason. I don't know why, just wanna help you guys get it fixed.
Title: Re: Netherlands Server Time-Outs.
Post by: Chris on November 17, 2013, 01:30:35 AM
Alright, I'll notify him. You could also send him a PM with when you're available if you wish.
Title: Re: Netherlands Server Time-Outs.
Post by: Indingo on November 18, 2013, 12:06:41 AM
Thanks Chris, Thanks PitBoss.

Anyone who was following this thread, the problem is considered solved, PitBoss found out what the problem was and it will be fixed very soon, maybe even with the next update. Thanks guys.