4 ms·

With wireguard since there is no "connection" to be maintained, you could argue this is a non-issue.

mynameisvlad 5y ago
But Wireguard itself relies on an active internet connection, which needs to still be set up to not fall back on in case the wg connection deactivates.
- midasuni 5y ago
  > With wireguard since there is no "connection" to be maintained
  - mynameisvlad 5y ago
    What does that even mean? Let's say you have a Wireguard configuration, wg0 which runs off ens0. If your wg0 connection dies, for whatever reason (let's say the remote server goes down), your computer falls back to ens0. What does "not having a connection to be maintained" change about this?
    - OJFord 5y ago
      GP's just taking issue with the word 'connection', it's fine, I think it's clear.
      - midasuni 5y ago
        It’s really not. If you have a route down your WireGuard interface, it’s not going to stop should the end point of that interface no longer be routable.
    - megous 5y ago
      Wireguard will keep contacting the remote server. You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0. Wireguard only has "connection" in a sense that it caches some runtime information about the peer's endpoint, but endpoint configuration is static. I guess, too much magic automation on top of this is not the best thing for opsec, including having some daemon that can disable your wireguard interface or reconfigure the network if it doesn't like something. You want your network configuration to be static and predictable, regardless of some temporary failures. Basic wireguard kernel primitives will give you that.
      - mynameisvlad 5y ago
        > You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0 So... You'd have to do work to properly blackhole traffic when wg0 goes down. However long it takes to reconnect, you still will automatically fall back down to ens0 while it's down unless you do something to stop that.
        midasuni 5y ago
        How does wg0 go down?
        megous 5y ago
        wg0 doesn't go down by itself. Packets are always delivered to wg interface as long as it is marked as 'UP' (or 'enabled', if 'UP' sounds to you like having anything to do with some kind of "connection") when your routing table directs them there. When they hit the wg interface when the other endpoint is unreachable for whatever reason, they are either dropped, or queued, or get ICMP unreachable response generated for them, depending on situation. This is done internally by wireguard.
        tertius 5y ago
        You have a route to stop that. You route 0.0.0.0/0 through wg0 and it doesn't matter if no traffic returns, it'll keep trying because that's the route that's been defined for wg0. If you wanted to not go through wg0 (whether it can reach the other wireguard peer or not) you'd have to remove the routes first.
- OJFord 5y ago
  A good (the best?) way to solve that is 'the new namespace solution' described at the bottom of the page here: https://www.wireguard.com/netns/ https://www.wireguard.com/netns/ In brief, you move your physical eth/wlan device to a new namespace, and create the wg device in that namespace but then move it to the init ns. By default (and without root) everything will use the init ns and only be able to reach the physical device via wg. If it's not active, nothing will even reach your NIC, nevermind the internet.
  - kortilla 5y ago
    +1 to this being the safest way. No physical nic for your traffic to fallback to. The downside is this isn’t supported by any GUIs that I know of so it’s a pretty miserable workflow for WiFi.

But Wireguard itself relies on an active internet connection, which needs to still be set up to not fall back on in case the wg connection deactivates.

midasuni 5y ago
> With wireguard since there is no "connection" to be maintained
- mynameisvlad 5y ago
  What does that even mean? Let's say you have a Wireguard configuration, wg0 which runs off ens0. If your wg0 connection dies, for whatever reason (let's say the remote server goes down), your computer falls back to ens0. What does "not having a connection to be maintained" change about this?
  - OJFord 5y ago
    GP's just taking issue with the word 'connection', it's fine, I think it's clear.
    - midasuni 5y ago
      It’s really not. If you have a route down your WireGuard interface, it’s not going to stop should the end point of that interface no longer be routable.
  - megous 5y ago
    Wireguard will keep contacting the remote server. You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0. Wireguard only has "connection" in a sense that it caches some runtime information about the peer's endpoint, but endpoint configuration is static. I guess, too much magic automation on top of this is not the best thing for opsec, including having some daemon that can disable your wireguard interface or reconfigure the network if it doesn't like something. You want your network configuration to be static and predictable, regardless of some temporary failures. Basic wireguard kernel primitives will give you that.
    - mynameisvlad 5y ago
      > You'd have to delete the wg0 interface or delete the default route for packets to go out via ens0 So... You'd have to do work to properly blackhole traffic when wg0 goes down. However long it takes to reconnect, you still will automatically fall back down to ens0 while it's down unless you do something to stop that.
      - midasuni 5y ago
        How does wg0 go down?
      - megous 5y ago
        wg0 doesn't go down by itself. Packets are always delivered to wg interface as long as it is marked as 'UP' (or 'enabled', if 'UP' sounds to you like having anything to do with some kind of "connection") when your routing table directs them there. When they hit the wg interface when the other endpoint is unreachable for whatever reason, they are either dropped, or queued, or get ICMP unreachable response generated for them, depending on situation. This is done internally by wireguard.
      - tertius 5y ago
        You have a route to stop that. You route 0.0.0.0/0 through wg0 and it doesn't matter if no traffic returns, it'll keep trying because that's the route that's been defined for wg0. If you wanted to not go through wg0 (whether it can reach the other wireguard peer or not) you'd have to remove the routes first.
OJFord 5y ago
A good (the best?) way to solve that is 'the new namespace solution' described at the bottom of the page here: https://www.wireguard.com/netns/ https://www.wireguard.com/netns/ In brief, you move your physical eth/wlan device to a new namespace, and create the wg device in that namespace but then move it to the init ns. By default (and without root) everything will use the init ns and only be able to reach the physical device via wg. If it's not active, nothing will even reach your NIC, nevermind the internet.
- kortilla 5y ago
  +1 to this being the safest way. No physical nic for your traffic to fallback to. The downside is this isn’t supported by any GUIs that I know of so it’s a pretty miserable workflow for WiFi.