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

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


On Wed, 24 May 2017 19:04:38 -0400
Text Editor <texteditor.si at gmail.com> 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:
> 
> https://pastebin.com/raw/TJvKazSL

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

[Peer]
…
192.168.2.0/24
(/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,
eg: 192.168.2.253/32)

> Configuration files on the Server side:
> 
> https://pastebin.com/raw/2t760WvY
> 
> 
> 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
eth0 -j MASQUERADE

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…

Jean-Yves


More information about the WireGuard mailing list