set resource-group username-group <my-users> username user01 password '09078081' set resource-group username-group <my-users> username user02 password 'fmndskl82' set service pppoe-server authentication local-users username-group 'my-users' set vpn l2tp remote-access authentication local-users username-group 'my-users' set vpn sstp authentication local-users username-group 'my-users' set vpn openconnect authentication local-users username-group 'my-users'
Looks like what I was talking about
Need a general place to store accounts for VPN; whether it is a local radius server or chap-secrets file(this option seems simpler and more correct) is not so important.
A separate radius server is another point of failure and a separate infrastructure object. Wants to have a boxed solution where everything is available at once
Apple IOS now recognizes multiple CAs inside the profile
With this change all CAs in the list are rendered into the template.
In T6417#190336, @Viacheslav wrote:It is not clear why it should be ignored? If they should be ignored they must not be in the CLI at all.
Why not use RADIUS authentication for it?Do I get it wrong? Local RADIUS server seems like overhead here. Are we talking about the local “chap-secrets” file that can be reused by other daemons or RADIUS?
Clarify please the feature request.
Need a general place to store accounts for VPN; whether it is a local radius server or chap-secrets file(this option seems simpler and more correct) is not so important.
A separate radius server is another point of failure and a separate infrastructure object. Wants to have a boxed solution where everything is available at once
The similar task T6409
It is not clear why it should be ignored? If they should be ignored they must not be in the CLI at all.
Why not use RADIUS authentication for it?
Tested as working in: VyOS 1.5-rolling-202405280020
@mersl thanks for confirm.
In T6417#190277, @Viacheslav wrote:It probably cannot be a universal solution due to specific per-user options.
For example, for opencoonect, you can add otp if you want on a per-user basis and not do it for other users.vyos@r4# set vpn openconnect authentication local-users username foo Possible completions: disable Disable instance > otp 2FA OTP authentication parameters password Password used for authenticationAnother case specific client IP address or rate limit
vyos@r4# set vpn sstp authentication local-users username foo Possible completions: disable Disable instance password Password for authentication > rate-limit Upload/Download speed limits static-ip Static client IP address (default: *)Though it could be only for accel-ppp based configuration sstp/l2tp/pptp
specific per-user options can ignored if the protocol does not support them
just some show commands with test results on my lab
very cool! I just rebuild a 1.5-rolling and upgraded my lab router and voila - works as expected ;-)
It probably cannot be a universal solution due to specific per-user options.
For example, for opencoonect, you can add otp if you want on a per-user basis and not do it for other users.
vyos@r4# set vpn openconnect authentication local-users username foo Possible completions: disable Disable instance > otp 2FA OTP authentication parameters password Password used for authentication
we've added this ability to configure the topology on isis :
agree ,it's more a feature than a bug : PR https://github.com/vyos/vyos-1x/pull/3537
More a feature request than a bug
the problem here is that MT options is enable by default when the RIB has ipv4, if not not-MT is enable by default on IPv4 .So, you need to add additional topologies (ipv6-unicast , ipv6-multicast,etc)
@Viacheslav here you go:
Can you provide set of commands instead? Bug-report-guidelines
@ssasso - thanks for this good catch! Coming from a Junos world, I was a bit surprised at the first place when I enabled ISIS and found no ipv6 isis routes and no multi-topology config option (and yes - we have multi-topology in place)
The charon identifier also shows IKE name of the SA; this way, we can identify peers in the logs https://github.com/vyos/vyos-build/blob/b809886538eaad66b8756be8f5e758584f88e6a6/data/live-build-config/hooks/live/30-strongswan-configs.chroot#L41-L54
The current show log vpn does https://github.com/vyos/vyos-1x/blob/48e5266e2bca8d1d7a2ee4bacbe0e6628de3fa66/op-mode-definitions/show-log.xml.in#L710
tested new cli structure, it combine the new mach-group and old syntax :
PR opened: https://github.com/vyos/vyos-1x/pull/3532
The dependency allowed for 386/amd64 only https://github.com/vyos/vyos-build/blob/b809886538eaad66b8756be8f5e758584f88e6a6/docker/Dockerfile#L281
Though the package is available for ARM
As several CA were allowed some time ago it is a bug with op-mode generator.
There is a list of CA's https://github.com/vyos/vyos-1x/blob/48e5266e2bca8d1d7a2ee4bacbe0e6628de3fa66/src/op_mode/ikev2_profile_generator.py#L147
The template https://github.com/vyos/vyos-1x/blob/current/data/templates/ipsec/windows_profile.j2
I made a PR that uses an implementation with a separate function: https://github.com/vyos/vyatta-cfg/pull/79