Discussion:
ipfilter: keep state per-interface?
(too old to reply)
Timo Buhrmester
2016-12-26 18:56:25 UTC
Permalink
Hi,

suppose you have a router with two interfaces:
- vr0, behind which is 192.168.0.0/24, and
- vr1, behind which is 192.168.1.0/24

and a (testcase) ipf.conf like this:
block in quick on vr0 all
block out quick on vr0 all
pass in quick on vr1 family inet proto udp from any to any keep state

I noticed that UDP datagrams ingressing on vr1 do get routed out on vr0,
the 'block out on vr0 all' rule notwithstanding.

I assume that is because I keep state on the packets when they arrive
on vr1.

Is this a bug, or is it working as designed? For some reason, I
assumed there to be per-interface state tables and hence consideration
of the vr0 rules (i.e. I assumed a 'keep state' on a vr1 rule would only
skip looking at the vr1 rules for future matching packets)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Egerváry Gergely
2016-12-26 20:05:49 UTC
Permalink
Hi,
Post by Timo Buhrmester
I assume that is because I keep state on the packets when they
arrive on vr1.
You are right - state table has precedence over filter rules.
Post by Timo Buhrmester
Is this a bug, or is it working as designed? For some reason, I
assumed there to be per-interface state tables and hence
consideration of the vr0 rules (i.e. I assumed a 'keep state' on a
vr1 rule would only> skip looking at the vr1 rules for future
matching packets)
It's by design. There's only one state table.

--
Gergely EGERVARY

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Egerváry Gergely
2016-12-26 20:19:24 UTC
Permalink
Post by Egerváry Gergely
Post by Timo Buhrmester
Is this a bug, or is it working as designed? For some reason, I
assumed there to be per-interface state tables and hence
consideration of the vr0 rules (i.e. I assumed a 'keep state' on a
vr1 rule would only> skip looking at the vr1 rules for future
matching packets)
It's by design. There's only one state table.
FYI: from NetBSD's NPF `man 5 npf.conf'

| Stateful packet inspection is enabled using `stateful' or
| `stateful-ends' keywords. The former creates a state which is
| uniquely identified by a 5-tuple (source and destination IP
| addresses, port numbers and an interface identifier). The latter
| excludes the interface identifier and must be used with precaution.
--
Gergely EGERVARY

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Timo Buhrmester
2016-12-27 18:20:42 UTC
Permalink
Post by Egerváry Gergely
FYI: from NetBSD's NPF `man 5 npf.conf'
| Stateful packet inspection is enabled using `stateful' or
| `stateful-ends' keywords. The former creates a state which is
| uniquely identified by a 5-tuple (source and destination IP
| addresses, port numbers and an interface identifier). The latter
| excludes the interface identifier and must be used with precaution.
Thanks! I guess I'll use it as an excuse to learn some npf :-)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Egerváry Gergely
2016-12-27 19:20:32 UTC
Permalink
Post by Timo Buhrmester
Post by Egerváry Gergely
| Stateful packet inspection is enabled using `stateful' or
| `stateful-ends' keywords. The former creates a state which is
| uniquely identified by a 5-tuple (source and destination IP
| addresses, port numbers and an interface identifier). The latter
| excludes the interface identifier and must be used with precaution.
Thanks! I guess I'll use it as an excuse to learn some npf :-)
BTW, matching on a state table entry and sending response are two
different stories.

Your packet comes in on vr1. There's a state table match based on
the source ip/port, destination ip/port and the interface. Sounds good?

Okay, then let's pass outgoing packet... on which interface? Routing
says: on vr0.

`stateful-ends` should be great for dynamic routing, when the incoming
interface can change on the fly (BGP, etc.) but I'm not sure it has
anything to do with the outgoing interface.

--
Gergely EGERVARY


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...