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@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@fw:~ # root@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@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? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature
