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/

Attachment: signature.asc
Description: PGP signature

Reply via email to