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
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "[email protected]"
