User Details
- User Since
- Sep 7 2017, 9:49 PM (377 w, 4 d)
Feb 26 2024
On 1.4.0-epa1, there is no longer an indication that configuration file actually has been saved.
Oct 18 2023
vyos logs
Oct 18 14:16:41 sshd[24197]: pam_succeed_if(sshd:auth): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 sshd[24197]: pam_succeed_if(sshd:account): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 sshd[24197]: Accepted password for olofl from 10.6.10.89 port 47110 ssh2 Oct 18 14:16:41 sshd[24197]: pam_succeed_if(sshd:session): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 sshd[24197]: pam_unix(sshd:session): session opened for user olofl(uid=1001) by (uid=0) Oct 18 14:16:41 systemd[1]: Created slice user-1001.slice - User Slice of UID 1001. Oct 18 14:16:41 systemd[1]: Starting user-runtime-dir@1001.service - User Runtime Directory /run/user/1001... Oct 18 14:16:41 systemd-logind[1259]: New session 129 of user olofl. Oct 18 14:16:41 systemd[1]: Finished user-runtime-dir@1001.service - User Runtime Directory /run/user/1001. Oct 18 14:16:41 systemd[1]: Starting user@1001.service - User Manager for UID 1001... Oct 18 14:16:41 (systemd)[24203]: pam_succeed_if(systemd-user:account): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 (systemd)[24203]: pam_succeed_if(systemd-user:session): requirement "service = sudo" not met by user "olofl" Oct 18 14:16:41 (systemd)[24203]: pam_unix(systemd-user:session): session opened for user olofl(uid=1001) by (uid=0) Oct 18 14:16:41 rsyslogd[11051]: message repeated 69 times: [-- MARK --] Oct 18 14:16:41 rsyslogd[11051]: child process (pid 24200) exited with status 1 [v8.2302.0] Oct 18 14:16:41 systemd[24203]: Queued start job for default target default.target. Oct 18 14:16:41 systemd[24203]: Reached target paths.target - Paths. Oct 18 14:16:41 systemd[24203]: Reached target sockets.target - Sockets. Oct 18 14:16:41 systemd[24203]: Reached target timers.target - Timers. Oct 18 14:16:41 systemd[24203]: Reached target basic.target - Basic System. Oct 18 14:16:41 systemd[24203]: Reached target default.target - Main User Target. Oct 18 14:16:41 systemd[24203]: Startup finished in 64ms. Oct 18 14:16:41 systemd[1]: Started user@1001.service - User Manager for UID 1001. Oct 18 14:16:41 systemd[1]: Started session-129.scope - Session 129 of User olofl. Oct 18 14:16:41 systemd[1]: opt-vyatta-config-tmp-new_config_24226.mount: Deactivated successfully. Oct 18 14:16:41 sshd[24197]: pam_env(sshd:session): deprecated reading of user environment enabled
testing another radius user
Oct 18 14:19:32 sshd[24610]: pam_succeed_if(sshd:auth): requirement "service = sudo" not met by user "oxidized" Oct 18 14:19:32 sshd[24610]: pam_succeed_if(sshd:account): requirement "service = sudo" not met by user "oxidized" Oct 18 14:19:32 sshd[24610]: Accepted password for oxidized from 10.6.10.89 port 58054 ssh2 Oct 18 14:19:32 sshd[24610]: pam_succeed_if(sshd:session): requirement "service = sudo" not met by user "oxidized" Oct 18 14:19:32 sshd[24610]: pam_unix(sshd:session): session opened for user oxidized(uid=1001) by (uid=0) Oct 18 14:19:32 systemd-logind[1259]: New session 132 of user olofl. Oct 18 14:19:32 systemd[1]: Started session-132.scope - Session 132 of User olofl. Oct 18 14:19:32 systemd[1]: opt-vyatta-config-tmp-new_config_24614.mount: Deactivated successfully. Oct 18 14:19:32 sshd[24610]: pam_env(sshd:session): deprecated reading of user environment enabled
My radius user was not called admin, but local user called admin was configured before I tried.
I removed local admin user, and tried once again, and I get the same reults.
Oct 17 2023
Mar 3 2022
1.3.0:
Still generating the same config
Feb 23 2022
If VyOS goes for Kea, it might be a better idea to invest time in Kea DHCPv6, as it has hook libraries which might resolve this task neater.
Feb 14 2022
Dec 29 2021
Nov 8 2021
Just want to know, did you try rfc3768-compatibility?
It probably works that way.
Unfortunately that breaks other parts of our setup.
Nov 3 2021
Im not sure its possible to delete the "le" part from vtysh cli? I tried running no ipv6 prefix-list PUBLIC-IPV6 seq 10 permit 2001:db8::/32 le 64 from vtysh, but it never removed le part.
Oct 26 2021
Aug 23 2021
More info:
@Viacheslav this ticket can be closed.
Jul 13 2021
May 12 2021
Yes the point of "longer-prefixes" is to find smaller routes within a bigger netmask, so if you're leaving out prefix, it doesn't make sense.
May 9 2021
May 4 2021
Apr 12 2021
@Viacheslav 1.2.7.
Apr 9 2021
Mar 29 2021
Mar 11 2021
just tested - 1.2.6-S1 - it is still working as described by ciprian.craciun
Mar 2 2021
ipsec policys, policy prefix-lists,
Mar 1 2021
I vote for option 1.
Feb 18 2021
I believe this is the behavior in 1.2.6 aswell?
And I think its not even possible to reset one peer?
So, reset vpn ipsec-peer XXX is broken
as well as reset vpn ipsec-peer XXX tunnel YYY
Sep 25 2020
I would also like to add that wouldn't it make more sense to set the protocol mode under host aswell rather behind "facility".
Sep 21 2020
Notice how my loopback interface with mask /32 does *not* show /32 in route table local.
@Viacheslav does that PR check for x.x.x.x/32 ? Because the ip route show table local does not contain the netmask /32. While ip route show table 254 actually shows the prefixes with /cidr notation.
Aug 26 2020
Is probably fixed in https://phabricator.vyos.net/T1291 according to cpo on slack
Aug 25 2020
Aug 17 2020
This is not solved in 1.2.6-epa1. Will this be solved in 1.2.6?
Jun 25 2020
Going to mention this in here:
Jun 24 2020
Jun 15 2020
This config was lost after first boot. Ping T2598
VyOS 1.2.3
When googling on the error given, T109 shows up where I had posted about this in 2018. I'm not sure it's related to this. Im not sure any configuration has been lost on reboot.
Feb 21 2020
Jan 7 2020
Nov 22 2019
From CPO on Slack:
Nov 21 2019
Nov 13 2019
Oct 10 2019
@hagbard via a route-map for example. set policy route-map TAG rule 10 set tag 33
Oct 4 2019
Any reason extcommunity-list and community-list doesnt support the same naming scheme?
Aug 12 2019
@Dmitry, thanks for reply.
May 3 2019
As per request from dmbaturin on slack:
May 2 2019
Nov 15 2018
Nov 13 2018
there's a problem when naming firewall network groups and port groups to the same name, and then later deleting one of them. Maybe thats related to this one.
this seem to be solved since moving to frr.
Jul 12 2018
Jul 10 2018
Thanks for pointing that out, I tested manually aswell again on both 1.1.7 and 1.1.5.
Nov 16 2017
Nov 7 2017
Nov 3 2017
I just ran a test on http://dev.packages.vyos.net/tmp/vyos-1.2.0-alpha-frr-test.iso
OSPF now works as intended in this particular setup. The ABR now sends LS Update type 3 into core.