openwrt / openwrt/firewall4

Use of both `src_ip` and `ipset` in a rule is unclear

Open
#48 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
ucode
Stars
27
Forks
37
PR merge metrics
No merged PRs in 30d

Description

If I create a rule:

config rule
	option name 'Brians PC and server to OPC network for SSH'
	option proto 'tcp'
	option dest 'opc_network'
	option src 'lan'
	list src_ip 'fd31:aeb1:48df:0:3b14:e643:83d8:7017'
	list src_ip '2001:123:4567:0:90cc:a629:cf42:5877'
	list src_ip '10.75.22.247'
	list src_ip 'fd31:aeb1:48df::2'
	list src_ip '2001:0123:4567::2'
	option dest_port '22'
	option target 'ACCEPT'
	option ipset 'Brians-trusted-hosts'

I end up with an NFTables rule of:

ip saddr 10.75.22.247 tcp dport 22 ether saddr @Brians-trusted-hosts counter packets 0 bytes 0 jump accept_to_opc_network

It's unclear to me with any certainty whether that's an or or an and in NFTables, but my testing of that rule appears to make me believe it's an and because the rule does not match when either of 10.75.22.247 @Brians-trusted-hosts try to ssh to the destination. Remove the ipset from the rule and it will match when 10.75.22.247 tries to ssh to the destination.

The results of this mixing of ip_src and the ipset are ambiguous at best and surprising at worst. I have not come across any OpenWRT and/or firewall4 documentation that indicates the result of such a combination.

My feeling is that given that you can list multiple src_ips as an or'd list that adding a (i.e. source mac) ipset should also be an or and result in:

ether saddr @Brians-trusted-hosts tcp dport 22 counter packets 1 bytes 80 jump accept_to_opc_network # handle 40125
ip saddr 10.75.22.247 tcp dport 22 counter packets 1 bytes 60 jump accept_to_opc_network # handle 40124

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source file or test is named in the issue. Reproduce the shown nftables rule with both src_ip and ipset, then trace the rule-generation entry point and compare it with the separate rules proposed; done means the matching semantics are unambiguous and the reported SSH cases behave accordingly.

Written by the indexing model from the issue text.

Assessment

Domain
networking, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.