bonienl

Please try with bonding disabled and only use bridging for eth0. Your attached diagnostics are from AFTER rebooting the system, we need diagnostics BEFORE you reboot and while the system is having the issue.

A configuration change is made effective by inactivating the tunnel with the current (old) configuration and next activating it with the updated (new) configuration, If a tunnel stays inactive, it should indicate some configuration conflict.

GUI has remote syslog functionality. You can set a remote server address there.

One WireGuard tunnel can support multiple peers, you'll need to create a peer configuration for each device that you want to connect.

See updated version 2020.01.02

Another thing you can try is to set a smaller MTU size, like 1400 bytes.

Today's update adds a local tunnel firewall function. This allowes the user to specify one or more IP addresses which will be blocked from remote access over the WireGuard tunnel. This can be useful when "Remote access to LAN" or "Remote tunneled access" is configured, and you want certain systems/networks not accessible (protected). Support for IPv6 is further enhanced in this version too.

When using UPnP, Unraid will periodically check the status on your router. This requires server and router to communicate with each other. If this communication gets broken or the router lost the UPnP setting, you will the message that UPnP is not set

The generated configurations are correct, I can't explain your situation. My own tests confirm your situation happening when peer and server are in the same network. It doesn't make sense to set the AllowedIP address to the local tunnel address, because WireGuard must add a route for reaching the remote side. WG does this by using the AllowedIP address(es), which needs to be the tunnel address of the remote Unraid server. Here is an example of my routing table with 2 active WG tunnels root@vesta:/tmp# ip -4 route default via 10.0.101.1 dev br0 10.0.101.0/24 dev br0 proto kernel scope link src 10.0.101.5 10.253.0.2 dev wg0 scope link 10.253.0.3 dev wg0 scope link Unraid itself is 10.253.0.1 For completeness the WG configuration [Interface] #Main server wg0 PrivateKey=**** Address=10.253.0.1 ListenPort=51821 PostUp=logger -t wireguard 'Tunnel WireGuard-wg0 started' PostDown=logger -t wireguard 'Tunnel WireGuard-wg0 stopped' [Peer] #Apple iPad PublicKey=**** AllowedIPs=10.253.0.2 [Peer] #Oppo phone PublicKey=**** AllowedIPs=10.253.0.3

Your laptop is somehow still in the same network as your server. This explains why when you modify the allowedIP address it starts to work.

I tested the generated config (again) to be 100% sure and it works correctly (you got me confused). The way to test, is making a connection from outside your network and set up the tunnel from the peer over the router to the server. How are you testing?

The config in the GUI shows the Unraid configuration. Unraid = 10.253.0.1 Peer = 10.253.0.4 (=allowed IP) This means for the peer configuration: Peer = 10.253.0.4 Unraid = 10.253.0.1 (=allowed IP) The zip file configuration is correct. At the peer side, you need to reach the server on address 10.253.0.1

I created a new tunnel, then added one new peer with "Remote access to server" (default) and applied the configuration. Next downloaded the zip file for the Unraid configuration and the zip for the peer configuration. Both zip files are correct. Note: each new tunnel will use a new network pool to assign addresses for the peers. Tunnel 0 = 10.253.0.0/24 Tunnel 1 = 10.253.1.0/24 etc

I followed your screenshot which has "Remote tunneled access" set. "remote server access'' does not exist, do you mean "Remote access to server"? Btw it is not explicitely said or denied in the GUI, but a peer set up with "Remote tunneled access" must run in its own tunnel, and can not be shared with peers using a different type of access. Sorry mixed up with "VPN tunneled access", which needs to be on its own tunnel

I created a new tunnel, then added one new peer with "Remote tunneled access" and applied the configuration. Next downloaded the zip file for the Unraid configuration and the zip for the peer configuration. Both zip files contain the correct configuration.

Post a screenshot Btw make sure you are running the latest version...

I suppose you mean "Remote access to server"? When this setting is chosen, it will generate a peer configuration with the tunnel address of Unraid as Allowed IP address. This is on purpose and allows users to reach the server on its tunnel address, even when the peer side uses the same network subnet as Unraid. (recommendation though is that both peers use different network subnets and avoid overlap) This is working okay for me, What steps do you do?

Care to explain in more detail, perhaps with screenshots? If I understand you correctly, you have set up a "VPN tunneled access" connection. Such a connection allows Unraid to reach the outside world via a VPN provider, but likely not the other way round. Depends on the VPN provider.

This is a known issue when using Safari, any other browser works properly. No solution yet...

Yesterday's version has some regressions error. Please update to version 2019.12.27

I made an update, which should address the issues you have observed. Please update.

Please update to the latest version 2019.12.26d Meanwhile I'll do more testing to see if I can replicate your issues.

There is also an "import" function. If you have a WireGuard configuration from a 3rd party (e.g. a VPN provider), you can simply import the settings, give it a name and it should be ready to go.

WireGuard works with "peers" and there is no such thing as server/client. In other words your Unraid server can connect as a peer to any other system running WireGuard.

Browser issue. Usually corrupted browser cache.