Quote:
Originally Posted by err0s  Nope - if the end device is getting a 10.x.x.x address from the hotspot's DHCP, and the VPN's end node you are trying to connect to is another 10.x.x.x then you definitely have a problem. When the client tries to connect to a 10.x.x.x it's going to look in its local route tables and not through the tunnel.
Stevew gives a great description of how two VPN gateways negotiate and encrypt (PHASE 1), but does not address the tunnel creation between the endpoints/nodes (PHASE 2).
What is needed is a way to change the IP address the hotspot issues to the host, and unfortunately the current code does not supply a user friendly way to adjust this. Using a 10.0.0.1 is extremely short sited as it conflicts with a good 90% of the corporate IP addressing schemes I've run into. |
Anyone using the actual 10.0.0.0 network is shortsighted. If you want to use class A, at least be creative. I use it regularly to segregate unauthenticated WLAN traffic from the live network, but I always use some sort of scheme to split octets 2 and 3 into a logical breakout. I usually use octet 2 to denote a site and then make octet 3 the same as the VLAN.