Hello Ian,
sorry it took me while to come back to you. I've got some tracks and kept
forgetting about it.
</snip>
> If I add 'log' to the block all, I can see on pflog0 that it's the 'block
> all' rule which is blocking it.
>
> I've seen this similar behaviour before I set up pfsync, but in this case
> it seems to be working fine and both hosts have a state entry which is
> created when I start pings:
>
> root@gw2:~# pfctl -ss |grep 193.0.6.138
> all icmp 172.16.0.91:8123 -> 193.0.6.138:8 0:0
>
> root@gw1:~# pfctl -ss |grep 193.0.6.138
> all icmp 172.16.0.91:8123 -> 193.0.6.138:8 0:0
>
> Is anyone able to shed any light on what's going on?
>
If I understand your set up right, then gw1 is supposed to forward icmp
packets between gw2 and ripe. If it is the case then I would expect
there will be two state entries for ICMP packet:
the first 'inbound' state created by inbound packet
the second 'outbound' state created as ICMP request leaves the host.
the 'pfctl -ss' just shows single state here, while there should be two
in fact. But it still does not explain why
pass quick proto { icmp, icmp6 }
fails to create a missing state. if matching state can not be found
four outbound icmp reply on gw1, then the rule above should kick in.
I wonder how 'pfctl -sI' output looks like. It should report all
network interfaces recognized by pf(4).
I'm not sure how much busy gw1 is, but it might make some sense to
repeat the test with 'pfctl -x debug', this will make pf(4) more
talkative we might be lucky to get some hits to see what goes wrong.
regards
sashan
