On Wed, 24 May 2017 19:04:38 -0400 Text Editor <[email protected]> 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 _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
