> > Google's likely to deprecate their non-BGP + IPsec tunnels soon so > > now I finally need to learn BGP and pick a proper daemon. > > I don't know what that is, or why BGP and IPsec and Google go together > at all. Are you doing some kind of BGP-TE or BGP-MPLS distribution > system? Google *prefers*¹ that you exchange routes between two site to site VPNs using BGP, especially in an HA (not here) setup. I'm not sure how long they'll continue supporting their “classic” VPN, so I might as well just use this now. Not entirely sure how I feel about them only supporting AES-GCM though². Also, my auditors will be asking less annoying questions if I use a hosted service for the VPN than if I run my own, which wouldn't normally be a big deal. > > Between Quagga, FRRouting, and BIRD, does anybody have a recommendation > > of what to run? And yes, the little details you think only you would > > care about and are overly specific do matter. > > FRRrouting is new name for Quagga, so that elimininates Quagga from the list. OK, so I take it that Quagga is comparitively dead or under-audited/developed/whatever and that it doesn't have any extra stability or value? > BIRD is very nice for advertising a stub network, and while it can be used > as a general daemon, it tends to be less feature-full. I.e. more focused on > BGP and not other stuff. No problem. BIRD it is unless you tell me it's unreliable, the man pages are terrible, the CLI worse, and that it's undebuggable. Yes, it's for a stub network. GCP already had example docs that used BIRD⁴, but I wasn't going to completely rely on those to be sufficiently strongly opinionated. > > Other than that, I'll have to deal with the usual, “why don't you > > just OpenVPN” questions, ugh. I just hope they won't cite the 50-75% > > meaningless, naive, or factually incorrect answers I preemptively > > found on StackExchange. > > I also have no idea how this relates to anything else. You wouldn't > use OpenVPN because your peer isn't using it. There's a 50/50 chance a non-auditor still going to ask me why I didn't just spin up an instance, run OpenVPN on it, and route manually. I wish I was kidding. That's also ignoring that you can trivially a better VPN over TCP than OpenVPN with OpenSSH, and surprisingly, do it with an HSM (c.f., sshd_config(8) § HostKeyAgent) and keep your auditors a bit happier about key control. It wouldn't matter terribly for control traffic³, but I'd think IPsec would just be more robust… and tested. Before netdev0.1, I tried OpenVPN. I wasn't terribly impressed, I wish there was better privsep, and one less thing running OpenSSL is fine by me. > If you weren't going to use IPsec, then you'd use wireguard. Which we know your opinion of. I've been tiptoeing around that one for a while. Alex ¹: https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview#classic-vpn ²: https://cloud.google.com/network-connectivity/docs/vpn/concepts/supported-ike-ciphers ³: Until somebody starts pushing whole docker images and volumes/datasets. ⁴: https://cloud.google.com/community/tutorials/using-cloud-vpn-with-strongswan#configuration_of_strongswan_2 and yes, I see the use of “which”, bashisms, unnecessary braces, VTI, etc. -- Manage your subscription: https://lists.linux-ottawa.org/sigs-l3go/listinfo.html