I removed the 0.0.0.0/0 mask generated by the Freebox to avoid blocking everything (thanks @sturpin!) and also 192.168.1.0/24 without any noticeable effect.
When I activate WireGuard with: wg-quick up wg0 it works fine, but some network accesses from the server to the outside (outside the WireGuard VPN) stop working, and the website hosted by the server becomes very heavily slowed down.
Everything returns to normal as soon as WireGuard is stopped.
What can I do to keep WireGuard active, preferably permanently, and have normal network access to and from the server?
When you use wg-quick up wg0, the WireGuard script reconfigures your server's network routes. Even though you have limited AllowedIPs to 192.168.27.64/27, the script may be adding a default route that points to the tunnel, or it may be modifying the main routing table.
The solution is to make sure WireGuard only manages traffic destined for your Freebox network and does not interfere with the default route for the rest of the traffic
Let's do the following, to see if we achieve the desired effect:
Activate WireGuard as you normally do: sudo wg-quick up wg0
Add a static route so that VPN traffic goes through the tunnel: sudo ip route add 192.168.27.64/27 dev wg0
Force the default route to be that of your public interface: sudo ip route del default sudo ip route add default via YOUR_GATEWAY dev eth0 To find your_gateway you can do so with the command ip route show default
Additionally we will use Table = Off inside the [Interface] section. With this option the traffic destined for the 192.168.27.64/27 network will not be automatically routed. For it to work, you will need to add the route manually with sudo ip route add 192.168.27.64/27 dev wg0.
Then, to make it permanent, you can add this line to the wg-quick script by editing the file /etc/wireguard/wg0.conf with the PostUp option, placed after Table = Off:
[Interface]
...
Table = off
PostUp = ip route add 192.168.27.64/27 dev wg0
Finally, save the file and restart WireGuard
P.S.: Bit by bit I am reaching the level of explanations that my colleague @Asterix usually gives
Before trying them, I notice that the command wg-quick up wg0 executes ip -4 route add 192.168.27.64/27 dev wg0, i.e., what you suggest with the additional -4 parameter. Unless I'm mistaken, nothing in the Freebox restricts me to IPv4, so I don't know why this parameter is present.
Should I still run this command ip route add192.168.27.64/27 dev wg0 or rather ip **-6** route add <the corresponding IPv6 address> dev wg0? Or should I refrain from launching this first command?
Wow, what a scare! I’m glad you were able to regain access
Indeed, the command sudo ip route del default removed the default route from your server, which was the one it used to reach the Internet and therefore for your SSH connection to get back to you
To avoid this problem and keep WireGuard running without affecting other services, I recommend using the Table = off option and configuring the routes with PostUp. It’s the cleanest way and avoids touching the default route.
[Interface]
PrivateKey = ***...***
Address = 192.168.27.71/32
DNS = 212.27.38.253
MTU = 1360
Table = off
PostUp = ip -4 route add 192.168.27.64/27 dev wg0
Based on what you told me, the -4 parameter you see in the ip command in the PostUp that wg‑quick runs is correct because you’re working with IPv4 addresses. If your Freebox also handles IPv6, you might need a similar line with -6 for the IPv6 routes you want, but for what you need, the IPv4 configuration is sufficient.
Restart WireGuard with sudo wg-quick down wg0 and then sudo wg-quick up wg0 so the changes take effect.
With this configuration, WireGuard will not modify your server’s default route.
Hello
I only changed the configuration, as suggested, and didn’t touch the default route.
The server remains reachable and my SSH is no longer blocked , but I still have the same problem.
As soon as I enable Wireguard, there is no access (ping especially) from the server to external sites, and a significant slowdown of the websites hosted on this server (20 seconds for a page instead of half a second; perhaps a consequence of the first issue). It returns to normal when I stop Wireguard.
For your information, when I start Wireguard with wg-quick up it displays:
[#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 192.168.27.71/32 dev wg0 [#] ip link set mtu 1360 up dev wg0 [#] resolvconf -a wg0 -m 0 -x [#] ip -4 route add 192.168.27.64/27 dev wg0