Hello Yasuoka-san,

</snip>
> > 
> > The thing is that rdr-to rules always imply match on inbound packets,
> > and similarly nat-to rules always imply match on outbound packets.
> >
> > So the natrule we are post-processing here will either have rdrpl
> > or natpl, but never both at the same time. So this the only change
> > I can suggest to improve in your diff.
> 
> In my understanding, pf.conf(5) says "nat-to is usually applied
> outbound" and "rdr-to is usually applied inbound", but actually pf
> accepts "in nat-to" and "out rdr-to" and it works.
> 
> So I prefer refusing the config when being parsed or writing the
> behavior on the man page clearer if we don't handle such the non usual
> cases.
> 
> Aslo, if we can assume the state can have only rdrpl or natpl, we can
> suppose it's natrule.ptr->nat or natrule.ptr->rdr then there is no
> need to iterate the match_rule.
> 
> What do you think?
> 

    I did some testing and I think rdr-to/nat-to require some work
    to be done (see further below). You can commit your diff with
    OK sashan further improvements can be done as follow up work.

This is what I've tried:

    echo 'pass from any to any nat-to 192.168.1.10 rdr-to 192.168.2.10' | \
	pfctl -nvf -
    stdin:1: nat-to and rdr-to require a direction
    stdin:1: skipping rule due to errors
    stdin:1: rule expands to no valid combination


If I fix it and add 'in' I get this behavior

    echo 'pass in from any to any nat-to 192.168.1.10 rdr-to 192.168.2.10' | \
	pfctl -nvf -
    pass in inet all flags S/SA nat-to 192.168.1.10

The rule gets accepted by parser, but rdr-to option is ignored. Trying to use
out, I get this.

    echo 'pass out from any to any nat-to 192.168.1.10 rdr-to 192.168.2.10' | \
	pfctl -nvf -
    pass out inet all flags S/SA nat-to 192.168.1.10

So let's change the order of nat-to and rdr-to.

    echo 'pass out from any to any rdr-to 192.168.2.10 nat-to 192.168.1.10' | \
	pfctl -nvf -
    pass out inet all flags S/SA nat-to 192.168.1.10

so order does not matter, nat-to still takes precedence.
This is behavior is yet another glitch. So I'm fine if you commit your diff
as is. It can get further changed once it will be in the tree.

thanks and
regards
sashan