Forum archive
OpenVPN on amazon AWS
I am trying to set up your openvpn instance on Amazon aws but seem to be running into a few problems. I have set up an account and used it to get a unique url to get the file for my mobile device. But using the QR code to get the file for the openvpn client on my android device I still cannot connect to my open vpn server.
I have tried to restart the openvpn server on the AWS instance with
/etc/init.d/openvpn restart
but get this error
[ ok ] Stopping virtual private network daemon:. [....] Starting virtual private network daemon: serverSIOCSIFADDR: No such device : ERROR while getting interface flags: No such device SIOCSIFDSTADDR: No such device : ERROR while getting interface flags: No such device SIOCSIFMTU: No such device failed!
Any help with this would be greatly appreciated.
Replies (6)
A quick google suggests that this is a Debian regression
Reply 1Ok, I think I worked it out...
Reply 2I could recreate your issue. Following launch of the OpenVPN appliance on AWS the OpenVPN service did exactly the same as your.
And it seems it was to do with a kernel update, but it appears not to be a regression, but an issue caused by the fact that the server needs a reboot to reload the proper module. Following a reboot my OpenVPN service starts and stops as it should...
root@openvpn ~# service openvpn stop [ ok ] Stopping virtual private network daemon: server. root@openvpn ~# service openvpn start [ ok ] Starting virtual private network daemon: server. root@openvpn ~# service openvpn restart [ ok ] Stopping virtual private network daemon: server. [ ok ] Starting virtual private network daemon: server. root@openvpn ~#
TBH I didn't bother setting it all up so I'm not totally sure whether or not the rest will go smoothly, but at least that's hopefully one less thing that it could be causing issues...
TBH I'm not sure
Reply 3I know very little about OpenVPN so I don't know how it works with DNS. I suspicion is that OpenVPN docs would be worth a search and/or google in general. If you keep in mind that a TurnKey appliance is essentially a specially preconfigured version of Debian (v13.x = Debian Wheezy) so you should be able to find plenty of info. If you find anything of interest that you think the rest of the community could benefit from, it'd be great if you could post back.
As for setting up your own dns then that should be fairly straight forward. Again, keep in mind that it's Debian under the hood and google will find you a multitude of tutorials. Also the TurnKey repo has a BIND module if you prefer Webmin. It's called webmin-bind8 (despite the name it works ok with bind9).
Yes all working :)
Reply 4I treid to setup my own vpn on a standard ubuntu instance when I couldnt get your instance to work, but with no joy. A simple reboot is all it took :) Great to have it working now. Goes with the old famous question "did you switch it on and off?"
Just one more question...
When my clients connect to my vpn service am I right in saying they will be using the dns from the aws instance. I would like to use my own dns servers and maybee setup bind on the same instance.
Thanks for the fast replies on this, great to get it working.
Thanks for your input
Reply 5But this is the forums of TurnKey Linux. Our OpenVPN appliance comes with OpenVPN pre-installed and configured. It appears that this issue occurred as a result of a kernel upgrade that required a reboot.
Thanks for posting back
Reply 6I'm assuming that you are hosting your TKL OpenVPN appliance on Amazon. If so, then you will get a new public IP on reboot (IPs are asigned via AWS's DHCP). If you have a domain name assigned by HubDNS then although HubDNS is preconfigured with a short TTL, sometimes some DNS providers (ISPs seem particularly bad) overrule this and have slow DNS updates.
The best workaround for that whole situation is to apply an AWS Elastic IP. They are essentially a static IP and are free (one per server) when attached to a running instance. If your server is regularly stopped/offline then check the prices on AWS to see if it's worth the cost to you...
I can't be sure, but I found some info that suggests that it is caused by a regression in a new Debian kernel released a couple of days ago. Apparently a workaround is to use an older kernel. When I get a chance I will have a look and see if I can reproduce and provide a verbatim workaround.