VPN / router / broadband issue

[#1]

You need to do the trace to the vpn server when not running the vpn software. What we're trying to establish is whether the routing to the server, to make the vpn connection, is working or not ?
Once (if?) the vpn software is connected then you ought to be able to traceroute to the virtual desktop server.

[#2]

Thanks. Think I get it. There's never been any problem running the vpn software. It was running when I did the trace route to the virtual office server earlier. Well I tried it with and without the vpn running and it gave the same results.
I will still do the trace route to the vpn server if I can to see what happens.

[#3]

Ah!, so the vpn software always makes the connection ok , but then you have trouble accessing the virtual server ?
If that's the case then I think we might be barking up the wrong tree here.

[#4]

That's right. Sorry if not clear. It isn't easy to explain when you don't fully understand what's going on yourself.
I log into a secure site. Start the vpn software. Then use vmware view to access the virtual desktop. It's the last bit that's been the problem since changing isp.

[#5]

No problem.
Given that, I need to think a little more about what may be the issue...

[#6]

Quote from: francemillers

I log into a secure site. Start the vpn software. Then use vmware view to access the virtual desktop. It's the last bit that's been the problem since changing isp.

The tracert you posted previously was not done with an active VPN connection, you wouldn't be seeing plusnet hops if it was through a vpn.
Are you sure the vpn is successfully connecting?
Have you tried disabling Plusnets firewall in the your plusnet members centre login?

[#7]

Once you've checked that the pn firewall is disabled, can you post a traceroute to bbc.co.uk both with the vpn connected and with it disconnected.

[#8]

Morning guys.
I've checked the member centre and firewall was already set to off.
Here are the traceroutes to bbc.co.uk. The first before running the vpn, the second while it's running......
C:\Users\LAPTOP>tracert bbc.co.uk
Tracing route to bbc.co.uk [212.58.244.20]
over a maximum of 30 hops:
  1    3 ms    1 ms    1 ms  dsldevice.lan [192.168.1.254]
  2    20 ms    20 ms    40 ms  lo0-central10.ptn-ag03.plus.net [195.166.128.192
]
  3    15 ms    15 ms    16 ms  link-b-central10.ptn-gw02.plus.net [212.159.2.13
8]
  4    15 ms    14 ms    32 ms  xe-5-3-0.ptw-cr02.plus.net [212.159.0.110]
  5    81 ms    25 ms    14 ms  ae2.ptw-cr01.plus.net [195.166.129.4]
  6    14 ms    14 ms    15 ms  kingston-gw.thdo.bbc.co.uk [212.58.239.6]
  7    *        *        *    Request timed out.
  8    *        *        *    Request timed out.
  9    15 ms    16 ms    14 ms  ae0.er01.telhc.bbc.co.uk [132.185.254.109]
10    15 ms    17 ms    14 ms  132.185.255.149
11    15 ms    16 ms    14 ms  fmt-vip71.telhc.bbc.co.uk [212.58.244.20]
Trace complete.
C:\Users\LAPTOP>tracert bbc.co.uk
Tracing route to bbc.co.uk [212.58.246.103]
over a maximum of 30 hops:
  1    3 ms    1 ms    1 ms  dsldevice.lan [192.168.1.254]
  2    15 ms    22 ms    15 ms  lo0-central10.ptn-ag03.plus.net [195.166.128.192
]
  3    15 ms    17 ms    15 ms  link-a-central10.ptn-gw01.plus.net [212.159.2.13
6]
  4    14 ms    15 ms    14 ms  xe-5-3-0.ptw-cr01.plus.net [212.159.0.108]
  5    14 ms    15 ms    14 ms  kingston-gw.thdo.bbc.co.uk [212.58.239.6]
  6    *        *        *    Request timed out.
  7  281 ms    17 ms  287 ms  ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
  8    16 ms    17 ms    16 ms  132.185.255.165
  9  320 ms    16 ms  288 ms  fmt-vip132.cwwtf.bbc.co.uk [212.58.246.103]
Trace complete.

[#9]

Thanks, as you can see, there's no difference. It's usual for a vpn connection, when active, to route all traffic down the vpn, especially on a company provide laptop. In your case either the vpn isn't really connecting OR the vpn is set to only route certain traffic (possible but unusual). Can you homour us and do a traceroute again to your virtual  desktop server, both with the vpn connected and disconnected. That should enable us to confirm if the vpn really is connected, as the traceroute should fail when not connected but work ( or at least be different ) when connected

[#10]

Quote from: npr

The tracert you posted previously was not done with an active VPN connection, you wouldn't be seeing plusnet hops if it was through a vpn. Are you sure the vpn is successfully connecting?

Think you're right there - the command line interface doesn't look to be going via the vpn at all. You can see which applications are using it - the browser does, the virtual desktop software does obviously, but when running the tracert it doesn't register as an active application in the vpn application list. Does that sound possible? It would explain the tracert going via plusnet if you're saying it shoudn't.

[#11]

It sounds like you're not using a conventional vpn, rather you use a browser to make an https: connection to a remote site , login , get some form of desktop and can then run applications ( e.g vmware view https://openvpn.net/index.php/vmware-view.html ) to allow you to access remote resources. That would explain why the traceroute is doing what it is, only the browser window is actually connected to the remote site. We use a similar facility to access remote systems at one of our Clients sites.
Obviously, that doesn't help with why it behaves differently  now you're on PlusNet and why the problem is intermittent ?
I'm not familiar with vmware view I'm afraid but I wonder if it could be a traffic management problem ? PlusNet use quite a sophisicated system to try and classify certain types of traffic and assign priorities to them. This tries to ensure that time critical traffic such as voip, gaming and browsing is assigned high priority. I wonder if your vpn traffic is not getting classified properly and thus is assigned low priority. At times when the network is busy it means that your vpn traffic might be delayed and posibly give rise to something timing out in the software.
Unless there is someone else on here who uses vmware view then it probably needs a PN rep to investigate a liitle further and if they think it's a possiblility then they may want you to do a network capture so they can see how the traffic is being classified

[#12]

Quote from: MisterW

the vpn is set to only route certain traffic (possible but unusual).

This is correct I'm pretty sure now. These traceroutes aren't going via the vpn, hence they're identical (just tried them again as you suggested).
It's not even all browser traffic, just that going to listed detsinations.

[#13]

Quote from: MisterW

It sounds like you're not using a conventional vpn, rather you use a browser to make an https: connection to a remote site , login , get some form of desktop and can then run applications ( e.g vmware view https://openvpn.net/index.php/vmware-view.html ) to allow you to access remote resources. That would explain why the traceroute is doing what it is, only the browser window is actually connected to the remote site. We use a similar facility to access remote systems at one of our Clients sites. Obviously, that doesn't help with why it behaves differently  now you're on PlusNet and why the problem is intermittent ? I'm not familiar with vmware view I'm afraid but I wonder if it could be a traffic management problem ? PlusNet use quite a sophisicated system to try and classify certain types of traffic and assign priorities to them. This tries to ensure that time critical traffic such as voip, gaming and browsing is assigned high priority. I wonder if your vpn traffic is not getting classified properly and thus is assigned low priority. At times when the network is busy it means that your vpn traffic might be delayed and posibly give rise to something timing out in the software. Unless there is someone else on here who uses vmware view then it probably needs a PN rep to investigate a liitle further and if they think it's a possiblility then they may want you to do a network capture so they can see how the traffic is being classified

Yes, that's pretty much the set up. Now I'm no IT expert (as I'm sure you can tell) but traffic management was my first thought on this weeks ago. I will add to the fault ticket and point to this thread and hopefully get somewhere.
Thanks for all your help on this.