Improving on the Auto-connecting Cisco VPN
In my first post in this series I described an auto-connecting setup for Cisco VPNs using OpenWRT and vpnc, and in my second post I showed the details of how I did it. To wrap it up, here are some thoughts about future improvements.
One thing that bugs me about this setup is that I hardcoded some IP addresses. This is a really bad idea, in fact half the reason DNS exists is to stop people from doing this. Someday the VPN administrators could decide to renumber their gateway, and then I would have to connect to each and every WRT and update the configuration, or all my customers would be cut off from the VPN.
I could stop hardcoding the VPN gateway pretty easily, by having it auto-update whenever the WRT boots. Look up the correct IP address and write it to /etc/hosts. (You need to be careful not to trigger the VPN autoconnect when you do the lookup, of course.)
The DNS servers are a little harder to fix. To look them up, we need to actually connect the VPN, and then pull out the nameservers that the VPN tells us to use. But this could be done automatically each time the VPN is connected, and it would make the whole setup more robust. Don’t forget to restart dnsmasq after you reconfigure it.
Another thing that bothers me is that there are a lot of gyrations before the VPN gets connected: a packet goes to a private IP address, matches on the vpn_trigger rule, which queues a message for the ulog daemon, which writes to a file, which causes the file to exist, and also causes tail to create some output, which finally causes the script to start vpnc. Whew!
One suggestion is to use inotify to watch the file, which is a good idea but still requires a file. (Also I don’t see inotify in the OpenWRT Kamikaze package list.) Another possibility would be to write a ulog plugin so that I can omit the file altogether. That might make VPN startup quicker, which would be a good thing.
Finally, if a customer wanted it, there are more sophisticated setups possible. It might be useful to connect to more than one VPN (either serially or at the same time), or to have the different LAN ports on the OpenWRT connect to different VPNs. All of these are possible if the scenario warrants it.
What are your ideas?
No comments:
Post a Comment