From Newsgroup: comp.lang.mumps

<div>My wireguard tunnel works perfectly, and I have two instances, one for the tunnel and one for hosting apps. On the first machine, there are also Docker applications, and I want to access them only over a LAN, using the tunnel.</div><div></div><div></div><div>I've opened the traffic within the subnet and everything works fine on the second machine which has a private IP address within the same subnet. It is only the first that is running the wireguard tunnel that I cannot access the services withe the private IP.</div><div></div><div></div><div></div><div></div><div></div><div>wireguard tunnel download</div><div></div><div>Download Zip: https://t.co/z7BxIekq6I </div><div></div><div></div><div>I did some more digging around and it seems it is an issue with the wireguard startup script in /etc/init.d/wireguard</div><div></div><div>The script defines a variable: AllowIPV4 which is taken from the allowed_ips setting in the peer configuration:</div><div></div><div> AllowIPV4=$(echo $allowed_ipscut -d ',' -f 1)</div><div></div><div>Then it compares it to 0.0.0.0/0 and either sets the default route to wg0 or only the allowed ip</div><div></div><div>if [ -n "$AllowIPV4" -a "$AllowIPV4" != "0.0.0.0/0" ];then ip route add "$AllowIPV4" dev wg0 else ip route add 0/1 dev wg0 ip route add 128/1 dev wg0</div><div></div><div>However the issue is, the allowed_ips is a comma separated list of hosts or networks. But this consideres only the first entry in the list. If you want/need to define more than one entry it will not work.</div><div></div><div>This also seems to be unrelated to the VPN policies setting.</div><div></div><div></div><div>I used the WAN interface of the device to create a new interface called LAN_SRV on 192.168.0.x offering DHCP (this is the interface where i want to route all traffic through the Wireguard tunnel), while the LAN is pretty much the stock configuration on 192.168.1.x also offering DHCP.</div><div></div><div></div><div>And the results are, if i set allowed ips to 0.0.0.0/0, only the interface that is routed to the wireguard tunnel can access internet, the other one is not. If i set the allowd ips to the wireguard network 192.168.10.0/24 there is no internet access on any interface.</div><div></div><div></div><div>After doing so if i set the allowed ips on the Wireguard peer configuration to 0.0.0.0/0 none of the LANS can access the internet, and had to set it back to 192.168.10.0/24 which is the wireguard network.</div><div></div><div></div><div>Traffic from 192.168.1.0/24 network will be routed via WAN. You can configure the second policy to route 0.0.0.0/0 to WG_VPN. This will essentially route all of the other traffic via the Wireguard tunnel.</div><div></div><div></div><div>I somehow managed to achieve what i wanted to by disabling the "Route allowed IPs" from the webui in the wireguard peer settings. By doing this everything started working as intended, at least until this morning.</div><div></div><div></div><div>There was one more strange thing, i couldn't connect to the VPS either from both networks (cant ping the public ip address or connect with SSH) this IP is the remote server used in the wireguard peer configuration.</div><div></div><div></div><div></div><div></div><div></div><div></div><div>If i reboot the device the problem persists and have to remove/add the gateway on the interface to make things work, its like the RUTX09 is trying to reach the public ip address of the vps through the tunnel, but the tunnel is not up yet, because it cant reach the ip through it?</div><div></div><div></div><div>EDIT: In your case I'd suspect you'd want to manage the tunnel yourself though since you're not really using it to access the IPv6 internet (which would normally be the use for a 3rd-party broker).</div><div></div><div>For your own networks you maybe have to look into IPsec+IKEv2 to set it all up (iirc IKEv2 can do IPv6). I'm afraid we have no wiki page for that (the best we have on the subject is on the StrongSwan software I think; ) so you'll have to do some searching online on this subject instead.</div><div></div><div></div><div>Sorry for rambling. I looked into 6in4 before, which apparently is to allow IPv4 clients to access IPv6 servers, within a specially configured IPv4 network. So I probably want 4in6, since I have my IPv6 client that I want to access an IPv4 device through an IPv6/IPv4 server (me (Wireguard IPv6) => main wireguard server (IPv6) => home server (Wireguard IPv6 and router IPv4) => device (router IPv4)). So to my understanding, I'm sending IPv4 packets in an IPv6 network (Wireguard network).</div><div></div><div></div><div>I looked into the kernel to find it supports 4in6 tunnels. OK, but not what I want, since I need to setup a tunnel for each of my servers both in the client (me) and in the server (home server) and have a dedicated IPv6 range for each tunnel:</div><div></div><div></div><div>I wanted the server to translate them automatically without setting up tunnels, etc, like normal routing/forwarding. I wanted to use my prefix to translate, since dead:1234:1::/96 is already routed to the home server correctly, and I do not want my client (me) to have hundreds of tunnels with hundreds of IPv6 assigned.</div><div></div><div></div><div>This seems to be what I want (if WireGuard would handle the translation without setting up tunnels with new IP's). It seems I would need to have Wireguard itself handle the 6in4, as the kernel doesn't seem to allow a tunnel to work in 2 modes at the same time, thus not making us use the already available code in kernel and having to duplicate the code in WireGuard. This doesn't seem to be right.</div><div></div><div></div><div>So I probably want 4in6, since I have my IPv6 client that I want to access an IPv4 device through an IPv6/IPv4 server (me (Wireguard IPv6) => main wireguard server (IPv6) => home server (Wireguard IPv6 and router IPv4) => device (router IPv4)). So to my understanding, I'm sending IPv4 packets in an IPv6 network (Wireguard network).</div><div></div><div></div><div>Neither 6in4 or 4in6 change protocols. Both of those assume that both ends of the connection use the same protocol. A tunnel is set up between the two to cross an incompatible network by wrapping it but no translation/conversion ever happens.</div><div></div><div>If you really want to change protocols (IPv6 connecting to IPv4), you'll need NAT64. No way around that. Please note that with NAT64, the other way around is still impossible (IPv4 connecting to IPv6).</div><div></div><div></div><div>WireGuard would not do any protocol translation/conversion, it would just provide the tunnel. That makes it possible for all machines to have an IPv6 address, allowing you to connect them all together using IPv6 and stick to 1 protocol.</div><div></div><div></div><div>a few weeks ago I setup a WireGuard tunnel with the AUR package networkmanager-wireguard (or networkmanager-wireguard-git, not sure anymore). A few days ago, it seems the project was abandoned or at least both AUR URLs lead to a 404.</div><div></div><div></div><div>So with wireguard I would like to connect just to my home network while all the remaining connections (e.g. google) should be for instance with my mobile data if I am using my mobile data to connect to the internet.</div><div></div><div></div><div>I understand. You want a split tunnel so that the only traffic going over the VPN is the IP range of your home network. All other internet traffic goes directly out of mobile data, not across the VPN.</div><div></div><div></div><div>The NoMachine server is running on Ubuntu. Sorry, I missed that info. However, there are no logs in the server. Connection from Windows never reaches the server. However, if I initiate a connection from a Linux everything works as expected. The problem is that NoMachine client on Windows is ignoring the Wireguard tunnel.</div><div></div><div></div><div>However, the Windows Client times out when trying to connect over the VPN tunnel. Everything else that is behind the VPN connection works. For instance, we have a documentation service that is accessible only internally and the web page opens just fine. SSH connections are also only accessible through the Tunnel, which work fine using PuTTY. The only service that times out is the Windows client.</div><div></div><div></div><div>Visit the WireGuard site for installation options. Install the software that is appropriate for your system. Windows and macOS have apps available to install. Linux systems have packages, typically named wireguard and wireguard-tools, you should install both.</div><div></div><div></div><div>As well as configuring the WireGuard service, the create command also generates a tunnel configuration file, complete with private keys which cannot be recovered. This configuration file will be used in the next step. First it has to be saved:</div><div></div><div></div><div>Run the WireGuard app. Click the Import tunnel(s) from file button. Select your configuration file. The WireGuard app will display the details of your tunnel. Click Activate to bring the tunnel online.</div><div></div><div></div><div>Run the WireGuard app. Click the Import tunnel(s) from file button. Select your configuration file and click Ok. You will be prompted by the OS that WireGuard would like to add VPN configurations; click Allow. The WireGuard app will display the details of your tunnel. Click Activate to bring the tunnel online.</div><div></div><div></div><div>WireGuard is a secure network tunnel, operating at layer 3, implemented as a kernel virtual network interface for Linux, which aims to replace both IPsec for most use cases, as well as popular user space and/or TLS-based solutions like OpenVPN, while being more secure, more performant, and easier to use. The virtual tunnel interface is based on a proposed fundamental principle of secure tunnels: an association between a peer public key and a tunnel source IP address. It uses a single round trip key exchange, based on NoiseIK, and handles all session creation transparently to the user using a novel timer state machine mechanism. Short pre-shared static keys Curve25519 points are used for mutual authentication in the style of OpenSSH. The protocol provides strong perfect forward secrecy in addition to a high degree of identity hiding. Transport speed is accomplished using ChaCha20Poly1305 authenticated-encryption for encapsulation of packets in UDP. An improved take on IP-binding cookies is used for mitigating denial of service attacks, improving greatly on IKEv2 and DTLS s cookie mechanisms to add encryption and authentication. The overall design allows for allocating no resources in response to received packets, and from a systems perspective, there are multiple interesting Linux implementation techniques for queues and parallelism. Finally, WireGuard can be simply implemented for Linux in less than 4,000 lines of code, making it easily audited and verified.</div><div></div><div> df19127ead</div>
--- Synchronet 3.21d-Linux NewsLink 1.2