pf's states

[Artem Viklenko]

On 04.12.19 09:47, Victor Sudakov wrote:
> Artem Viklenko via freebsd-pf wrote:
> 
>> Had to build test lab....
> 
> Thank you for your time.
> 
>>
>> I still not 100% sure about state-policy - can't check it now.
>> But it definitelly can influence on the final result.
> 
> Let's stick to the default floating state-policy for now. No need to make
> the lab more complicated.
> 
>>
>> Simple ruleset:
> 
> Once you have invested your time to build the lab, could you please
> reproduce my ruleset exactly (I'll repeat it below)?  Unlike yours, my
> ruleset has *all* rules bound to interfaces. It would be also very nice of
> you to use the same IP addresses so that we did not have to translate the
> addresses mentally.

Actually, no. Seems I've provided enougth examples.

> 
> [dd]
> 
>>
>>    Traffic coming in the system was inspected by pf
>> rules and first state was created. Then traffic going out to destination
>> via another interface was inspected by pf again and second state was
>> created by the same rule #1.
>>
>> ICMP replies going in reverse direction pass due to these states.
> 
> Why would you need two states to pass the replies, that is the
> question. If the rule is floating, why is one rule not enough?
> 

Not I need - this is how PF works.

> [dd]
> 
>>
>> This is because by default pf allows traffic but not create states.
>> You can start pf with empty ruleset and see no states while traffic
>> passing firewall.
> 
> No doubt about it. But I was not talking about the complete absense of
> states. Please see below.
> 
>>
>> So then traffic came back it was blocked by last matched rule with
>> keyword in which is rule #2 in this case.
> 
> No, in my case *one* state is being created. The question is why this one
> available state is not enough to pass return traffic? Please peruse the pfctl
> output I provide below:
> 
> A brief repetition of what I was doing. I'd be grateful if you replicate it.

Similar case - from the traffic point of view - already in my post with 
explanations.


> 
> 1. Interface configuration
> 
> hostname="fw.test"
> ifconfig_vtnet0="DHCP description Outside"
> ifconfig_vtnet1="172.16.1.1/24 description DMZ"
> ifconfig_vtnet2="192.168.10.1/24 description Inside"
> 
> 2. Ping configuration
> 
> Pinging 172.16.1.10 (dmz host) from 192.168.10.3 (inside host).
> 
> 3. Rules
> 
> 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: 9596      Packets: 1         Bytes: 84          States: 0     ]
>    [ Inserted: uid 0 pid 1343 State Creations: 1     ]
> @1 block drop in on vtnet1 inet from any to 192.168.0.0/16
>    [ Evaluations: 2955      Packets: 2954      Bytes: 248136      States: 0     ]
>    [ Inserted: uid 0 pid 1343 State Creations: 0     ]
> @2 pass in on vtnet2 all flags S/SA keep state
>    [ Evaluations: 6641      Packets: 2955      Bytes: 248220      States: 1     ]
>    [ Inserted: uid 0 pid 1343 State Creations: 2     ]
> root at fw:~ #
> 
> 
> 4. State while pinging:
> 
> 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:51:57, expires in 00:00:10, 2970:0 pkts, 249480:0 bytes, rule 2
>     id: 000000005de756c8 creatorid: 9da41898
> root at fw:~ #
> 
> 
> 5. Question:
> 
> We see that a floating state "172.16.1.10:33794 <- 192.168.10.3:33794" has been
> created by rule 2. Why is this state not passing ICMP replies from 172.16.1.10 to
> 192.168.10.3 ? I.e. why is this state not overriding the blocking rule 1 ?
> 
> 

-- 
Regards!