4 ms·
One of the pain points I’ve experienced with configuration of traditional VPNs is when devices physically connect to different parts of the network when staff t
by phil-martin 2y ago
One of the pain points I’ve experienced with configuration of traditional VPNs is when devices physically connect to different parts of the network when staff travel between home and different offices.
For a small example, when working from home, we want to connect to SMB shares over the vpn, with regular traffic going over the regular LAN interface of the computer. When the same person comes into the main office, just use the LAN. The simplest solution is to teach users to make sure they turn their VPN off when in the office, but that’s a super easy step to forget.
Could Firezone help managing these quality-of-life details for end users?
- jamilbk 2y agoThis is a fairly common scenario and one that we had in mind when building the NAT traversal implementation. The short answer is that you wouldn't need to sign out of Firezone when in the office -- the connection should hairpin off the nearest common router and go directly to the SMB share in this case.
- redrove 2y agoThis single handedly convinced me to try it out in my homelab! Tailscale fails at this and I consider it fairly basic networking.
- jamilbk 2y agoYou can read more about how we came up with the current implementation here: https://github.com/firezone/firezone/issues/3553 https://github.com/firezone/firezone/issues/3553 We didn't invent these techniques. Host candidates are part of standard ICE: https://datatracker.ietf.org/doc/html/rfc8445#section-5.1.1.1 https://datatracker.ietf.org/doc/html/rfc8445#section-5.1.1....