Hi Ryan, > On 28 Jun 2015, at 04:04, Ryan McBride <mcbr...@openbsd.org> wrote: > > This is nice, I hope you'll share the editable source file as well.
Currently just scribbling it together on Lucidchart. Its nothing clever like LaTeX source ;) However I can only add a couple of editors? I would be more than happy to give edit rights to anyone who is better informed about this stuff so we can get a good and up-to-date flow diagram which can be publicly shared? > > A few comments: > > rdr & nat happen as part of packet filtering now, not as separate > ruleset evaluations. Awesome, thanks. I have changed this can you check it looks right? http://postimg.org/image/l172i1vmx/ <http://postimg.org/image/l172i1vmx/> or http://s12.postimg.org/40o69dilp/Open_BSD_Packet_Flow.png <http://s12.postimg.org/40o69dilp/Open_BSD_Packet_Flow.png> Its scruffy but its getting there :) > They can both occur on ingress as well as > egress packet paths; (binat in pf.conf gets expanded to a pair of > nat & rdr rules). > > pf now does af translation (NAT64) as well, see af-to in pf.conf(4) Amazing, thank you. > > I would suggesting adding a box for "Address & Port Translation > (nat-to, rdr-to, binat-to, af-to)" right after "State Generate" > in both ingress and egress, and have the "state exists" path merge > into that step. I'll bow to your knowledge if you tell me this is correct, but isn't the state created after the nat-to and rdr-to is applied as the state stores both the inside IP and the outside IP etc. Of does this second box also append this extra info to the state that was created at the previous step (Packet Filtering)? I haven't added this yet.. > > > On Thu, Jun 25, 2015 at 10:15:08AM +0100, Andy Lemin wrote: >> Surprised I've not had any replies for this? >> http://s12.postimg.org/i4pggq465/Open_BSDPFPacket_Flow.jpg >> <http://s12.postimg.org/i4pggq465/Open_BSDPFPacket_Flow.jpg> Thanks you so much for your time, I'm all ears for more ?? :)
