vyos-1x.git/src/conf_mode/firewall.py, branch nos-task-id

Merge pull request #5327 from BradKollmyer/T9076-remote-group-interval

2026-07-23T14:28:21+00:00

firewall: T9076: add per-remote-group update interval

utils: T9008: migrate remaining cmd() callers to cmdl() and remove cmd()

2026-07-17T16:10:08+00:00

Complete the safer-subprocess migration started by the cmdl()/ifconfig refactoring and convert every remaining vyos.utils.process.cmd() call site to the list-based cmdl(). Drop the vyos.utils.process.cmd() implementation as it is no longer in use.

firewall: T9076: add per-remote-group update interval

2026-07-10T23:31:18+00:00

Add 'set firewall group remote-group interval ' to control how often each remote group list is re-downloaded, independent of the global resolver-interval that also drives domain-group/FQDN resolution. The value accepts plain seconds or time-unit suffixes s/m/h/d/w (e.g. 4h), range 60 seconds to 4 weeks, enforced at commit time after conversion. When unset, the group keeps following 'firewall global-options resolver-interval', so existing configurations are unaffected. vyos-domain-resolver now tracks a last-update timestamp per remote group and sleeps until the next due update instead of a fixed resolver-interval tick, honoring per-group intervals both shorter and longer than the global one. A group is only stamped as updated after a successful download; failed downloads fall back to the cached list and are retried at the resolver cadence rather than after the full group interval. human_to_seconds() now treats a plain number as seconds instead of returning 0. Co-Authored-By: Claude Fable 5

firewall: T8761: re-introduce VRF interface names in generated firewall config

2026-07-01T19:51:21+00:00

This change re-implements the intended behaviour from T4180 aswell as from T4506, it ensures that both the vrf-member interface aswell as the vrf itself is added as an oifname -> meaning that traffic traversing and originating from withing VyOS is matches outbound. Changes done by c-po: * re-sort dependency list to keep diff low * vyos.configdict.is_vrf_changed() should return early and not carry over the to-be return value * keep common coding style (dict by . separation) in nftables-zone.j2 Co-authored-by: Christian Breunig

geoip: T5746: Add GeoIP ASN support

2026-06-04T14:18:29+00:00

geoip: T8590: fix initialization failure and set clobbering on boot and commit

2026-05-19T21:33:48+00:00

Three related bugs prevented GeoIP nftables sets from being populated correctly at boot and when incrementally modifying firewall or policy route rules. 1. geoip_updated() always returned False The previous implementation called node_changed() and then searched the result with dict_search_recursive(changes, 'geoip'). This could never match: node_changed() is annotated `-> list` and returns a flat list of the immediate top-level child names whose subtree changed (e.g. ['ipv4'] for the firewall path, or route names for policy route). The 'geoip' key sits several levels deeper than those names, so dict_search_recursive — which only walks dicts and lists for a matching dict key — never yielded a hit, and geoip_updated() always returned False. As a consequence, geoip_update() was never triggered by an incremental add or change of a GeoIP rule; the only path that ever populated /run/nftables-geoip.conf was the explicit \"update geoip\" command or the fallback when geoip_refresh() failed. Fix: bypass node_changed() and call get_config_diff() / get_child_nodes_diff() directly with expand_nodes=Diff.ADD|Diff.DELETE and recursive=True. In that mode, the 'add' and 'delete' values in the returned dict are full nested subtrees of the config diff, so dict_search_recursive correctly finds 'geoip' wherever it appears in the change set. 2. GeoIP block executed unconditionally, breaking the boot sequence geoip_sets() always returns {'name': [], 'ipv6_name': []}. A non-empty dict is truthy in Python regardless of whether its values are empty lists, so the guards \"if geoip_sets:\" and \"if 'name' in geoip_sets:\" were always True. On boot, when policy_route.py is invoked as a dependent of firewall.py (triggered by group_resync), it entered the GeoIP block even with no policy route GeoIP rules configured. Because /run/nftables-geoip.conf did not yet exist, geoip_refresh() returned False and geoip_update(policy=policy) was called with an empty policy. This created /run/nftables-geoip.conf containing only empty table stubs. When firewall.py subsequently called geoip_refresh(), the file existed and nft loaded it successfully — so the geoip_update(firewall) call was never reached and the firewall GeoIP sets stayed empty for the entire uptime of the router. Fix: check the actual list contents instead of the container dict: if geoip_sets['name'] or geoip_sets['ipv6_name']. 3. geoip_update() clobbered the other caller's sets geoip_update() renders /run/nftables-geoip.conf from both firewall_sets and policy_sets in a single pass. When called with only one argument (as firewall.py and policy_route.py each do), the other argument defaulted to None and that half of the file was rendered empty, erasing whatever the other script had written. The geoip-update helper used by \"update geoip\" and the weekly cron was unaffected because it always passes both arguments, which masked this bug in normal manual operation. Fix: when either argument is absent, read the missing config from the live Config session before building the set tables, so every invocation writes the complete combined firewall + policy file.

firewall: T8446: Prevent chain with offload rule on local zone

2026-03-31T21:09:09+00:00

* Add warning when defining `offload-target` without setting action to `offload`

geoip: T8049: Add MaxMind database support

2026-01-21T10:52:29+00:00

geoip: T7926: Refactor geoip handling

2026-01-21T10:52:29+00:00

* Move core logic to separate vyos.geoip module * Use a sqlite database for storing and querying address ranges by country * Remove downloaded geoip ranges once loaded into sqlite db * No longer rebuild geoip sets on each commit unless necessary * Allows for extensibility using other geoip data vendors

Merge pull request #4672 from apschultz/zone_default_firewall_ruleset

2025-11-24T19:48:07+00:00

firewall: T7739: Default ruleset for firewall zones