Can't seem to split tunnel using tables the way I can in OpenVPN

Bzzzz lazyvirus at
Thu May 25 19:13:37 CEST 2017

On Wed, 24 May 2017 19:04:38 -0400
Text Editor < at> wrote:

> Trying to replicate my OpenVPN routing setup, tunnel is split to go
> to /24 subnet inside OpenVPN without the default traffic going through
> it.

Hi Text Editor,

> I can ping the
> endpoints inside the Wireguard VPN,

So your WG VPN is acting good, giving you access your server from
another place than your LAN, ie: through a phone tethering or from
a friend's connection.

Your setup seems overly complicated, as touching network I/F confs isn't
a requirement, neither w/ OVPN or WG.

ie: for the server, I took a copy of /etc/init.d/rmnologin (because it
was the last one to be enabled into /etc/rc2.d and I want my VPN to be
the last one to be activated), then I modified it, testing and using the
presence of 'wg-quick' that is far more usable than modifying the
network I/F confs or manually use 'wg' instead; on clients, scripts are
manual, but also use 'wg-quick'.

A quick run of chkconfig and the links are created in the right places,
starting your VPN server at boot and allowing to start/stop it manually.

I won't say it is the best way to do that, but it has the advantage not
to scatter configurations in all the server corners.

> but trying to reach the internet
> via the internet seems to not work
> Configuration files on the Server side:

IIRC, using means _all_ traffic is routed through the VPN;
IMHO, your server setup should otherwise use something like:

(/24 IF you intend to use WG to unite 2 LAN; for a roadwarrior, it
might be better to restrict more stricly to it's IP,

> Configuration files on the Server side:
> This same concept works on OpenVPN without issue, not sure what is
> happening

AFAIK, given you formerly authorize packets forward (either indefinitely
into /etc/syctl.conf or temporarily by:
echo 1 >/proc/sys/net/ipv4/ip_forward), the only iptables rules you need
(into the server conf file) are:

PostUp = iptables -t nat -I POSTROUTING -s <VPN IP segment>/24
-o eth0 -j MASQUERADE

PostDown = iptables -t nat -D POSTROUTING -s <VPN IP segment>/24 -o

remember that any kind of testing on packets, ie: established, related,
etc) can be a huge loss of time (it has to be computed for _each_
packet), hence, a loss of throughput in your VPN.

And BTW, it is much more dangerous to reveal your keys on the Ternet
than your endpoint IP address…


More information about the WireGuard mailing list