# [SOLVED]Autostart VPN when needed

## Telemin

Hi all,

I am currently having to use Mathematica and Matlab for University projects, which means that I have to be connected to the university VPN for as long as they are open, as if they cannot re-authenticate with the license server every couple of minutes, they shut themselves down.  I don't like to leave the VPN connected, partly because I don't like the university logging all my traffic (legality not an issue, I just like my privacy) and also because the overhead on the VPN is daft (~5kbps !!) which on a DL limited line adds up if you leave it connected all day.

I also want to make it reconnect on dropout, rather than me only finding out when my program just autosaves and quits on me.

So to cut a long ramble short:

Is there a way to run a service when a connection to a specific IP or IP block is requested, so that the VPN connects automatically, like xinetd but for IPs not ports?

I hope that makes sense, although it may not be a common request, but being a geek I am lazy, and work on the basis of if it can be automated I like to automate it  :Razz: 

Many thanks in advance

-Telemin-

----------

## Hu

One way you could do this would be to use an iptables rule that logs when the connection is made, then have a tool tailing the kernel log and triggering the VPN when you see that message go past.  You could use a static route when the VPN is down to ensure that Linux sends the TCP SYN out, so that iptables can catch it.  The SYN would go nowhere since your local network would not be able to route it, but its mere presence would have triggered VPN initiation.  Yes, this is an ugly hack.  However, if it works, it should be quick to put together.

As regards privacy, you might be able to play with the routes so that only selected university-specific traffic goes over the VPN interface and everything else goes over your regular Internet connection.

----------

## Telemin

Thank's for the reply Hu, that's a really good idea, it should work great as a quick and easy hack to keep my programs from shutting down on me.  Since I would imagine after the first failed syn they should send a few more before giving up.

I had a feeling there was probably going to be nothing that specifically suited my job since it's a fairly odd request I feel, maybe it'll be a weekend project sometime soon, patch xinetd to have ip-based rules as well as port based, or see if there is a way to trick it somehow.

As for the routing I have sorted a script to set it all up for me, I think I'll have to root around in the man pages to point specific domains to the university nameservers with resolv.conf though.  And maybe give openvpn a try so I don't have to pipe yes to the cisco client!

Thank you very much!

-Telemin-

----------

## Hu

If you cannot get the VPN started fast enough after that first SYN to avoid having the application die, you might be able to buy yourself a bit more time if you instead redirect the application traffic to a local listener, which starts the VPN and then acts as a transparent forwarder of the traffic to the real license server.  This would require writing such a listener/forwarder, which is more involved than the cobbled together idea I posted above.

----------

## s_bernstein

Or maybe, you leave your vpn connection open. You don't have to use your vpn as default gateway. So just route the traffic to the licence server via your vpn.

----------

## Hu

 *s_bernstein wrote:*   

> Or maybe, you leave your vpn connection open. You don't have to use your vpn as default gateway. So just route the traffic to the licence server via your vpn.

 He also stated that the VPN connection is chatty and cuts into his limited allowance of bandwidth.

----------

## tcbounce

pptp with dial on demand (weak MS security proven flawed by cain & able and counterplane security)

Well you could turn of DPD (dead peer detection) if you had a fixed ip address. I mean what's a few kb packets every 30 seconds anyway?

If you were really a nut I guess you could use diald and a non KAME -kernel version of IPSEC (old freeswan ipsec network interface) to implement a dial on demand solution. What he's asking for is pretty uncommon in the world of IPSEC.

----------

