micahmo
No IP without NAT routing or Internet Sharing
Wanting to try out my own routing with Windows' IP Routing, I disabled NAT & Internet Sharing. Unfortunately wg_server won't get the desired IP address, just a Windows dynamic 169... address, if both options are turned off.
As a workaround I can manually execute
netsh interface ipv4 set address name="wg_server" static 192.168.170.1 255.255.255.0
but it would be better, if it could be done automatically with the correct ip address. I am not sure yet, how useful it is to disable NAT.
I am not sure yet, how useful it is to disable NAT.
I did some testing, and it is very useful. NAT is fine and easy to use, but it has some disadvantages: 1.) As peers are behind a NAT, they cannot be addressed from your network 2.) You don't know, from which peer a request originates, as the originating IP will always be the one of the LAN adapter, where the wireguard tunnel is running. This makes things simple, but prevents you to make clever access rules. e.g. you have a program, which allows access only from specific IP addresses (a VNC server perhaps?). Such a program will always see a request from the local LAN.
Using Windows' routing instead of NAT is fairly easy, but you need a "not completely cheap" router, which allows you to add a default route to your wireguard network.
First, you need to enable "packet forwarding" in Windows for both "wg_server" interface and your "LAN" interface. There are various methods how to do this, for simple testing this will do it:
netsh interface ipv4 set int "LAN-Connection" forwarding=enabled
netsh interface ipv4 set int "wg_server" forwarding=enabled
If wg_server interface has the correct IP, this is basically all you have to do on the Windows side. The routing table is set up already to route from / to "wg_server" and "LAN-Connection".
If you have a router with a firewall, you will need to allow access to required services like DNS from the wireguard subnet. But most important, you need to add a static route in your router acting as the default gateway of your LAN. This route should specify the machine running the wireguard tunnel as a gateway to the wireguard subnet. Once this is done, reply packets from your LAN subnet can find a way to the wireguard subnet.
This is a nice solution, especially with NAT being ... "difficult". Why NAT would require Hyper-V to be running really is beyond me. And a "Nat-less" solution simply looks cleaner in my opinion.
It seems that there's a bug with the address field not being populated in the config.
If you manually add Address=192.168.170.1/24 under [Interface] to server_wg\wg_server.conf and reinstall the tunnel it should work.
