Am Freitag, 22. April 2005 03:04 schrieben Sie:
> On Fri, Apr 22, 2005 at 02:40:31AM +0200, Wolfgang Walter wrote:
> > > Although you probably have rp_filter turned, but please check
> > >
> > > cat /proc/sys/net/ipv4/conf/eth3/rp_filter
> > >
> > > anway.
> Please do this check.
> > > > src 10.148.0.0/23 dst 10.0.25.210/32
> > > > dir fwd priority 0
> > >
> > > There you go. This policy trumps your other policy. This one
> > > says that forwarded traffic matching it must carry no tunnel
> > > IPsec transforms. Therefore all IPsec packets matching it will
> > > be dropped.
> > I don't understand that. 10.148.0.0/23 is 10.148.0.0-10.148.1.255, isn't
> > it? But 10.148.4.0/28 (is 10.148.4.0-10.148.4.15) is not within it.
> Sorry, I misread the netmask. I was right about the problem though :)
> Further down it says
> src 0.0.0.0/0 dst 10.0.25.210/32
> dir fwd priority 0
> which still trumps your IPsec policy.
Oh yes, me stupid.
They are needed (these hosts are allowed to communicate with outside world
unencrypted), but priority is wrong.
Our rules are generated from a description of the network. And if we connect
10.0.25.210 directly to C and change netmask to 30 instead of 32 our
generator assumes that this system is not allowed to communicate with outside
world and does not generate this rule.
Thanks a lot, sorry for bothering you. I should have seen this difference. But
probably I would not have recognized that as a problemebecause I assumed that
in and fwd allow-rules only applies to non-ipsec packets which of course is
not logical :-).
Anstalt des öffentlichen Rechts