View previous topic :: View next topic |
Author |
Message |
Telemin l33t
Joined: 25 Aug 2005 Posts: 753 Location: Glasgow, UK
|
Posted: Thu Jan 20, 2011 3:50 pm Post subject: [SOLVED]Autostart VPN when needed |
|
|
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
Many thanks in advance
-Telemin- _________________ The Geek formerly known as -Freestyling-
When you feel your problem has been solved please add [Solved] to the topic title.
Please adopt an unanswered post
Last edited by Telemin on Thu Feb 03, 2011 1:26 pm; edited 1 time in total |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21635
|
Posted: Fri Jan 21, 2011 3:43 am Post subject: |
|
|
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. |
|
Back to top |
|
|
Telemin l33t
Joined: 25 Aug 2005 Posts: 753 Location: Glasgow, UK
|
Posted: Fri Jan 21, 2011 10:12 am Post subject: |
|
|
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- _________________ The Geek formerly known as -Freestyling-
When you feel your problem has been solved please add [Solved] to the topic title.
Please adopt an unanswered post |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21635
|
Posted: Sat Jan 22, 2011 12:36 am Post subject: |
|
|
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. |
|
Back to top |
|
|
s_bernstein Apprentice
Joined: 11 Mar 2006 Posts: 172 Location: Bremen, Germany
|
Posted: Sat Jan 22, 2011 8:27 am Post subject: |
|
|
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. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21635
|
Posted: Sat Jan 22, 2011 5:47 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
tcbounce Tux's lil' helper
Joined: 18 Nov 2003 Posts: 86 Location: South Korea
|
Posted: Thu Jan 27, 2011 7:17 am Post subject: |
|
|
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. |
|
Back to top |
|
|
|