Fairly new to VPN but expert in computing and cannot solve this. We have a client using some sort of Cisco VPN router - not sure what. We use the Cisco VPN client - cannot see the version but file date is 21/12/2002.
We're in UK, client is elsewhere in Europe but with good internet. When we are in that country and on internet (say in hotel) we can connect fine and when connected ping and terminal service to a PC we manage.
But when we are back in the UK, although we can establish the VPN, ping and terminal services ot the machine inside fail. This is however we connect to the internet - through three different ADSLs - all with NAT routers, or with a direct connection via GPRS on mobile phone it all fails - we can VPN but not ping/terminal service.
Client subset is 192.168.0.X - ours in UK when in office is 192.168.107.X or 108.X or 9.1 depending on where we are.
There are about 15 hops over internet to client site.
Other sorts of remoting - for example we use Citrix Gotoassist work fine.
So the only thing we can think of is some sort of timeout in the VPN client.
VPN client is set so that transparent mode is unticked - otherwise VPN cannot be established. Client has confirmed that this occurs with them when they remote in from home. Presumably hotel in the country uses NAT as of course are we.
I'm very puzzled by this - cannot see any difference between hotel in country concerned and our various sites/homes we havw tried in the UK.
Sorry for long ramble but this has us flummoxed. Everything points to something concerning the distance over the internet, e.g. in terms of hops or timings. tracert gives about 15 ops to client dateway in about 120ms.
A reward to anyone with a solution to this.
Well I don't know if I ca offer a solution but here are some thoughts on the matter. If I had to guess (and believe me I am) I would say that latency is the culprit. Citrix is probably working fine as it is designed to handle slow links better than most apps. Distance is (almost) irrelevant for the Internet. It is more the quality of your connection and the connection you are trying to reach. I have a carrier that guarantees a 55ms response time from anywhere on their network to any other point on their network not matter where in the world it is. I just installed an international Cisco VoIP solution that works better than the PSTN for international calls. Network performance is great.
Mis-configuration is another possibility. You need to check your network end to end and then your ISPs network to get to the bottom of this.
can anyone from your team try to VPN into this other company from home (taking your company's network out of the picture altogether) where they have a high-speed Internet connection? If so do they get the same results or is it better? My guess would be better and that points back to your network being the bottle neck. Could also be your ISP has a bad backbone connection into this other country. Some many possibilities, so little time
Well I think that is about it from an architectural side. There are some technical issues that others here can address but I would start with what I have mentioned.
Hope this helps.
Please remember to rate all replies
Hi Travis (or Dennis)
Thanks for this. Our main ISP is a large UK one to whom we have a dedicated 500k fibre. We've also tried three different ADSL connections from two different suppliers and also mobile phone GPRS.
My sense is therefore that this is towards the other end in the country of our client. However their internet is fine and when we're actually in their country in a hotel it works fine - using the same laptop and software.
So presuming it is something in the route over the internet between us and the client - which lets the VPN get established but stops it after that.
Any other ideas on this?
you mentioned "Client subset is 192.168.0.X - ours in UK when in office is 192.168.107.X or 108.X or 9.1 depending on where we are."
just wondering what the vpn client pool is. further, verify the vpn client statistic. go status > statistics, and you will be able to see the actual number of packets being encrypted/decrypted.
nice puzzle! Well let me summarize: while the VPN is up and running you have problems with SOME applications from your company site? Citrix works, but ping/terminal service doesn´t?
So tunnel setup works. Can you check with a packet analyzer, whether pings are sent across the tunnel?
Also: is there a firewall behind the VPN terminating device on the other end? Does your client get the same IP all the time - i mean the VPN interface IP not physical interface. If not, are the FW rules really the same for all possible client IPs?
I had this once that the firewall team "forgot" to setup some rules. Result was that sometimes it worked, sometimes not.
What are the destination addresses to connect to (Citrix, etc.), are they possibly the same as LAN IP?
Hope this helps
Hi Jackko and Martin
I have found some more information. A partner we use with this client *is* able to connect but I think he had to set his internal IP address range to the 10.0.x.x internal range - something like that. So at one sitee I can easily reconfigure - my home - I tried setting the internal IP address range to 172.18.9.x with mask 255.255.255.0 - but this did not work. Unfortunately my partner is on holiday so I cannot check his exact settings.
There is some indication that the client has several 192.168.X.0 ranges at their site but not one which overlaps with our old 192.168.107.x range.
Also I can see from the statistics on the VPN that it does seem to send packets when trying to ping.
Trouble is in this holiday period our client is closed down and they also subcontract their network management.
Not sure if this helps.
so when you are sending ICMP packets, but not receiving replies, it could be IP routing or Firewall (or similar function) in the client site.
In case their internal routing is messed up the result could be as experienced - f.e. static routing on SOME internal routers.
My best bet based on the info so far is firewall rules are not set consistently for all possible client addresses.
Do you get the same IP or the same subnet every time for the VPN interface IP?
P.S.: remotely possible: NAT is used in the client site
to verify the client subnet range i.e. 192.168.x.0, go status > statistics > route details.
from there, you can identify all the subnets which should be routed via the vpn.
Helpful - have just looked at statistics. When I ping it increased the encrypted packet count by 1 but then I get a number of packets discarded on return. Looks like the ping packets are getting bounced for some reason. Not sure what is bouncing them.