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@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@fw:~ #
4. State while pinging:
root@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@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!
_______________________________________________
freebsd-pf@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
