Wondering if someone who understands the VPN universe well enough could help me out here. I’m looking at this article on IKEv2 w/ macOS 10.12 and wondering if this would be possible on VyOS Helium 1.1.7? I did not see anything that looked similar on the Proposed Enhancements page and could not find any information that looked relevant in the chat or forum history.
My desired use case would be that multiple users could log into the system and the system can slave off FreeIPA for credentials. FreeIPA can provide either LDAP, RADIUS or KRB5 authentication endpoints and can also generate and provide client certificates per user. Ideally, devices in the field could opportunistically encrypt.
I guess my first question is whether there is any way to do this at all (whether on Helium or later versions), but falling short of that, what are the missing pieces that others might imagine? It seems like an excellent opportunity to learn more about VPN on VyOS.
The document I referenced above uses StrongSwan, coincidentally so does VyOS.
Since the configuration is in the same place and there are headers on the generated configuration, I was able to find /opt/vyatta/sbin/vpn-config.pl and /opt/vyatta/sbin/dmvpn-config.pl. I don’t know what the ‘dm’ difference is yet. Those ‘generated by’ headers were great, thanks!
Perl isn’t my first language, but it’s not obfuscated so it’s pretty easy to search key words like ‘chap’ and ‘identity’ to see that the authentication can only come from files at this point.
What I didn’t find is a facility that will include static user configuration into the final configuration. This configuration would be invisible to the VyOS configuration and might even conflict if this user-provided static configuration was not written carefully, but would allow some kind of prototyping to follow. Does that kind of thing exist and I am not seeing it?
I understand the legacy attachment to TACACS+ and that Vyatta did this, but why would it be a good idea to follow that?
If it all needs to be written from scratch anyway, it seems like using straight LDAP or PAM would be more versatile and compatible with modern auth providers, for instance for storing and serving certificates. For instance here: [strongSwan] StrongSwan & Kerberos authentication?.
From a configuration perspective, my personal preference would be interested in a simple configuration builder that knew how to connect to a RedHat IPA server with a single line. This should be straightforward with SSSD. Of course that’s pretty specific tho.
I was able to make a login on Phabricator, but it was difficult to search issues on it, can’t order by date, for instance.
Well LDAP and other directories is another story.
TACACS+ kind of standard for networking devices,
a lot of people invested in that and it hard to ignore that
It may be academic, my Perl is really rusty. What I could see possibility for is that there was some way to do override configurations with includes, those would either merge or replace configuration that was generated at each boot. Then at least community members could demonstrate a POC. If it was presented well enough, a real VyOS developer could choose to take on the task, knowing that the configuration does not need to be debugged, it just needs the Perl.
It seems unrealistic for the community to submit modules in different languages. My main language is Scala, I don’t think you’d want to put any of that in the distribution. Even if it happened, there would eventually be this incredibly unmaintainable set of languages. What happens if there is a problem with my submission and I am nowhere to be found to fix it? Sticking with Perl makes sense for now.
What if the configuration builders could containerized with something like Docker? Maybe the configuration syntax was expanded with something like an XML namespace so VyOS could parse the configuration and use the “namespace” to pull the image from somewhere (if it hadn’t already been pulled), then hand off the configuration element to the downloaded container. Some kind of context would need to be handed in and the context would provide the ability to configure the aspects of the core router, like StrongSwan in this case.
I get that this is a potentially ugly security hole and Docker could add some heft to an otherwise lightweight system, but as a user, I would be okay with that if the ecosystem of containerized configurators started growing and I could do awesome stuff without harassing developers for it. For the part of the developers, I think they could look to this plugin ecosystem and quantitatively decide what features should be hand-coded in Perl by popularity.
