Bienvenido! - Willkommen! - Welcome!

Bitácora Técnica de Tux&Cía., Santa Cruz de la Sierra, BO
Bitácora Central: Tux&Cía.
Bitácora de Información Avanzada: Tux&Cía.-Información
May the source be with you!

Saturday, February 19, 2011

Warning symbol on Hamachi connection to partner PC

[failed to connect to VPN tunnel]
Try looking for a different or additional firewall product on the problem machine, like McAfee Security Center (totally hostile to VPNs) or ZoneAlarm or whatever. These are especially suspect if you can chat but cannot ping. 
check out this link for VPN on Windows XP xp.php3 
Hamachi works across NAT routers, even if there are NAT routers at both ends of the connection. In nearly all cases it doesn't require any reconfiguring of the routers - no port-forwarding required. All machines running the Hamachi client are simply and individually visible, even if they are all behind the same router.
Clearing the arp cache fixes 90% of connection problems to the internet. - apart from manually clearing the cache by using a command code or in services, i mainly use the connection repair - double click your connection, wireless or wired then the support tab at the top of that window and then repair. fixes 90% of internet connectivity problems. if repair does not work or fails use one of the commands to clear the arp-cache manually.
What I had to do was tell the connection to not use the remote gateway to connect through internet. On the XP machine (works on Vista and 7 also) go to the properties of the VPN connection. Click on the Networking tab and double click Internet Protocol Version 4 (TCP/IPv4). Click Advanced and uncheck the box for "Use default gateway on remote network." This will route all of your local traffic through whatever network you're locally connected to, and any remote traffic through the VPN connection. This also assumes that you're not trying to route your internet traffic through the VPN. If you leave this option set, then you will not be able to access any local network resources without manually specifiying routes to get to them. This is the default design of VPN :D
Nice work! Did the trick for me.
Could connect to the vpn but not the servers on the network. Thought it was the router because on other wireless networks I could connect fine. This solution did the trick however. Thanks.
Do the following in the command prompt:
route delete
where is your LAN network ID (usually xx.xx.xx.0)
The lack of connectivity is generally either vpn client configuration based, or the firewall on the local pc's that are unable to pass traffic would be the first thing i would check.
Generally if a vpn client successfully connects, that means that handshake portion is over, a secure connection has been established (port 51) ... however data is unable to use this tunnel for some reason ergo port 500 is blocked or if that is not the case then the traffic is getting to the far end but not returning via the tunnel, (in this case that is not true, as 2 of the PC's are using the same configuration and most likely the same tunnel on the firewall (remote dialup clients) with traffic returning to them.
so back to basics:
1) check the client vpn configurations
a) make sure that the client is setup to "only connect manually" or has split horizon enabled.
2) check that the firewall has not blocked port 500 on the PC, if you are unable to view the blocked list, then
create an exception rule for ports 51 and ports 500 inbound and outbound.
may be that you have a worm which is causing this trouble.
arp-cache worm. it's the only way this can go wrong.
worms publisher: microsoft updates.
I have 5 office computers all running Windows XP Pro SP3. THey are all on my home office network - same subnet. They have an identical VPN configuration to one of my customers. I will refer to them as A, B, C, D and E.
A, B and C can connect to my client using VPN but cannot ping anything on the remote network. Once the connection is made these computers can't access anything on the local lan either. D and E can connect to the remote network and can ping the router and other resources on both the local and remote LAN.
The fix:
I wanted to compare the routing table of a successful and non successful connection so I was on computer A and remoted in to computer E using remote desktop. While remoted in I successfully connected to my customer using VPN. I minimized that window and then remotely accessed computer B from computer A. I then fired up a VPN connection and low and behold I was able to ping and access resources on the remote network. I couldn't believe it. I disconnected both remote desktop sessions and logged on at the console of B. I then established a VPN to my customer successfully. Computer B seemed to be "fixed". To make sure that nothing changed on the customer's end I went back to computer A and tried to make a VPN connection. I made the connection to the customer but could not ping or access resources on the remote LAN. So, I still had the problem with A and C.
I then did a remote desktop session from computer B to A and while on A established my VPN session to my customer and then everything was fixed on A. I did the same to C and now that one works as well.
Does anybody have a clue as to why this worked?
Vista makes the distinction between local and www connections, but not winxp.
I run Hamachi, but with a yellow caution sign on right hand side (failed to connect to VPN tunnel).
What did I do?
I uninstalled the Hamachi network adapter via device manager, and then uninstalled Hamachi software. After restarting the computer, I proceeded to install Hamachi afresh, from which point on the software worked fine.
For Rome: Total War engine to connect its Lan gameplay through Hamachi, you must make sure that Hamachi is first place on the Connections list.
[Network and Sharing Center - Manage Network Connections - Advanced - Advanced Settings - Adapters and Bindings - Connections]
For Linux I had the same problem, but I've searched a little bit around and found next section is the CHANGES-file
 * Added an option of keep-aliving tunnels. When enabled, it will cause
Hamachi to send out small UDP packet over the tunnel if there was no
  outbound traffic for a specified number of seconds. Default value is
  90 seconds.
  To modify the value add the following line into ~/.hamachi/config:
   KeepAlive 123
  where 123 is an idle timeout in seconds. Minimum allowed values is 10.
  To disable tunnel keep-alives, set KeepAlive to 0.
 I've tried this on my Linux-clients (6 are running) with value 10 and they all stay online.
The file 'config' does not exist anymore, but I've created it and restarted hamachi.
 Works fine for me.
Edit: I still get yellow warnings in the Hamachi² client, but the connection stays alive! And that was the most important to realise!

No comments: