Setting it configurable will be a good solution.
Just like it is done in OpenVPN
vyos@r14# set interfaces openvpn vtun0 tls tls-version-min Possible completions: 1.0 TLS v1.0 1.1 TLS v1.1 1.2 TLS v1.2 1.3 TLS v1.3
Setting it configurable will be a good solution.
Just like it is done in OpenVPN
vyos@r14# set interfaces openvpn vtun0 tls tls-version-min Possible completions: 1.0 TLS v1.0 1.1 TLS v1.1 1.2 TLS v1.2 1.3 TLS v1.3
Maybe, we need to handle cron script differently if ping failed?
Please let me know what should be the direction for solving this issue.
We also need to increase opened file descriptors (ulimit -n) to listen limit + some margin.
And consider adding a warning about increasing net.core.optmem_max for systems with a limit of more than 100 peers.
It is a problem with mapping user to radius_priv_user
This problem began after https://github.com/vyos/vyos-1x/commit/765f84386b6e94984ff79db2eab36d51f759159b#diff-0ab0ed71ce757261c4a6ae2f3a5bc441d6257d477bfb5435ae38f230777ff81cR51
If I set in sshd_config
I'm not free now. I'll check it when I'm free
@Viacheslav unfortunately I am not too familiar with your build system, but basically you need to clone the ovpn-dco repository (https://github.com/OpenVPN/ovpn-dco.git) and compile it against your kernel, as you would normally do for any other out-of-tree kernel module.
PR for alternative completion helper. This provides the same args/output of the Python script, with a speedup of 1--2 orders of magnitude; testing needed.
https://github.com/vyos/vyos-utils/pull/11
I just confirmed that it's still reproducible in VyOS 1.4-rolling-202301241944. It seems that I cannot copy stanza to a new name instead of trying to rename it, either.
A basic implementation: https://github.com/vyos/vyos-1x/pull/1800
when an incompatible option is found, OpenVPN will simply disable DCO and go back to tun (this info will be logged). Therefore the limitations should not be a reason for not including DCO in VyOS.
PR for 1.3 which makes the change available for every config subsystem https://github.com/vyos/vyos-1x/pull/1798
In T3871#141847, @jestabro wrote:Before adopting the approach mentioned above, there was development of an alternative using pyudev within an 'interface-monitor' daemon; the following branches contain (a version of) the rebased code. It would need a few hours of attention to check the logic and add the is_persistent check from vyos-interface-rescan.py; it could use some refactoring as well.
https://github.com/vyos/vyos-1x/compare/current...jestabro:vyos-1x:interface-monitor
https://github.com/vyos/vyatta-cfg/compare/current...jestabro:vyatta-cfg:interface-monitor
https://github.com/vyos/vyos-build/compare/current...jestabro:vyos-build:interface-monitor
Before adopting the approach mentioned above, there was development of an alternative using pyudev within an 'interface-monitor' daemon; the following branches contain (a version of) the rebased code. It would need a few hours of attention to check the logic and add the is_persistent check from vyos-interface-rescan.py; it could use some refactoring as well.
### generated by accel_pppoe.py ### [modules] log_syslog pppoe shaper radius ippool auth_pap auth_chap_md5 auth_mschap_v1 auth_mschap_v2
@daniil Could you update the PR?
Could you send the full accel-ppp working configuration that you expect?
@Jimz Show please the file cat /config/dhcpd.leases
I cannot reproduce it even if no any leases
vyos@r14:~$ show dhcp server leases IP Address MAC address State Lease start Lease expiration Remaining Pool Hostname ------------ ------------- ------- ------------- ------------------ ----------- ------ ---------- vyos@r14:~$
The approach in commit ee02ca93 of vyos-1x was considered a reasonable workaround for all but a few corner cases. However, the issue pointed out in
PR for 1.3: https://github.com/vyos/vyos-1x/pull/1796
PR for 1.4: https://github.com/vyos/vyos-1x/pull/1795
pfsense implements it , however , they explain that it has some limitations :
There are some limitations
In particular, this is a list (may not be complete) of features that are not available when using ovpn-dco:
accel-ppp doesn't support FQDN for RADIUS https://docs.accel-ppp.org/en/latest/configuration/radius.html#radius
So it is impossible until it is available in the accep-ppp
PR for Equuleus:
https://github.com/vyos/vyos-build/pull/303
PR for Sagitta:
https://github.com/vyos/vyos-build/pull/301