| 29 May 2021 |
 andi- | If you don't send data the interface does nothing. That is one of the design principles behind wireguard. | 19:39:46 |
 Roos | I wonder though, if you send packets but the interface can't relay them, how long does it keep them around? | 19:40:57 |
 hpfr | cool. I'm using this to remotely access some resources on my home network, is there a way to automatically disable it on my home network? I guess that's what a mesh vpn is for but nebula couldn't handle the cgnat I'm behind | 19:41:16 |
| Roos | In reply to @hpfr:matrix.org
cool. I'm using this to remotely access some resources on my home network, is there a way to automatically disable it on my home network? I guess that's what a mesh vpn is for but nebula couldn't handle the cgnat I'm behind You could share the ip space, route through your vpn to your home network subnet. | 19:42:07 |
| Roos | When you join the network, packets should pick the route without the extra hop. | 19:42:33 |
| hpfr | I think that's what I'm doing | 19:42:40 |
| andi- | Roos: IIRC it depends on the handshake state. If there was a handshake already it just sends it out. | 19:42:48 |
| andi- | Otherwise it tries to do the 0-rtt handshake first which is IIRC 2 packets (including 1 for the payload) | 19:43:10 |
| hpfr | if by share the IP space you mean putting my home network subnet in wg's allowedIPs | 19:43:07 |
| andi- | A trivial solution to that problem is: Have a high path metric for the VPN route. It will not use that unless you have that same subnet locally in another network. | 19:49:56 |
| Roos | In reply to @andi:kack.it
Roos: IIRC it depends on the handshake state. If there was a handshake already it just sends it out. Yes, but if connection was lost? (e.g. Plug was pulled) | 19:43:35 |
| Roos | In reply to @hpfr:matrix.org
if by share the IP space you mean putting my home network subnet in wg's allowedIPs Yes. | 19:43:59 |
| Roos | In reply to @roosemberth:orbstheorem.ch
Yes, but if connection was lost? (e.g. Plug was pulled) I'm asking because when you roam, no packets are lost. | 19:44:30 |
| Roos | So there must be a buffer somewhere. | 19:44:38 |
| hpfr | In reply to @roosemberth:orbstheorem.ch
When you join the network, packets should pick the route without the extra hop. how do the packets "know" about both routes? I would have thought putting a range in wg's allowedIPs sort of claims them | 19:55:35 |
| andi- | In reply to @roosemberth:orbstheorem.ch
I'm asking because when you roam, no packets are lost. It will just reconnect again with the next packet. | 19:57:57 |
| Roos | First matching route is used | 19:57:21 |
| andi- | Packets are authenticated via their keys and not their source addresses. If you send packets 50/50 from different source addresses that works just fine. You can expect to receive packets from the other side on both as well.. | 19:58:47 |
| Roos | I'm not sure the path metric is used by Linux though | 19:57:50 |
| Roos | But you can have multiple routing tables which will be sequentially scanned and matched, just like normal routes. | 19:58:43 |
|  delroth joined the room. | 20:00:03 |
| Roos | See `ip-rule` | 19:58:55 |
| Roos | I think there may be a confusion. There are two cases: you are connected to both your vpn and you home network and you are connected only to your home network | 20:00:15 |
| Roos | * I think there may be a confusion. There are two cases: you are connected to both your vpn and you home network and you are connected only to your vpn | 20:00:35 |
| Roos | If you're on your home network, you want packets not to use the wg interface.
If you are not connected to your home network you want packets to go through the wg interface. Correct? | 20:01:27 |
|  antifuchs joined the room. | 22:37:48 |
| antifuchs set a profile picture. | 22:49:05 |
| 30 May 2021 |
|  rizary_andika (@rizary_:matrix.org) (@rizary:matrix.org) joined the room. | 17:42:34 |
| 31 May 2021 |
|  [0x4A6F] changed their display name from [0x4A6F] to 0x4A6F. | 08:24:25 |
|  panic joined the room. | 17:54:25 |
