On 26/9/2015 11:45 μμ, Martijn Grooten wrote: Hi, Put the commands in /etc/rc.local, before the "exit 0" line. --GM

Hi Martijn, On Sat, Sep 26, 2015 at 08:45:13PM +0000, Martijn Grooten wrote: Incidentally, and not meant as a criticism for you as clearly you knew how to debug this: the notifications about enforced reboots suggest that you reboot your VPS yourself to check it boots cleanly. This is an example of why that can be useful, as it might be good to discover that (for example) your VPN doesn't work at a time when you're ready to debug it as opposed to at some random other time. :) I'm not a recent user of openvpn but I suspect the restart of it was not necessary: the other things cause packets to be dropped by either the kernel's routing table or by the kernel's IP filtering, so probably just they alone caused things to not work. Is this on Debian? If so then I'd be inclined to put the /proc/sys/net/ipv4/ip_forward part into the relevant interface stanza in /etc/network/interfaces, e.g: auto eth0 iface eth0 inet static address 85.119.82.xyz netmask 255.255.248.0 gateway 85.119.80.1 pre-up echo 1 > /proc/sys/net/ipv4/ip_forward pre-up modprobe tun However, things under /proc/sys have their own tool in "sysctl", so a neater way to do this might be: auto eth0 iface eth0 inet static address 85.119.82.xyz netmask 255.255.248.0 gateway 85.119.80.1 pre-up sysctl -w net.ipv4.ip_forward=1 pre-up modprobe tun I personally would use either of those two ways as it links the act of enabling IP forwarding with the bringing up of eth0. As this is sysctl though, some people would choose to use Debian's other way of persisting sysctl changes, which is to either put the setting in /etc/sysctl.conf, or else as a file under /etc/sysctl.d, for example: /etc/sysctl.d/local-enable-ip-forwarding.conf: net.ipv4.ip_forward=1 See man sysctl and man sysctl.conf. That's down to taste, I think. As for the iptables rule, if you already have a way of persisting iptables rules (something that uses iptables-save and iptables-restore) then use that. Otherwise it can also go in the /etc/network/interfaces file: auto eth0 iface eth0 inet static address 85.119.82.xyz netmask 255.255.248.0 gateway 85.119.80.1 pre-up sysctl -w net.ipv4.ip_forward=1 pre-up modprobe tun pre-up iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE By the way, those three pre-up commands could be put inside a single shell script placed in /etc/network/if-pre-up.d/ and then nothing would need to be explicitly added to /etc/network/interfaces. If you do this, bear in mind that such a script would be called every time *any* interface was about to be brought up, so inside the script you might wish to test the contents of the $IFACE variable to check it is "eth0" or whatever. Dee man interfaces for details. If not Debian/Ubuntu, well, I dunno. This is distribution-specific. :) Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting

Hello Martijn, On 26/09/15 21:45, Martijn Grooten wrote: As was advised by Hugo and GM, there are two ways to do this, so choose the one that makes the most sense to you. I normally put it in /etc/rc.local purely because it's easier to backup that single file reliably, but pedantically speaking the /etc/sysctl.conf file is the technically "more correct" place to enable this configuration. You should not have to do this, the kernel module should auto-load once you start OpenVPN. This one is the crucial step, because it allows IP addresses from your VPN range to be translated. Without this nothing will work, because none of the 10.x.x.x (or for that matter all of the RFC 1918 address ranges) addresses are specifically not routed over the public internet. Again, there are more than one way to do this depending on the distro you are running. The /etc/rc.local file is again a good place to centralise this, although your distro might have another more "technically correct" place (CentOS uses /etc/sysconfig/iptables, Debian and Ubuntu have their own schema). If OpenVPN is configured to start at boot-up via the normal start-up scripts, you should not have to restart OpenVPN in this manner. The IP forwarding and iptables masquerading bits will enable routing to happen properly. -- Regards, Jan Henkins