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.
>
> Cheers,
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 :-).
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Leopoldstraße 15
80802 München
|