Date: Fri, 5 Aug 2016 12:36:56 +0800 From: Julian Elischer <julian@freebsd.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: "Andrey V. Elsukov" <ae@freebsd.org>, lev@freebsd.org, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" <melifaro@freebsd.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? Message-ID: <24bf65d1-1b4f-07a0-5a3c-93fd906f5705@freebsd.org> In-Reply-To: <20160805034606.K56585@sola.nimnet.asn.au> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <d7bef617-70a4-f761-7d09-9413eb720b11@freebsd.org> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> <ee745842-c33e-4e73-f84c-6eb11f283b51@FreeBSD.org> <a3e98e25-4c0d-56ad-5640-0b6f13ebeb21@freebsd.org> <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> <20160805034606.K56585@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24bf65d1-1b4f-07a0-5a3c-93fd906f5705>