pf's states

[Max]

No. You have no block rules on $inside (no rules at all in this case). 
PF uses default pass with no states.

I think we should consider the traffic flow from the firewall's point of 
view. It has incoming and outgoing flows. That's all. Transitional flow 
is just a combination of incoming and outgoing. If we have incoming 
packets from some source ip (straight flow) then reversed packets will 
flow to that source ip. When we send packets to some destination ip 
(staright flow) the reversed will be arriving from that destination ip. 
No matter if we use one interface or two. So, in the case of 
transitional connection it will be:
1. recieving packet from src to dst (incoming)
2. creating state src-dst allowing to pass replies TO src (and straignt 
flow from src)
3. routing
4. sending packet from src to dst (outgoing)
5. creating state dst-src allowing to pass replies FROM dst (and 
straight flow to dst)

> root at fw:~ #  pfctl -vvs states
> No ALTQ support in kernel
> ALTQ related functions disabled
> all icmp 172.16.1.10:33794 <- 192.168.10.3:33794       0:0
>     age 00:43:38, expires in 00:00:10, 2498:2498 pkts, 209832:209832 bytes, rule 3
>     id: 000000005de764a4 creatorid: 4e14336a
> all icmp 192.168.10.3:33794 -> 172.16.1.10:33794       0:0
>     age 00:43:38, expires in 00:00:10, 2498:2498 pkts, 209832:209832 bytes, rule 2
>     id: 000000005de764a5 creatorid: 4e14336a
> root at fw:~ #
>
> I begin to see two identical (?) floating states. I call them identical because
> both denote the direction of traffic "192.168.10.3 -> 172.16.1.10". There is not
> a state with (reversed) key "172.16.1.10 -> 192.168.10.3", but the return
> traffic is now somehow magically passed. I'm mystified again.

They are distinguish. "<-" means incoming flow, "->" means outgoing flow.

05.12.2019 7:24, Victor Sudakov пишет:
> Victor Sudakov wrote:
>> Max wrote:
> [dd]
>
>>> Or you can create "pass out on $dmz..." rule.
>> Yeah, that sounds great.  The ping responses begin to arrive at 192.168.10.3!
>> Victory!
> You know what! If I create a "pass out on $dmz..." rule, no rules on
> $inside are necessary any more. pfctl shows only *one* state, but this time
> it is sufficient:
>
> root at fw:~ # pfctl -vvs rules
> No ALTQ support in kernel
> ALTQ related functions disabled
> @0 pass in on vtnet1 all flags S/SA keep state
>    [ Evaluations: 15        Packets: 0         Bytes: 0           States: 0     ]
>    [ Inserted: uid 0 pid 1262 State Creations: 0     ]
> @1 block return in on vtnet1 inet from any to 192.168.0.0/16
>    [ Evaluations: 1         Packets: 1         Bytes: 84          States: 0     ]
>    [ Inserted: uid 0 pid 1262 State Creations: 0     ]
> @2 pass out on vtnet1 all flags S/SA keep state
>    [ Evaluations: 1         Packets: 0         Bytes: 0           States: 0     ]
>    [ Inserted: uid 0 pid 1262 State Creations: 0     ]
> root at fw:~ #
>
> root at fw:~ # pfctl -vvs states
> No ALTQ support in kernel
> ALTQ related functions disabled
> all icmp 192.168.10.3:63234 -> 172.16.1.10:63234       0:0
>     age 00:00:11, expires in 00:00:09, 11:11 pkts, 924:924 bytes, rule 2
>     id: 000000005de88142 creatorid: 68441fab
> root at fw:~ #
>
> Now 192.168.10.3 can ping 172.16.1.10 and receive echo replies, 172.16.1.10
> cannot ping 192.168.10.3.
>
> Don't you think there is something non-trivial or even incorrect about the
> way states are evaluated?
>