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