@daryll-swer For your use case, you can use your tables/chains (not standard names like RAW/MANGLE INPUT/OUTPUT etc.), that won't be cleared by the VyOS firewall CLI
nft add table MYRAW
nft -- add chain ip MYRAW my_chain '{ type filter hook prerouting priority raw; policy accept; }'
nft add rule ip MYRAW my_chain ip saddr 192.0.2.5 counter dropAn example of dict that we can use
{
"images": {
"rolling": {
"latest": {
"arch": "amd64",
"flavors": ["azure"],
"image": "vyos-rolling-latest.iso",
"latest": True,
"lts": False,
"release_date": "2022-09-02",
"release_train": "sagitta",
"version": "1.4-rolling-202209020217"
},
"1.4-rolling-202209020217": {
"arch": "amd64",
"flavors": ["generic"],
"image": "vyos-1.4-rolling-202209020217-amd64.iso",
"latest": True,
"lts": False,
"release_date": "2022-09-02",
"release_train": "sagitta",
"version": "1.4-rolling-202209020217"
},
"1.4-rolling-202208291850": {
"arch": "amd64",
"flavors": ["openstack"],
"image": "vyos-1.4-rolling-202208291850-amd64.iso",
"latest": False,
"lts": False,
"release_date": "2022-08-29",
"release_train": "sagitta",
"version": "1.4-rolling-20220829850"
}
},
"lts": {
"latest": {
"arch": "amd64",
"flavors": ["generic"],
"image": "vyos-1.3-x.iso",
"latest": True,
"lts": True,
"release_date": "2022-xx-xx",
"release_train": "equuleus",
"version": "1.3-stable-202208230511"
}
}
}
}Could be a part of T4118
1.3 is not affected by this bug
A similar task T3541 I'll leave a link here
Maybe I'm wrong, I see it as some small API (on some hosts) without links to the images but with information about images (in JSON).
We compare our local VyOS version and the version that we get from API, if diff => true send a message to the "wall"
Smoketest can't pass policy route
Fix https://github.com/vyos/vyos-1x/pull/1512
Required version for offload hardware flag nftables 0.9.9
The current version we use 0.9.8-3.1
I have NAT working with vrf in VyOS 1.4-rolling-202208290458 + custom nat offload
set interfaces ethernet eth0 address '192.168.122.14/24' set interfaces ethernet eth1 address '192.0.2.1/24' set interfaces ethernet eth1 vrf 'foo' set protocols static route 192.0.2.0/24 interface eth1 vrf 'foo' set system conntrack set vrf name foo protocols static route 0.0.0.0/0 next-hop 192.168.122.1 interface 'eth0' set vrf name foo protocols static route 0.0.0.0/0 next-hop 192.168.122.1 vrf 'default' set vrf name foo table '1010'
The same for VyOS 1.4-rolling-202208290458
vyos@r14# set interfaces ethernet eth0 offload gro [edit] vyos@r14# commit
PR for 1.3 https://github.com/vyos/vyos-1x/pull/1504
This bug was in T4241, client couldn't connect to openconnect server and logs from the server site like:
Feb 16 19:46:03 r4 ocserv[2409]: main:192.168.122.1:44480 user disconnected (reason: unspecified, rx: 0, tx: 0) Feb 16 19:46:03 r4 ocserv[2409]: main:192.168.122.1:44482 user disconnected (reason: unspecified, rx: 0, tx: 0) ^C
It was tested with self-signed certificates.
@syncer It is affected also and 1.3
It should be a warning if we delete an interface (IP address of Interface) that belongs to some service.
In T4533#126598, @c-po wrote:In T4533#126578, @Viacheslav wrote:It is operator level, that shouldn’t have permission for configurations. Only basic diagnostics (op-mode)
Operator mode is no longer supported in VyOS 1.4
Even if so - we should still try to "support" it somehow for the upcoming future when there is a true secure op-mode again.
Could you please add a new Cmnd_Alias vor VRF to /etc/sudoers.d/vyos and allow it for the %operator group?
ip vrf exec requires the CAP_SYS_ADMIN capability which somehow is more or less equal to root.
It seems working:
● telegraf.service - The plugin-driven server agent for reporting metrics into InfluxDB
Loaded: loaded (/lib/systemd/system/telegraf.service; disabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/telegraf.service.d
└─10-override.conf
Active: active (running) since Mon 2022-08-29 12:51:47 EEST; 1min 7s ago
Docs: https://github.com/influxdata/telegraf
Main PID: 6740 (telegraf)
Tasks: 9 (limit: 9409)
Memory: 49.7M
CPU: 836ms
CGroup: /system.slice/telegraf.service
└─vrf
└─foo
└─6740 /usr/bin/telegraf --config /run/telegraf/telegraf.conf --config-directory /etc/telegraf/telegraf.d --pidfile /run/telegraf/telegraf.pidIn T2044#129750, @egoistdream wrote:Hi,
Same issue on VyOS 1.4-rolling-202208240217
And when you set the rpki ips you have wrong description on the options, instead of the "rpki server ip" you have "NTP server"
router# set protocols rpki cache ?
Possible completions:
> <x.x.x.x> IP address of NTP server
> <h:h:h:h:h:h:h:h> IPv6 address of NTP server
> <hostname> Fully qualified domain name of NTP server
In the 1.4 nat translations were rewritten, but I didn't delete the old python code yet https://github.com/vyos/vyos-1x/pull/1501
Before fix:
06:04:21 DEBUG - FAIL: test_pki_misc (__main__.TestConfigPkiMisc) 06:04:21 DEBUG - ---------------------------------------------------------------------- 06:04:21 DEBUG - Traceback (most recent call last): 06:04:21 DEBUG - File "/usr/bin/vyos-configtest", line 50, in test_config_load 06:04:21 DEBUG - self.session.commit() 06:04:21 DEBUG - vyos.configsession.ConfigSessionError: [[service https]] failed 06:04:21 DEBUG - Commit failed 06:04:21 DEBUG - 06:04:21 DEBUG - 06:04:21 DEBUG - During handling of the above exception, another exception occurred: 06:04:21 DEBUG - 06:04:21 DEBUG - Traceback (most recent call last): 06:04:21 DEBUG - File "/usr/bin/vyos-configtest", line 53, in test_config_load 06:04:21 DEBUG - self.fail() 06:04:21 DEBUG - AssertionError: None
After fix:
vyos@r14:~$ /usr/bin/vyos-configtest Generating tests ... completed: 0.000608 test_pki_misc (__main__.TestConfigPkiMisc) ... time: 16.943 ok