Re: [bitfolk] Making OpenVPN routing settings survive a rebo…

Top Page
Author: Andy Smith
Date:  
To: users
Subject: Re: [bitfolk] Making OpenVPN routing settings survive a reboot

Reply to this message
gpg: Signature made Sat Sep 26 21:14:08 2015 UTC
gpg: using DSA key 2099B64CBF15490B
gpg: Good signature from "Andy Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andrew James Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andy Smith (UKUUG) <andy.smith@ukuug.org>" [unknown]
gpg: aka "Andy Smith (BitFolk Ltd.) <andy@bitfolk.com>" [unknown]
gpg: aka "Andy Smith (Linux User Groups UK) <andy@lug.org.uk>" [unknown]
gpg: aka "Andy Smith (Cernio Technology Cooperative) <andy.smith@cernio.com>" [unknown]
Hi Martijn,

On Sat, Sep 26, 2015 at 08:45:13PM +0000, Martijn Grooten wrote:
> Following the recent upgrade and reboot of my Bitfolk server, OpenVPN
> had stopped working. (I don't use it very often on that server; hence I
> hadn't noticed.)


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. :)

> echo 1 > /proc/sys/net/ipv4/ip_forward
> modprobe tun
> iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
> /etc/init.d/openvpn restart
>
> Not sure if all of these were needed - the iptables one definitely was
> as that was the one that fixed it.


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 there an easy way to make these changes permanent so that they will
> survive a future reboot?


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