Page MenuHomeVyOS Platform

Problem after commit with errors
Confirmed, LowPublicBUG

Description

Hi,

I have found problem with starting VyOS router after commiting wrong sequence of configuration set's.
This behavior occurs when we do the example configuration set's in GUI.
ex.
set firewall group network-group FW-OUT network '191.200.161.8/31'
set firewall group network-group FW-OUT network '191.200.161.8/32'

next "commit"

VyOS display an error message "set firewall group network-group FW-OUT network '191.200.161.8/31'
set firewall group network-group FW-OUT network '191.200.161.8/32' "

This is correct because 191.200.161.8/32 network is in a range 191.200.161.8/31, but when at this moment I run command "save" this configuration is written in config.boot file. So VyOS apply after commit wrong sets into memory and when I press "save" this configuration is written into config.boot file. Then this VyOS router doesn't start properly because it stops when is parsing configuration file (line by line) after find wrong network definition. In this case is only one problem resolution, after any warnings in commit command we need do command "commit discard" and apply correct set's with GUI then save this configuration. Could you explain this behavior?

Best regards
Krzysztof

Details

Difficulty level
Normal (likely a few hours)
Version
1.1.7
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Perfectly compatible

Event Timeline

syncer triaged this task as Low priority.
syncer changed the task status from Open to On hold.Oct 13 2018, 9:17 AM
syncer edited projects, added VyOS 1.2 Crux (VyOS 1.2.0-rc3); removed VyOS 1.1.x.
syncer added a subscriber: syncer.

requires testing against 1.2 rolling
please retest and provide findings

Hi,

The problem is still present.

//vyos@vyos:~$ configure
[edit]
vyos@vyos# set firewall group network-group FW-OUT network '191.200.161.8/31'
[edit]
vyos@vyos# set firewall group network-group FW-OUT network '191.200.161.8/32'
[edit]
vyos@vyos# commit
[ firewall group network-group FW-OUT ]
Error: member [191.200.161.8/32] already exists in [FW-OUT]

[edit]
vyos@vyos# commit
No configuration changes to commit
[edit]
vyos@vyos# exit//

After that all network-group is present in the active configuration file.

  • snip -----

// network-group FW-OUT {

    network 191.200.161.8/31
    network 191.200.161.8/32
}//
  • snip -----

I made tests on the last available version 1.2.0-rolling + 201812050337

Best regards
Krzysztof

HI,

In addition, when trying to delete these entries from the configuration

//vyos @ vyos: ~ $ configure
[Edit]
vyos @ vyos # delete firewall group network-group FW-OUT
[Edit]
vyos @ vyos # commit
[firewall group network-group FW-OUT]
Error: group [FW-OUT] does not exists

[Edit]//

After that the network-group FW-OUT is not present in the configuration file.

So there is a problem with validation

Bet regards
Krzysztof

syncer changed the task status from On hold to Needs testing.Feb 7 2019, 11:39 PM
syncer reassigned this task from dmbaturin to zsdc.
syncer added a subscriber: dmbaturin.
zsdc changed the task status from Needs testing to Confirmed.Feb 25 2019, 5:18 PM
zsdc reassigned this task from zsdc to dmbaturin.
zsdc added a subscriber: zsdc.

Confirmed in 1.2.0-rolling+201902250337.
I think we must allow adding overlapped networks/address into the same set, as ipset allows to do this. Maybe situations, where this will be necessary, are rare (for example, resizing network size defined in set), but there is no clear reason to deny such combinations.

Hi,

Confirmed it's still happening in VyOS 1.2.0 LTS

dmbaturin changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).Jan 27 2021, 6:47 PM
dmbaturin set Is it a breaking change? to Perfectly compatible.

I can confirm that the issue of accepting configurations that yield errors is present in the latest LTS (1.2.6) and latest rolling release (1.4-202101240218). However, I couldn't replicate the issue of the configuration parser breaking at startup. Do we want to prevent the user from committing erroneous input at the risk of annoying false positives?

erkin renamed this task from Problem after commit with erros to Problem after commit with errors.Jan 27 2021, 8:02 PM

It's better to let this problem be solved by the migration to pftables (per T3286) instead of try and a band-aid over this isolated issue.

erkin removed erkin as the assignee of this task.Feb 6 2021, 12:10 PM
erkin added a subscriber: erkin.