$ show ssh fingerprints SSH server public key fingerprints:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Oct 13 2023
OpenVPN cannot pass the smoketest
DEBUG - ====================================================================== DEBUG - FAIL: test_openvpn_options (__main__.TestInterfacesOpenVPN.test_openvpn_options) DEBUG - ---------------------------------------------------------------------- DEBUG - Traceback (most recent call last): DEBUG - File "/usr/libexec/vyos/tests/smoke/cli/test_interfaces_openvpn.py", line 525, in test_openvpn_options DEBUG - self.assertNotEqual(cur_pid, new_pid) DEBUG - AssertionError: None == None DEBUG - DEBUG - ====================================================================== DEBUG - FAIL: test_openvpn_site2site_interfaces_tun (__main__.TestInterfacesOpenVPN.test_openvpn_site2site_interfaces_tun) DEBUG - ---------------------------------------------------------------------- DEBUG - Traceback (most recent call last): DEBUG - File "/usr/libexec/vyos/tests/smoke/cli/test_interfaces_openvpn.py", line 601, in test_openvpn_site2site_interfaces_tun DEBUG - self.assertTrue(process_named_running(PROCESS_NAME)) DEBUG - AssertionError: None is not true
I had a similar issue going from 1.5-rolling-202309250022 to 1.5-rolling-202310090023.
Oct 12 2023
Then this task can be set to closed and invalid :-)
PR updated: https://github.com/vyos/vyos-build/pull/435
If you don't use the firewall (statefully at least) then it will go through the FW_CONNTRACK chain and the NAT_CONNTRACK and/or WLB_CONNTRACK chains will be reached, or fall through to the notrack.
But the NAT_CONNTRACK and WLB_CONNTRACK chains are never evaluted because FW_CONNTRACK always set action to accept?
This should fix the problem: https://github.com/vyos/vyos-1x/pull/2361
That is how the conntrack enabling system works. FW_CONNTRACK verdict is set to accept when it is determined the firewall needs conntracking (state rules, flowtable etc.), same for NAT_/WLB_ chains. If none require conntrack - all chains will be return and it falls down the chain to the final notrack and conntrack is not enabled.
An additional "nice to have" would be a hook that runs on route state change.
Examples:
set protocols failover route 0.0.0.0/0 next-hop 100.100.100.1 hook '/config/scripts/failover-hook-100.100.100.1'
Oct 11 2023
Oct 10 2023
show conntrack statistics shows only sudo conntrack -S command
This won't show any logs
In T5497#161764, @Apachez wrote:I assume this will end up in config mode aswell before this task can be set to resolved?
Simply because this is a few more steps:
- Use the command
- Copy the output
- Delete current firewall
- Paste command output
- Commit
than this:
- Use the command
- Commit
I assume this will end up in config mode aswell before this task can be set to resolved?
Once PR https://github.com/vyos/vyos-1x/pull/2344 is merged, counters and logs for default action should be available once again.
It's an op-mode command, so it does not changes configuration. User may get something different from what he expected, so at least on this very first attempt of re-generating and re-ordering firewall rules, it's done in op-mode command with no impact on running configuration.
The syntax seems to have changed from "produce" to "generate" during this task?
Updated scan performed on VyOS 1.5-rolling-202310090023 (see attached file).
show conntrack statistics still fails in VyOS 1.5-rolling-202310090023:
Seems to be fixed in VyOS 1.5-rolling-202310090023:
Problem remains with "N/D" is being used in show firewall groups instead of "None".
Verified in VyOS 1.5-rolling-202310090023:
Verified in VyOS 1.5-rolling-202310090023:
Works as expected:
Oct 9 2023
Final testing before PR, the following corrects behavior when configuring the http-api using the http-api, for example:
PR created: https://github.com/vyos/vyos-build/pull/435
Oct 8 2023
As @twan mentioned previously...
Turns out that packages/linux-kernel/arch/x86/configs/vyos_defconfig doesnt include xz as option for initrd:
Will attempt to:
I see, looks like a way more streamlined approach. Thank you for the information and the quick response!
A new firewall frontend engine was implemented in VyOS 1.4-rolling-202308040557.
Good to hear that this was implemented, thank you! Could you elaborate in which release this feature will be available?
In T5635#161656, @freebsdjlu wrote:I think it depends on nftables , https://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation#Matching_by_socket_UID_.2F_GID , it is first handled by nftables and mark , then use rule .
PR created: https://github.com/vyos/vyos-1x/pull/2349
PR for 1.3 https://github.com/vyos/vyos-1x/pull/2348
PR for 1.3 https://github.com/vyos/vyos-1x/pull/2347
I think it depends on nftables , https://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation#Matching_by_socket_UID_.2F_GID , it is first handled by nftables and mark , then use rule .
PR for 1.4 https://github.com/vyos/vyos-1x/pull/2346
Oct 7 2023
Oct 6 2023
The blog over at claims:
Closing this one, because it's already implemented