Michael D. Berger wrote:
> The problem described below occurs with TCP as well
> as UDP. I have attached a client log.
TCP/UDP shouldn't matter here, so use what is best for your networking
situation (UDP in most cases.)
>> -----Original Message-----
>> I take my laptop to a hotspot either at
>> a coffee house or my church (with the Linksys
>> programmed to pass 1194 if it is still in the
>> system). It doesn't work. here are some
>> 1. The client log shows that it got the
>> server-bridge information from the server,
>> but it says it completed with errors. It
>> doesn't say what the errors are (at
>> verbosity level 4).
I believe the error is because you're pushing a route that already
exists for the tap adapter. If you're bridging to the 192.168.1.0/24
network, don't push that route. Your client logs show that the client
received a push for the 192.168.1.0/24 route to be routed through
192.168.1.32. This shouldn't exist, because the 192.168.1.0/24 network
will be reachable on the link-layer of the tap device, so the route is
already added and shouldn't be specified again, especially not with that
that gateway. If you aren't pushing any additional routes that are made
available through the VPN, try simply removing the route and
route-gateway statements since they're not necessary unless you're
trying to push routes other than the one the client is a part of with
the bridged adapter.
>> 2. The client TAP interface does not have a
>> correct IP address. Rather it has, for
>> example, 169.254.216.58, which goog informs
>> me is assigned by WinXP when it has nothing
If the route wasn't what caused this problem, try the suggestions at the
URL specified after that error. Basically, insure that the tap adapter
is using DHCP, is not firewalled (by the XP firewall or any 3rd party
firewall) and if both of those didn't help, try one of the `ip-win32
netsh` method rather than the ipapi which is default.
>> 3. 169.254.216.58 IGMP packets appear on the
>> 4. On the client, neither pings, nor any other
>> attempt to access the internet, work. This
>> problem persists after the OpenVPN
>> client is closed, but can be corrected by
>> logging off the hotspot and logging on again.
>> I note that with the "WAN" tests, the client is
>> wired, while at the hotspots, it is wireless.
If the wireless network includes 192.168.1.0/24, your VPN won't work
because the computer can't know which of the 2 identical networks you
are referring to. Common networks are usually a bad idea to use for VPN
clients that might be connecting in at various location due to this problem.
Description: OpenPGP digital signature