IPFW: more "orthogonal? state operations, push into 11?
Julian Elischer
julian at freebsd.org
Fri Aug 5 04:37:08 UTC 2016
On 5/08/2016 2:14 AM, Ian Smith wrote:
> On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote:
> > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote:
> > > On 04.08.16 06:42, Julian Elischer wrote:
> > > > so it's a combination of #1 and #2 in my list. I think I originally
> > > > thought of having just #1.
> > > >
> > > > A combination is less useful for me as you need to do:
> > > >
> > > > 20 skipto 400 tcp from table(2) to me setup record-state
> > > > 21 skipto 400 tcp from table(2) to me setup
> > > > to make the entire session do the same thing.
>
> > > So, in your example what wrong with just using keep-state?
> > > "record-state without immediate action" == "keep-state without implicit
> > > check-state" needed to solve issues with NAT or something similar, that
> > > was described by Lev.
> > >
>
> > because keep-state is a check-state for ALL packets going past, regardless of
> > whether they match the pattern.
> >
> > at least that's what I have observed.
>
> Except now(?) with named states/flows/whatever, isn't it the case that
> check-state [flowname] only affects packets with same state/flowname? So
> you can clearly separate, say, packets on different interfaces, packets
> coming or going on any interface, and such?
>
> If I'm understanding that right - quite possibly not! - then only those
> packets will match, and others with other names (including 'default')
> won't match states with that name. I'm not sure I'm expressing this at
> all well, because I'm only just starting to get any sort of grip, but
> I'm liking the idea and wondering if it's sufficient for starters.
wellll not quite..
Only the given state table will be looked at, but all packets will
still be matched with it.
>
> To me, orthogonality implies the least number of commands/instructions
> that will accomplish the desired functionality. First, let's find out
> what can and cannot be accomplished with named states/flows .. I'm yet
> to understand what record-state-without-action can accomplish apart from
> that .. it could work only for the first packet I suppose, since once
> state is established, further packets will match and follow state, no?
>
> Again, I find concrete examples - like the use of valtype skipto,fib
> mentioned above - really helpful, essential really, for bears of such
> little brain as I ..
ok, so sometimes I like to do some processing on a packet (e.g. divert
it somewhere for munging) after I've set up a state for it.
so I don't want to necessarily Act on the state immediately. but the
packet may get changed in the munging, so I need to set the state
before hand., or I can't match it.
here's a real example that I couldn't do because I couldn't
store a state without actually doing it.
I wanted all packets from a process on the local machine (identified
because
it has a unique group, used for just this purpose) to be forwarded to a
particular other machine for "vetting', however the machine I am doing
this has outgoing NAT using a modified natd that also does some added
"stuff".
After the NAT I can no longer recognise the packets that came from
that process
as they moved out of the kernel to userland and back, yet I still need
these
ackets to go through the natd.
So I need to identify them first, before the nat in order to set a
state entry for
them. Since they are local packets NAT will not have changed their
addresses,
so AFTER the NAT I could have done the associated check-state which
triggers
the stored action (forwarding to another location).
I ended up having to do this via an ugly use of skiptos where packets
I wanted to forward, were identified early and then sent to a
duplicate set of
rules which also did the divert, but then did the forward. I think
there were
about 25 rules duplicated.
Having said that, "store without do" is the least important of the
features.
Store (do or not) without a prior checkstate is more important to me.
state name are a wonderful addition that I have yet to use in all my
scripts
I just haven't had time yet.
>
> cheers, Ian
>
More information about the freebsd-ipfw
mailing list