SSL Client broken route entry

Lewis:

1 and / or 2 below should resolve the issue.  As indicated by the problem you mentioned, if you don't configure these DNS settings, your remote computer may not be able to find routes to IP addresses (resources) in the host (destination) network.

1.) Do you have DNS set within the Remote Access | DNS settings (and WINS settings too) in the Astaro?  Astaro doesn't yet point out that these settings work with SSL VPN's, but they do.  Because you're coming across the VPN, the Remote Access DNS settings should be configured to the local DNS source IP address you would use if your remote computer was connected inside the host (destination) network.  Usually, that local DNS IP address will be the internal address of the Astaro, a Win2003 server or other DNS server within the host network.  And so that your remote computer can quickly get to a destination, it helps have some static or defined IP addresses listed in that same internal DNS, including the inside address of servers you want to attach to from the remote computer.

BTW - While you're setting up the remote computer, you might want to configure the WINS addresses, and set some addresses in that computer's "hosts" file as well.

2.) You can also list the DNS and WINS addresses you want to use in the VPN client listing in the network configuration for XP.   As in 1 above, the DNS you would use would be the local DNS source inside the host network.

Lewis:

1 and / or 2 below should resolve the issue.  As indicated by the problem you mentioned, if you don't configure these DNS settings, your remote computer may not be able to find routes to IP addresses (resources) in the host (destination) network.

1.) Do you have DNS set within the Remote Access | DNS settings (and WINS settings too) in the Astaro?  Astaro doesn't yet point out that these settings work with SSL VPN's, but they do.  Because you're coming across the VPN, the Remote Access DNS settings should be configured to the local DNS source IP address you would use if your remote computer was connected inside the host (destination) network.  Usually, that local DNS IP address will be the internal address of the Astaro, a Win2003 server or other DNS server within the host network.  And so that your remote computer can quickly get to a destination, it helps have some static or defined IP addresses listed in that same internal DNS, including the inside address of servers you want to attach to from the remote computer.

BTW - While you're setting up the remote computer, you might want to configure the WINS addresses, and set some addresses in that computer's "hosts" file as well.

2.) You can also list the DNS and WINS addresses you want to use in the VPN client listing in the network configuration for XP.   As in 1 above, the DNS you would use would be the local DNS source inside the host network.

Thanks for the info, but neither of these really addresses the issue...

DNS lookups are not a problem, nor do I want the clients banging on the internal servers for DNS (I'd just as soon push down a hosts file to them if local name services were a concern).

There is no WINS running on the network (Novell, with a couple Win boxes as app servers).

Rather, the issue surrounds getting the static route to properly set in the client. The GroupWise server address is specified by IP in GroupWise, as is the Citrix server address in Citrix Program Neighborhood.

Pinging an IP on the office LAN from the affected station, following a "successful" VPN connection, results in no responses, whereas entering a static route - exactly as reported in the VPN log on the client - results in ping responses.

Again, this has nothing to do with name resolution and everything to do with setting a static route in a specific client machine (all other clients - Windows & Linux - behave normally).

Thanks again for the response!

Lewis, I've had exactly the same problem (no response to ping - direct conn's work) with my mixed networks (Novell - Netware and SuSE and Win app servers) and this does resolve the problem.

I didn't implement the DNS for "typical" lookups, but rather to resolve the same problem you're having - finding a route to host side internal servers, like the GW server.  Adding the static entry for internal servers and then propagating that route through the host side DNS does work.

have to agree lewis and disagree eganders;
experience the same problem since 7.305 - clients connects successfull, routing table shows 0.0.0.0 to tunnel, but nothin' goes over there..; if add one of the destination networks manually or del/replace the 0.0.0.0 anything fine...
and dns is set in my config, because we use it for domain comm - so this "workaround" have no effect for me
the problem is reproducable in the meaning that u have to connect 5 times and will have 3 times this error - a simple reconnect helps often, but not ever;
intresting thing is in the log:

Tue Dec 02 23:23:13 2008 route ADD 0.0.0.0 MASK 0.0.0.0 10.200.24.61
Tue Dec 02 23:23:13 2008 ROUTE: route addition failed using CreateIpForwardEntry: One or more arguments are not correct.   [status=160 if_index=15]
Tue Dec 02 23:23:13 2008 Route addition via IPAPI failed [adaptive]
Tue Dec 02 23:23:13 2008 Route addition fallback to route.exe
 OK!

looks for me like route change will be tried first with an windows-unknown method and later with the known route.exe - may be this "fallback" is not really stable...

regards, andre

Thanks, Andre, and Happy New Year. Apologies for the late follow-up...

I'm currently working around this issue (it just cropped up on another box...I wonder now whether it was some dopey Windows update which broke route.exe...I'll need to check) with a .cmd file shortcut on the user's desktop which essentially just sets a static route back to the office LAN via the tunnel IP. 

I really need to see if I can get this to happen on some other platform. I'm going to check the route.exe versions on these Wintendo boxes and see what's up. I *do* see the correct route getting set in the OpenVPN log, but running route print lists the table *without* the setting from OpenVPN.

Adding the static entry for internal servers and then propagating that route through the host side DNS does work.

I'm still not following how one might "propagate a route through [...] DNS." DNS is a name resolution system, mapping hostnames to addresses. It has nothing to do with routing, nor is it possible to list an IP route in DNS. The only way to automate the propagation of a static route is via DHCP, which has no bearing on the issue at hand...

Thanks for following up, though, and apologies for being so late to reply. I think Andre has hit on the issue I'm seeing.

Happy New Year...

Cool. Three of the top people I listen to here are discussing a problem that I've not yet seen.

Thanks - Bob

You're on 7.305, Bob?

As I say, I don't see this with all clients. So far, only a couple. I don't see it on Linux, either (my OS/2 build of OpenVPN - not *my* build, as it wouldn't quite compile for me, actually, but a friend's - won't yet work as we only have a working TUN implementation in our TAP/TUN driver, and for this, we need TAP). I don't have a Mac handy to test right now.

BOB, happy you :-)

in another thread here is a similar discussion - and they use a workaround preventing client from tryin' set the route via IPAPI - forcing route.exe instead...

unfortunately i can't find this and don't remember the syntax for the config.ovpn file...

rgds, andre

A random thought- is it possible that a software firewall or other bit of security software on the problem system(s) is limiting keepalive or other traffic?

possible: sure!
but i don't think so because of than it have to be reproducable - esp. the effect, that sometimes the route will not be set when tunnel comes up; if you restart the tunnel five times sometimes it works on the fourth and not more on the fifth - that makes no sense with a static fw config..
cheers, andre