Hello Ian,
On Mon, May 02, 2022 at 03:27:06PM +0100, Ian Chilton wrote:
> Hi Alexandr,
>
> Not quite, this is the corrected diagram:
>
> .--->-- rpki.ripe.net ---->--------.
> | |
> | |
> | |
> ^ echo request: V echo reply:
> | 172.16.0.91 -> 193.0.6.138 | 193.0.6.138 -> 172.16.0.91
> | |
> | vlan367 | vlan313
> ,------+-------. ,------+-------.
> | gw2 | vlan209 | gw1 |
> | 172.16.0.91 +-------------------+ 172.16.0.90 |
> | | | |
> | +-------------------+ |
> | | vlan409 | |
> `--------------' `--------------'
>
>
> > I would try to make state check less paranoid at gw1:
> > pass quick proto { icmp, icmp6 } keep state (sloppy)
>
I would like to have one more clarification here.
is there a pfsync(4) configured between gw2 and gw1?
the reason I'm asking is I could see a state at gw1 in one
of your earlier emails. It looks like such state allows
incoming ICMP reply to enter gw1. The only way to explain
the existence of such state is it gets imported by pfsync
from gw2. If this is the case then story goes as follows:
gw2 sends ICMP request, outgoing ICMP request is
intercepted by pf(4) running at gw2. The packet
creates state and leaves gw2 to rpki.ripe.net.
the state created by packet is exported by pfsync
from gw2 to gw1. gw1 imports state which allows
inbound ICMP reply and outbound ICMP request.
ICMP reply arrives to gw1. It enters pf(4) as inbound packet.
inbound ICMP reply is allowed by state. pf(4) accepts packet.
packet enters IP stack at gw1, which forwards the packet towards
destination.
when packet reaches outbound NIC at gw1 it is intercepted
by pf again as outbound ICMP reply. There is no state, which
allows outbound ICMP reply. pf checks rules for ICMP reply:
pass quick {icmp, icmp6} all
rule does not match, because implicit 'keep state', is not
allowed to create state for icmp replies.
thanks and
regards
sashan
