auto init tunnel based on connectivity?

This is really beyond the scope of the client control. What you are proposing could more than likely be done in several ways (a hidden program at startup, a system service, etc). There needs to be a controlling process to manage the policy you would like to enforce. You'll also have to determine if this is to be a manual process (client provides username/password) or automatic (where the credentials are hidden securely on the machine).

 

 

Please keep in touch as I'd be very excited to hear about how you decided to implement this.

 

 

-Joe

Thanks for the feedback Joe, I will investigate this further and most probably I will write my own then with some hooks on the nics to see when an interface is enabled and then run some connectivity checks to figure out if i want to start the client.

 

 

But,

 

 

The way I see it this is functionality that could (should) be implemented in the win32client. Just have the client started at all time but not active (just the monitoring part) and based on criteria initiate tunnel. It shouldnt really be hard to do this in the client (not hard outside either but still a function that customers are interested in).

 

 

It would make you able to have an always-on vpn approach outside your internal network.

 

 

Ill post my findings at a later time.

 

 

Cheers,

 

 

Alex

Alex,

 

 

Were you able to get this working?

 

 

By the way, could you clarify something for me? When you refer to the win32client, were you referring to the FPSDK -- which is basically f5fpapi.dll -- which is a wrapper for the COM component "F5 Networks AppTunnel Type Library"?

 

 

Thanks.

We did this yes, but not within the f5 product api:s. Basically we coded a small app that registered with the NLA service to get updates when connectivity changes occur on the machine. Based on this and some custom logic here we trigger the app to start vpn. So this would be generic to any vpn solution really it has nothing to do with F5 only one demand and that is that you are able to start vpnclient in the way you want (this looks different in different software, some will allow a pass through auth based on a smartcard so its invisible to the user, others will pop up some sort of challenge, your mileage will vary).

 

 

/Alex

 

Thanks Alex.

 

That app that starts the vpn: is it a desktop application or a Windows service?

 

Its actually a two part solution, one service where basically all the logic etc is baked into, but since the vpnclient needs to be invoked as the logged on user thats done from something running as the logged on user I believe, at first this was a trayicon but since you already have 10000000 of those that was ditched later I think. I did not do the end result only the specification what was supposed to happen and some initial investigations if the solution was feasible at all - which it proved to be.

 

 

This could certainly be coded into any vendors client fro the start which would be the ideal solution really. Until then, were doing it ourselves.

Joe, in your response to Alex, you indicated that what he was trying to do could be done with a system service. Were you referring to the service initiating the tunnel, or just the extraneous logic (as Alex ultimately did)?

 

 

If you were indicating that the tunnel could be established by a service, could you elaborate a bit on that?

 

 

Thanks.

We did something like this. We took the VB6 sample application and wrapped it in SRVANY to create the service.

Ultimately, we did get this to work from a system service we wrote from scratch in .NET. The service monitors conditions and when certain conditions occur, it launches the VPN tunnel. Works even without a logged in user. Except for a problem with Vista which I will start a new thread on.

Nice to see that others are doing pretty much the same as us then with success.

 

 

One question to Rickstout, are you handling all the monitoring yourself or are you letting "Network Location Awareness" handle some of your logic and just register for events? Thats the approach we had so you just wait for a message that the network environment changed and then run a few logical tests to see what network you are on at the time.