It works now! Thanks!

In testing:
https://github.com/vyos/vyos-1x/compare/current...jestabro:interface-names
https://github.com/vyos/vyatta-cfg/compare/current...jestabro:interface-names
The following removes legacy code: vyatta_net_name, vyatta_interface_rescan, XorpConfigParser
https://github.com/vyos/vyatta-cfg-system/compare/current...jestabro:interface-names

@danielpo Will be fixed in the next rolling release.

PR https://github.com/vyos/vyos-1x/pull/1016
Change priority for nat66

By the way, the SNMPD service of the router will not restart automatically. After the SNMP service is attacked, the SNMP service cannot be restored even if the device is restarted, which may be an inappropriate implementation.

I have a question. If you confirm the existence of the vulnerability, can you report to the NET-SNMP vendor and apply for a CVE number?

I have sent the POC of the vulnerability to [email protected].

By the way, The password of the compressed package is HGkasjgJFYL261.

Hello, I have found three vulnerabilities in V1.2.7, one of which can also be reproduced in V1.3, please continue to check the other versions, I will send all three POCs to your email, thank you for your work.

Adding a few notes here:

• The ideal behavior probably depends on which PKI elements are changed and what services depend on them.
• E.g. OpenVPN does not require a server restart for a CRL change (see https://openvpn.net/community-resources/controlling-a-running-openvpn-process/), but changing the CA or server cert/key would require a restart.
• It seems like there are some swanctrl commands that can conditionally reload parts of the config too without taking all tunnels down
• The former might be useful if you need to renew server certs or something like that and want to do so with the minimal impact

@c-po The mentioned completion help stating is wrong then as it says at the specified path.

Related to T3863 and could also be a XML priority issue as NAT66 has a higher priority then e.g. the tunnel interface

@zoenan7 Thanks for your research! You can send the PoC to [email protected]

The command mentions that the file is saved to: /opt/vyatta/etc/config/support/file.vyos.tech-support-archive.2021-09-25-150643.tgz thus ls from the home directory will not reveal a file.

The next rolling will also have support for the set protocols bgp neighbor fe80::202 interface source-interface 'eth1' CLI command

Actually the VyOS syntax is a bit different - you do not need to establish a "relationship" with a link-local address - multiple links could indeed share the same link local address causing conflicts and non-uniqueness in the config.

Bug still present.

Additional logs:

Sep 24 12:32:23 r1-roll systemd[1]: Starting NDP Proxy Daemon...
Sep 24 12:32:23 r1-roll ndppd[2150]: (notice) ndppd (NDP Proxy Daemon) version 0.2.4
Sep 24 12:32:23 r1-roll ndppd[2150]: (notice) Using configuration file '/run/ndppd/ndppd.conf'
Sep 24 12:32:23 r1-roll ndppd[2150]: (warning) Low prefix length (80 <= 120) when using 'static' method
Sep 24 12:32:23 r1-roll ndppd[2150]: (warning) Low prefix length (80 <= 120) when using 'static' method
Sep 24 12:32:23 r1-roll systemd[1]: ndppd.service: Can't open PID file /run/ndppd/ndppd.pid (yet?) after start: Operation not permitted
Sep 24 12:32:23 r1-roll kernel: [  131.465473] NET: Registered protocol family 17
Sep 24 12:32:23 r1-roll isisd[1006]: circuit already connected

Thanks!

https://github.com/vyos/vyos-1x/commit/514da738173696c70440c959b9d7ec9afd77fbae

https://github.com/vyos/vyos-1x/commit/688f9810fde3947db66ff7e4c0ea21bf9708feec

I have created a PR for the bugs that I found above. I hope that is is acceptable to solve these within this ticket:
https://github.com/vyos/vyos-1x/pull/1014

I think I found my problem. I haven't known the difference between PKCS#1 and PKCS#8.
If I give the key in PKCS#8 format I can finally commit the changes without problems.

Hey everyone,