vyos-1x.git/src/conf_mode/firewall.py, branch rolling

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

firewall: T7112: Default action drop fails

2025-11-05T07:30:31+00:00

Prevent `KeyError` by safely handling missing 'member' dict in zone config. Add smoketest to verify commit fails gracefully when zone has no interfaces.

firewall: T7739: Default ruleset for firewall zones

2025-10-21T23:46:37+00:00

In large networks with many zones where simple allow/deny rules are not sufficient, zones become tedious to manage. Many use cases can be simplified by providing an ability to define a default ruleset for traffic from other zones. This change proposes adding the follwing syntax: set firewall zone default_firewall name set firewall zone default_firewall ipv6_name The proposed behavior is the following: local in: The default firewall ruleset for the local zone will be appended after all from configurations. local out: If a non-local zone does not have a from local ruleset but does have a default_firewall ruleset, the default_firewall ruleset will be appended using oifname forward: The default firewall ruleset for the zone will be appended after all from configurations To keep the behavior consistent with from ruleset configurations, a return is appended after the default_firewall ruleset. The proposed behavior differs slightly from the default_policy configuration for the local out chains. The default_policy applied in the out templates comes from the local zone, not the actual outbound zone. The proposed change does not amend this, but does make default_firewall logically consistent with the intent of the out rules.

Firewall: T7475: Disable conntrack per firewall chain

2025-09-05T20:37:19+00:00

- Added command to disable conntrack per firewall chain - Added test_disable_conntrack_per_chain function to smoketest